I started programming 7 years ago. After watching dozens of YouTube tutorials, I decided to take things more seriously and enroll in a coding bootcamp in 2015.
It was hard work, but I had a blast! We covered HTML/CSS/JS, Ruby, Ruby on Rails, and Git.
We were encouraged to use the command line as much as we could, so I got pretty comfortable with Git's most popular commands, such as git commit, git branch, git push, and git pull. I worked mostly solo during that time, so those commands were usually enough for my daily workflow.
When I finished my bootcamp, I wasn't working alone anymore. I learned the hard way how to amend commits, fix merge conflicts, and what force push was about. It started to become a bit overwhelming 😰
As projects got more and more complex, I was feeling blind with just a terminal by my side, so I took the plunge and explored what Git clients had to offer.
Adding a Git Client to My Web Development Workflow
Like many others, I started with Sourcetree, a free Git client. The visual aid it provided opened my eyes (pun intended) to how I could become more productive with Git.
I could easily:
- find the commits and branches I needed
- have a look at what changed in each commit
- add service accounts (like GitHub) for quick cloning
At first, I felt guilty — using a Git client was sometimes seen as cheating! For this reason, I would still go back to the command line to recreate some operations, or read the Git documentation to figure out how to type some commands.
I was acting as if the Git client wouldn't be there for me tomorrow. I guess I didn't want to let my bootcamp senseis and my peers down 😶
Looking back, that doesn't make much sense to me. I should be busy coding, not wrestling with Git! So I started relying more and more on Git clients. That gave me more time to learn how to properly center a div and keep up with JavaScript frameworks.
Sourcetree was a great introduction to what a Git GUI can bring to the table, but I didn't stop there. I always enjoy trying out new apps, so I gave many other Git clients a shot — some free, some paid. Now, I have the privilege of doing that for a living (I work at Tower).
Tower is my favorite of the bunch. It's available for both Mac and Windows and is currently on sale — 50% off for the first year (Black Friday deal).
Tower also offers a 30-day trial with all the features. It doesn't ask for an email account or credit card, so there's absolutely no pressure to give it a shot.
Oh, and it's free for students and teachers!
Why I Think You Should Give Tower a Try
Tower has all the basic features you would expect from a premium Git client. It can perform any Git operation with the greatest of ease, like staging files (or chunks), amending commits, merging and rebasing, stashing, etc.
It supports all the popular remote services, such as GitHub, BitBucket, GitLab, Azure DevOps, Perforce, or Beanstalk. You can clone and publish new repositories directly in the client, manage pull requests, and perform repetitive actions (like fetching) automatically for you.
It has many quality-of-life improvements, like managing multiple author profiles and GPG keys, a command palette, a CLI tool, LFS and submodule support, and themes.
But the big differences are in the details. And no other app comes close to Tower when it comes to intuitiveness and feeling productive.
Here are 4 things that I think are worth highlighting:
1. Native App
I don't hate Electron apps, but sometimes they don't feel right (maybe that's why I still prefer to use SublimeText over VS Code). I tend to use native apps, even though they're hard to come by.
Tower was developed using native technologies, and it shows. It's a joy to look at and the performance is stunning. Even while working with large repositories, I never felt any hiccups.
2. Undo
Quite possibly my favorite feature. Other Git clients also allow you to undo some actions, but sometimes they don't work as you'd expect (or some actions are missing).
With Tower, you just need to hit CMD+Z (or CTRL+Z on Windows) whenever you make a mistake. This is a huge confidence-booster for me; every once in a while I'm just going through the motions and I accidentally mess things up.
You can undo pretty much any action; every time I run into an issue, I just hit CMD+Z and it works. It has never let me down — even while merging or rebasing.
Another thing I find really neat is that it can recover file discards — which is something that Git doesn't actually allow! I was pleasantly surprised the first time I pressed CMD+Z and the discarded file returned to my working copy 🤩
3. Working with Branches
I'm constantly checking out different branches, so I really appreciate the effort the team put into this.
First, checking out branches is a breeze. You can use Quick Actions (Tower's command palette) or, if it's a frequently used branch, you can pin it to the sidebar.
I also enjoy how you can compare branches to pinpoint the commits that are exclusive to a branch, or how it tells you that you will need to solve a merge conflict if you go ahead and merge that branch.
The "Branches Review" view even identifies which branches are safe to be removed, so that you can clean up messy repositories without looking over your shoulder.
4. Drag and Drop
Another prime example of how Tower thinks differently is how Drag and Drop was implemented. It’s so intuitive that I miss it when I'm not using Tower for a Git operation.
I can drag and drop to cherry-pick commits by simply dragging commits from another branch to the HEAD branch. I can move commits around or drop one on top of another to perform a squash. Interactive Rebase is really easy this way.
I often spend a good chunk of time reviewing and tweaking the commits I added before pushing everything to the remote repository. Drag and drop is vital in this process.
While those are my favorite use cases, drag and drop also works to merge, push, and pull. It's even possible to create (or publish) branches this way.
I don't waste time with Git anymore — everything just works! For this reason, I highly encourage you to give Tower a try (even if you're proficient with the command line)!
What about you? What's your favorite Git client and why?
Top comments (28)
It's going to sound harsh (not my intention at all):
The worst advice ever is to tell people that is learning git, to use a git client.
The main problem with git apps is that they usually hide hard-to-understand concepts that you should really invest time in learning them. Why? Because you really need them to work in complex environments. You need to understand how to work with multiple remotes in the same repository. You need to understand how to do rebases and merges. You need to understand how to do binary search, etc, etc, etc.
Git is complex. For sure. But it's a really important tool that helps a lot and solves a lot of weird cases, and on top of that, the concepts of control version systems are a really valuable skill to invest time.
Not harsh at all, @alexsaezm! I know where you're coming from. I already had a decent understanding of Git before I moved on to Git clients, which was definitely helpful.
That said, I think a good Git client can definitely make you a better developer. With all the visual aid they provide, you can create granular commits with ease, resolve merge conflicts in a nutshell and quickly pinpoint what changed in a specific branch or period of time.
Of course, everything you do with a Git client can be done over the command line. But my repositories look much more organized and readable after I took my time to learn how to properly use the superpowers Tower gave me 🙂
The problem I find with the CLI git command is people run commands and don't/can't understand what state they're currently in which gets them more trouble! Not a failing of git itself, just the lack of easy visibility into where they're at.
The number of times I've seen someone rebase just to merge their branch into itself is astounding :(
That's a great point @dogers. Git newbies will often type a series of commands without really knowing what's happening due to the lack of visual aid.
For those who haven't got a habit to check the state, there exists a bunch of state-exposing shell helpers like
liquidprompt,bash-git-prompt, etc.Making mistakes is a normal thing and leads always to understanding and learning. The solution is always stop, ask and learn. That's how we grow.
In this particular case (git), if using it looks like a chore, instead of an aid, I think the user is not understanding the tool and of course every single minute will be a painful experience.
That is a strong statement, let see your arguments.
Here I completely agree, I propose this link every single time to my readers
Learn git concepts, not commands
Nico Riedmann ・ Jun 2 '19 ・ 36 min read
In fact that's also exactly the main issue with the git CLI
It adds a ton of unnecessary accidental complexity on top of learning the concepts of version control, which I do agree is the real goal. People should be learning about working in parallel (banches) and collaborating (pull requests) and so on.
Instead they have stupid errors on top of stupid errors: they made a typo in the name of the branch, or they didn't get command flag right, or the cli want them to specifiy the origin for the 24th time, or they don't have a visual clue that they were on the wrong branch or needed to pull.
Actually nobody uses just the git CLI, why do you think hard core users have super sophisticated shell git prompt and tons of git aliases? That's their own version of a better git client.
Did we forget about usability? Are developers not people?
Watch people using git with less than 1000th hours of practice and you will see how terrible the CLI is.
In fact the vast majority of projects have a small number of people who contribute to it and it's absolutely easier to work with one remote.
Again for most projects you are better off with letting the git history of the pull request showing what actually happened, instead of what actually happen. What's the point of pretending you never make mistake? The only history that count is in the main branch. Enable "Squash and merge" by default and you divide the number of fucking up and time wasted by a large amount.
you mean bisect? again YAGNI for most people
The thing is that git was invented for the Linux Kernel project which indeed work in a very weird way (bazaar style) with hundreds or thousands of developers who are really good at mastering low level details. Also they use emails for issues and pull requests, which is why git doesn't support that.
So there is indeed a huge reason why git is the way it is. But that reason probably don't apply to your projects unless you work in a bazaar style fully decentralized manner with hundred of developpers. If that's your context, git is the best tool possible for it.
For the rest of us the real question is what allows us to focus best on the task at hand.
And that's why we use GitHub instead of just git, and better (for us) git clients like for me lazygit or IntelliJ
Edit: I realized that I skipped a few comments that you made so I'm going to answer them for the sake of the discussion :)
Of course it is a strong statement; this is the Internet! Jokes aside, I don't have all the truth in the world, so like every opinion, it's biased and might be wrong. Also, I would love to highlight that the original post is an ad for a tool.
And also that nobody should take comments like mine verbatim where I might have used "argument from authority."
Git CLI is far from easy to use. I know and see the struggles of junior developers because I was one, too, and I mentor them. Everybody makes mistakes, and that is not only fine but useful! It's the learning process. Do hard things (here I'm talking with myself from the past, because I used to avoid hard things :D)
It is no excuse, but the reason is that tooling developers are not good at designing (and I include myself here because I work on a tooling team, and the tools are not user-friendly).
I don't consider myself a hardcore user, and I acknowledge that my work field is rare, but for the sake of the conversation... I do not use aliases, and I don't personally know anyone who does it, as far as I'm aware. The ones I know that did it ditched them or kept them minimal.
As a side point, I'm against bash alias too. The reasons here are different and off-topic, but I wanted to highlight that. My prompt looks like:
No git alias, no bash alias. Why? Because I worked for many years in shared complex environments where bash versions weren't stable and you have thousands of volatile servers. Which is a really common scenario nowadays. I try to keep my tools customization to minimum because they were never only yours and it creates a dependency. I used to do it until I found myself in a server where a bash alias that helped me a lot wasn't there. Not anymore. But that's my personal take (like the the rest of the comment)
While this is true, again, my whole comment is about not being helpful with the yourself of the future. Because sooner or later, you'll be in complex scenarios. That's life, we tend to make things complex.
Far from the truth I think. It's quite common to rebase personal branches or work with forks. It's not about hiding mistakes. It's about helping the maintainer. "Squash and merge" is use in general when the branch you are merging offers only a feature and therefore the history of it is not relevant, only the branch as a whole. But this is a discussion about learning not about git best practices.
The concepts I said are really important and for example binary search (the concept) saves your ass more times than you might think if you learn the CLI command (bisec). Even for junior developers. But only if you know is there.
We need to differentiate collaboration tools from git and git aid. They are not in the same category at all. You use GitHub and others for collaboration. You use lazygit for aid. You use IntelliJ because you want an IDE, and it includes some features that helps you with git. Three different categories, different purposes.
Again, I’m not against aid, I’m against hiding concepts and in general, some of these tools in my experience do that. Once you did understand the inner concepts, even just the basics, do whatever you want to do what makes your work easier. But the best way to learn git in my experience is by practice, not by reading blog posts (unless you have a very specific question, and then you should read the documentation) or using external tools. Learn by doing.
Thanks for the answer.
In fact we agree on many things: on learning by doing, on learning the concepts, that there are git aid tools that don't hide the concepts so those are ok, that collaboration tools are needed on top of git...
Personal opinion here: that's exactly the point.
For me as a maintainer what matters in a PR is that it's focused on one thing. That one thing could cover many files if you rename a function used everywhere or reformat everything, but conceptually that's only one thing.
A PR that does only one thing lowers the cognitive load for everyone involved. So if the PR can't be squashed it's a useful friction, a signal that the PR does more than one thing and can be splitted in smaller ones.
Not saying it's easy, saying it's useful. And if the PR can be squashed and merged, then the history inside the PR doesn't matter. That's why I prefer to keep the "rewriting the history" stuff for the exceptional cases.
git programmers are super talented C programmers.
They are good at many important things: performance, scalability, concepts, portability, features, and tons of low-level details we have no idea of.
Because they are hardcore talented C programmers, they are not however good at usability.
This is not an issue for me, this means that they are building the foundation on top of which others build usable software.
... like GitHub for example.
Git would not have been such a massive success without GitHub
GitHub is not "just" a git remote where you git push your stuff.
GitHub is what made git understandable for the larger public and it proposed its own different way of collaborating on code.
That's why I say fear not the git clients.
Avoid the bad ones yes, but adopt the good ones.
Just a comment regarding the PR squash thing (don’t want to extend the flame I created more lol and I’m using the phone to answer so not able to quote properly)
The squash is the decision of the maintainer but the contributor should rebase to help the maintainers. This is highly common in fast moving projects with hundreds of daily commits. Your pull request is never gonna get merge if you just leave a completely un-rebased branch because that’s the only way to test new code that might change the behaviour of what you are trying to contribute.
Regarding the last quote. Fine enough for me. I don’t consider for example VSCode default git support a git client. It’s just visual aid. Aid is always welcome if that leverage the cognitive load of the user. But I consider it and hosting software different things to git clients like the ad/post we are commenting.
GitHub is not about usability - the latter is sick there. It is about social networking in development (initially, only public FOSS development). Well, this is definitely not a programmer's task itself.
Still the best client I've met is the standard CLI ;)
If so, I haven't yet met a visual Git client suitable for me, my flows and manners. Standard CLI (with own aliases, of course) is still best.
And, the reason would be the same as @alexsaezm defined - all clients are limited and adjusted to a minor subset of features and scenarios, effectively dropping chance to get out of their Procrustean bed.
I disagree. Thats like telling people "The worst advice ever is to tell people that are learning how to program to use an IDE". Yes, you can program with notepad or a text editor and compile using a CLI. But using an IDE can take out a lot of frustration with getting through the fundamentals. Same with using a git client. Once they get the foundations of git into their head using a client they can go on and dive deeper into the topic using a CLI. Then use which one they find more helpful. TBH 90% of devs really only need to use a client.
Sorry, but that comparison is not accurate at all. And IDE doesn’t hide concepts. For example, no IDE is gonna hide OOP concepts.
I have a mentee currently that is struggling a little with some concepts because she keeps using a text editor when a more powerful tool would help her leveraging the cognitive load of the task. That is absolutely fine. But no matter what tool she uses, the concept is there and she needs to understand it.
As I said in other comments, I’m not against aid, I’m against hiding concepts. Those concepts will help you in the long run.
An IDE does hide how to compile, error highlighting, formatting, use of a terminal, vertical/horizontal layout of multiple code source files, etc. Which was my point.
I don’t want to sound picky but the whole point of my comment was about learning and hiding concepts in the learning path of someone and non of those examples are doing that.
Why not simplify those complex environments then?
Also, Do you know what blackboxing is?
For a simple flow, cloning, staging, committing and pushing is enough for a regular developer.
The amount of use cases of multiple remotes can be counted with one hand. On one finger actually: when contributing to a FOSS project with having your own forked repository of it and you want to keep getting up-to-date with the upstream repository. I've never had to deal with multiple remotes at my jobs.
Merging and conflict-resolving is still horrible error-prone without visual Git client (and anything vim-emac-like is not visual). It is also sad git does not provide a way to stage changes per line.
The requirement of using rebase means your git-flow is too complex, and/or the commits are too big. With the Law of Murphy in mind, rebasing is something your rather not want to do.
Never had to do that. gitk is sufficient enough.
First of all you can’t simplify everything, no when you work with tons of developers. Not everyone works in a small 5 people team. Sadly it is in our own nature to make things complex in the long run. That’s the whole point of the technical debt for example.
You might be right that remotes are more necessary in FOSS projects, and in fact that’s my daily job, so of course my views are biased. But I used them for years in privative projects before working at open source.
I explained more in other comments but, again, I’m against hiding concepts that make things look like magic when you should be the wizard in the story :P
Thank you for this. I've been struggling with git and, like you, have become frustrated that I'm spending time trying to figure this out when I want to be focused on more important things. I never thought to try to find an easier way. I've downloaded Git Force to try out a free option.
Thanks for reading,@angelabowen! Let me know how it goes.
Feel free to give Tower a try as well, since you can use without any limitations for 30 days.
The advice is sound, but who needs a client when vscode (you’re writing code with that, right?) has full integration with git{hub,lab} anyway?
Thanks for reading! Haha, actually I go back and forth between Sublime and VS Code depending on the task. But that's a post for another day :)
IMO, VS Code is perfectly fine for that quick commit/push where only a couple of lines were modified. I'm a fan of granular commits though, and after an entire afternoon of work I often need to review what changed. Before pushing, I launch Tower to have a look at the diffs (to decide which chunks will be staged), or if I need to perform a more complex operation like interactive rebase or a merge.
The git client that really worked for me is Cycligent Git Tool. How it presented the git "model" matched my mental model of git. Alas, it appears to be abandonware. And since it wasn't open source, it's deadware. Especially since it wasn't finished yet, and had not-yet-implemented features.
I use git on the command line, predominantly. Sometimes, I use Atlassian Sourcetree, for some operations that work better in a GUI than command line.
My former boss highly recommends SmartGit as the best GUI client. I have not used it yet. Someday.
I've tried Tower and GitKraken. That was about 4 or 5 years ago. I recall that Tower was good, and in my team review I gave it thumbs-up. And that GitKraken seemed very nice — to my sensibilities — but didn't scale to the size of my project, so at the time it got thumbs-down. Maybe the scaling problem has been fixed.
Personally, I love Fork (fork.dev/) although unfortunately there's no Linux version right now. I like to have a TUI client knocking about too, in case of any issues - gitui is the current favourite (github.com/extrawurst/gitui/)
Thanks for the suggestions! I will give gitui a shot 😀
No Linux version? I'll stick with GitKraken then
At this time, Tower is only available for macOS and Windows, as they are both native apps.
Oddly phrased response. You can make native apps for Linux too