I’ve been thinking a lot lately about how I use Git in my day-to-day work, and I’ve realized I still default to the terminal for just about everything Git-related. For me, there's something satisfying about typing out commands and getting immediate feedback, especially when I’m doing things like rebasing, cherry-picking, or fixing up commits.
But then I started wondering... am I just stuck in my ways? There are so many GUIs and tools out there that streamline Git workflows—tools like GitKraken, SourceTree, and even VS Code’s built-in Git integration. Some of them look slick, and I know they make things easier for a lot of people, but I can’t seem to break away from the terminal. Maybe it’s the control freak in me!
So here’s my question: Do you still use Git in the terminal, or have you switched to using a tool? If you’ve made the switch, what’s your favorite Git tool? I’d love to know what everyone’s using these days. Maybe I’ll find something new to try out!
Drop your thoughts below—I’m genuinely curious to hear what’s working for you.
Top comments (319)
I use a GUI (VSCode) to view git history and diffs (including viewing/resolving merge conflicts), but command line for everything else (commit, push, fetch, merge etc) ... just a GUI for tasks which are easier to do via a GUI, and CLI for the rest :)
Just like this, I use the VSCode GUI mostly for merge conflicts and see the branch tree in a much clear way, and have it updated with remote pressing just one button.
For the rest I use the CLI, without any aliases because I like it rough (?)
Yeah VSCode is so good for resolving conflicts! The CLI is just SO much faster for everything else though.
That side by side comparison is too nice to live without!
I do exactly the same!
I learned git via the CLI first, and I have tried using GUIs on multiple occasions, but I'm having a hard time figuring out exactly which commands it's going to run, so I prefer to write it myself 😅
But for git history, and diffs, I use GUIs.
I use
git
on the command line 99% of the time.For those hard to reach places via command line, I use either Atlassian Sourcetree or git's own gitk.
My former boss speaks very highly of SmartGit. I haven't tried it, though.
Both Xcode and Visual Studio have git integration, but I never use git from those IDEs.
I've heard from my colleagues that use VS Code that the git integration is excellent.
(I was looking forward to Cycligent Git Tool, but appears to have been abandoned years ago. Alas. It was the one Git GUI client I've found that really resonated with me.)
git in the CLI is slow, inefficient and clunky...
SmartGit is hands down the best crossplatform git GUI I've ever used, too bad they removed the free tier and now its completely payware...
Sourcetree is a bloated mess...
Stay away from Gitkraken, personally I don't trust any app that asks me to login, especially one for git client...
VScode used to have a very popular git extension, that is before it got bought by Gitkraken and now they constantly push you to buy premium or something...
SublimeMerge is a decent git client, could even be considered a good one if it didn't had that annoying popup to buy a license...
Gittyup is free and open source, it doesn't have the most modern UI and it has crashed a few times, but overall it gets the job done, I've been using it ever since I've had to switch from Smartgit...
there are other open source alternatives like Gitnuro which has a modern look but lacks functionality and its development is probably abandoned...
there's also GitButler, another open source with a modern interface that tries to update the workflow of git with virtual branches or something, and it also generates commit messages with AI, it seemed interesting but it feels like its in alpha and in the end I went back to Gittyup...
I will say, I disagree with your first statement. It works much faster than any GUI for larger operations, and if you power yourself with aliases and functions like in my latest blog post you're really speeding up your workflow in the CLI.
Have you checked out LazyGit yet?
I haven't checked it out yet so I don't know what to say about that approach, in general I'm a bit shy of using the terminal so I just prefer clicking on stuff, also having the ability to see a side-by-side code diff is another personal preference
Side by sides are a very nice quality of life feature!
Tools where you can click around are nice, but they're just doing all the commands under the hood for you. So if you're doing some heavy lifting, since the GUI adds a layer of abstraction, certain big operations can take much longer 7-10 minutes in some cases vs 10 seconds or less in terminal. But hey, ain't nothing wrong with a little coffee break now and again!
If you're a little terminal shy, I'd recommend you to follow my channel here. I try and do my best to demystify the terminal and make it approachable for everyone :)
Is gitk available on Linux as a standalone app?
I've not heard of it before though, might want to try it out.
Yes. Actually, it is the GUI tool that I use when the CLI is not enough
I've been hearing lots of good things about LazyGit though!
I've never heard of it being used on Linux, worth checking the package manager for your distro though!
Yes
I mostly use the GitHub Desktop app on Linux/Mac. The thing does have its limits though, so I do have to switch to the terminal every now and then.
I love the GitHub Integration. If my branch is related to a PR, I can see the status of the PR and know out of the desktop app if there's a problem with it or not.
What editor do you use mostly?
I use JetBrains WebStorm mostly. I know they have an amazing Git / VCS integration, but I got used so much to the GitHub Desktop app. I've been playfully mocked by some of my colleagues for being probably the sole developer in our company who uses the Desktop app :D
But like I said - I simply got used to it.
We all fall into ways. I would encourage you to play around and learn Idea VCS. It's literally better than everything else. I think you'll find the swap easier than you think!
The only beef I have with GitHub Desktop is that I only can have one stash active in the UI. I'll try it out and see how it works! The good part is - I have used it to some extent already. I know that changing branches also kind of restores the branch's "workspace", which is a nice feature. This of course gets lost if you change the branch from an outside source.
One feature that's pretty nice is you can create different groups for your commits. So sometimes code bases suck and you need to have changes to make things work and not want to push them up. So you can create a group called "don't commit" and move in the files you don't want to commit. then you can have them seperate from all your other changes making it really easy not to accidently push changes you don't want to commit.
The merge conflict editor and diff tool are out of this work imo too. :)
I use a bit of many things:
gitk
most of the times I want/need to look at the history, andgit citool
(fromgit-gui
) to stage changes and commitgit mergetool
with Meld to resolve conflictsI think it varies person to person.
Most def does! However, I've definitely seen some trends on this thread. I think the most common answer I've read so far is, "Yes, I use the terminal for most things but I use VSCode or Idea VCS to handles conflicts and diffs, since the GUI makes those more easily readable with the side by side comparisons"
I use the command line, gitk, and lazygit for their respective strengths.
Lazygit can do things like move a commit back in history, which is just a little easier than command line interactive rebase. It can split up an old commit “in place”, which is also an interactive rebase which contains more steps. It can edit commit messages in old commits, which is helpful when you’re the maintainer of a code base with commit message standards. Basically, I use it to do commit cleanup before and after the pull requests. It’s very helpful for rebasing and conflict resolution too, where it shows you what commit you’re currently merging and which files are in conflict. And it allows you to view the conflicts and open an editor to work on that file. After you fix and save all the conflicts, it will continue merging the next commit until done.
Gitk is useful for its lazy graphical UI updating. When I press F5, it refreshes the branch and tag states but still keeps the old refs. So if I made a mistake in the current session, I can just hard rebase back to the previous history. Lazygit will prune the old refs from the view aggressively.
The command line is good for git status and quick commits, as well as times when you want to pass in —no-verify or other flags.
I used to use tig (git spelled backwards). It’s now replaced largely by lazygit except for the use of git blame. It can traverse history to find who really created the line, even after it’s been reformatted by other people. It’s not automated but the tool makes it easier.
I use the git provided by VSCode and git graph to have a clear visual.
I'm the lazy person that do not like to remember git command and prioritize speed/ minimal steps or keystroke to achieve what I needed to, most of the time when I work with build-in git it's usually the case of me waiting for tasks to finish, instead of tasks waiting for me to finish typing.
I love the little time where I can squeeze in a little bit of stuff.
I must admit it was a small bouquet I used, a combination of the terminal, vscode extension and GitHub Desktop. Some steps along the way just seemed more comfortable here and others there. However, for anything complex it was definitely the cli.
I moved away from the CLI and use GUI tools now.
I started off with SourceTree by Atlassian. It was great. But it was a super memory hogger and CPU hogger.
Then I found GitKraken. It was cross platform - supported in Windows, Mac, Linux. But somehow the UI didn't quite cut it for me # felt clunky and slow in rendering all UI components.
Then I found Fork and been madly loving it since 2019. Very feature rich. Does not hurt CPU/Memory. The UI feels snappy and it just works. Their team is also pushing out new features and bugfixes quite fast compared to other publishers. Only downside, is it is only supported in Windows & Mac. So if you're using Linux/Ubuntu, this is not for you. But i have been a super fan of it on MacOS ever since - and later learned that many of my colleagues switched to it as well after they saw me juggling with it.
The support for Git in VSCode works for some. But to me, using it feels more like a second-class citizen - an after thought experience - because it tries to fit itself within the UI framework of what was originally designed for VSCode. An advantage of it is that it's free. But if you have the licensing budget, go for a tool which is a first-class citizen and purpose-built specifically for the job of being a git UI.
I think Fork is the second favorite tool that's been suggested! (That I didn't know about before) This seems really cool. The first for me is LazyGit because I'm a terminal junky XD But I think I will be suggesting Fork to plenty of people moving forward :)
GitHub for PRs. git CLI for everything else. However, like just about everyone else, I have my own wrappers and environment based on a separate branch for each development project or production triage event, a work tree for each branch and a framework that keeps track of it all. For the interested see my ‘personal’ repo under ‘matthewpersico’ at github.
And emacs is my IDE😉
OMG YOU DON'T USE VIM?!?!?! Haha jk, even Neovim is trying to pull a lot of things from emacs. Emacs can technically do more than you can in Vim or Neovim. I've tried SpaceMacs before and really liked it!
Thanks for sharing! 🔥
Tools or CLI? It doesn't matter that much in my opinion. The basic advantages and challenges stay the same (merge/rebase conflicts, unexpected "detached head" out of sync states), and why isn't anybody mentioning the elephant in the room? GitHub / GitLab or whatever central authoritative hub repository brings back many of the problems we had when using SVN, and why is GitHub so prone to time out over slow networks? They really introduce an unnecessary single point of failure to what was designed as a robust decentral successor to SVN.
GitHub has quite a few problems. It's so trendy. I prefer GitLab personally.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.