Its true -- and actually the well designed gui that accurately depicts the graphical state of your local repository makes it far easier to learn the concepts behind git than does the command line. Distributed vc is conceptually nuanced, but not overly complicated -- the complexity of git really is in the interface wherein you are asked to map command line syntax into abstract operations that manipulate a state that you actually can't easily see from the command line. The value of having a graphical depiction of the state that's changing as you invoke operations should not be underestimated.

http://gitup.co

I love this tool -- it's honestly one of the best graphical tools I've ever used -- rock solid reliable -- intuitive, not leaky in the abstractions it represents -- and not limited to only "simple" operations. And with the graphical reflog history rollback view -- it's always really easy to back up however far you want if you mess up which gives great confidence as you explore the ui's features. Ive taken designers from "never used git" to confidently pushing, pulling, rebasing, and resolving conflicts in less than a day (and most of it after the first 10 minutes without outside help).

Just ran `brew cask install gitup`, cd'd into my repo and ran `gitup`. Took about 60 seconds and so far it's quite impressive.

Clicking on a commit and pressing space brings up a view showing a github-style diff, a list of all changed files, and the complete commit message. Nice.

Thanks for the tip!

Happy to share!

I had to do a site visit with a customer recently and spent some time pair programming on their codebase -- on a Windows machine and they used an awful git client -- really reminded me how much I appreciate using gitup!

Only for iUsers... Really searching for a Linux alternative !

I don't know how it compares to GitUp, but SmartGit works on Linux, Windows, and macOS. I use it on all three platforms and recommend it highly. See my other comment in the subthread for more thoughts about it.

It's not free software though.

True, SmartGit is not open source or free-as-in-speech. It is free-as-in-beer if you use it for open source or noncommercial purposes. I use it for commercial projects and didn't blink at their price - it's paid for itself many times over.

All GUI clients on Linux I tested are plenty of buttons and menus, it makes me cry...

Have you tried GitKraken? https://www.gitkraken.com/

Seems like there's a glut of these apps of late—not that I'm complaining! :-)

It's built on electron, though.

Which, as far as I know, works on Linux.

But is not open-source like Linux and Electron are.

Preach! I absolutely love gitup; all of these slice-and-dice operations that are brainteasers in command-line git are just intuitively obvious in gitup. Absolutely one of my favorite pieces of software, ever.

git is basically a brilliant repo model combined with an insane cli. gitup is the brilliant ui that the repo model deserves.

bonus awesome thing about gitup: it monitors the filesystem and updates its state in realtime, so it it's seemless to mix your workflow between cli and gui.

This looks like an awesome way to learn git, and many would probably love to continue with it - but many others too would prefer to move to the CLI.

I used to use a GUI for git, but now I just find them cumbersome; by their nature requiring me to switch window for less.

I actually used to think similarly before I found git up -- although to me it wasn't about switching window context away from the terminal but rather switching away from the text editor. I imagined that the ideal place for featureful visualization/interaction with the repo would be in the text editor/ide. In reality though -- i really like having the separate window -- it's always there, does one thing and does it well, and it's easy to switch to when I want to take a look at the state of my repo/upstream branches/any dirtiness in my checkout (what exactly have I done recently?). I regularly use three editors when working on different platforms -- Xcode, android studio, atom -- sometimes it's convenient to use in ide repo-driven features (blame, sometimes historical diffs for a single file), however very often I'm actually more interested in quickly seeing diffs for files other than the one(s) I'm currently editing -- so switching to a separate app context that's all about showing repo info tends to be the fastest way to see the relevant info I want side by side without changing away from the editing context I want. More often than not navigating to most relevant diffs within the ide would actually involve more expensive context switching -- for me I'm discovering that it's always somewhat high risk to switch editor contexts -- editing text is just such a powerful interface that it tends to easily lead down rabbit holes that take me further from the most relevant info for my current task context. Once I have the most useful buffers in the right windows, with maybe some reasonable things in the editor navigation stack -- changing the editor views at that point comes with a pretty high risk of straying off task -- or operating for awhile with the non optimal set of editor windows in front of my face -- which at some point I'll realize is dumb/wastes energy and fix -- but energy was already spent in the meanwhile ...

Honestly I'm not aware of any common repo tasks that I could more efficiently complete via the command line vs gitup. There are good keyboard shortcuts for everything in gitup so most everything I do doesn't even involve the mouse.

Also -- I'm the kind of person who's always got a set of terminal windows open and definitely uses them often (almost never use Finder, hate taking my hands off the keyboard to reach for the trackpad). At this point -- I never reach for the git cli over gitup (except when cloning a new repo).

That's interesting. On Linux?

I'm using mac at the moment, and the awful window management (and inability to properly change it - all wm apps just handle resizing and moving within existing spaces and margins) just makes me more motivated to do everything in full-screen tmux, to simulate a decent wm - as long as everything is CLI-based!

(I tried Arch on it for a while, but ended up deciding the firmware difficulties - in particular the battery draining quickly and CPU running hotter - weren't worth it; I traded i3 for full-screened tmux.)

For commands maybe, but nothing beats a graphical history tree. It's hard for a human to imagine a complex branch history without a good visual aid

I agree, and often use a `log --bunch -of --options` alias to view this - but slightly prettier rendering isn't going to make me switch window and back again.

I can't think of a single time I've actually ever cared to look at anything other than a linear history or a single file's blame. I do have a 'hist' alias set up (http://blog.wittchen.biz.pl/basics-of-git/#gist16617665), but it's not something I ever actually use.

Good for you. I'm probably not as smart and more likely to get confused without having the history laid out in the form of a clean, coloured graph. At any rate, it allows me to free whatever brain power I have for other purposes

I had a look at the tool, watched the screencast and was impressed. Then I saw, at the very bottom that this is for Macs. The disappointment...

I have to disagree, I've seen people paint themselves into really hard to get out of corners by using GUI tools and not understanding the underlying tool. git GUIs are leaky abstractions that sometimes even change the meaning of core git concepts. I always recommend people start by using git at the command line until the have a solid understanding of how the tool works before switching to a GUI.

Yes. I teach git professionally and when I do, my approach is to stick to describing the nuts and bolts. Once people use it from the command line and get things done, they (usually) understand what's going on pretty well but are annoyed by the nitty gritties of the command line. Then they're ready to move on to a tool of their choice but can always map the actions there back to the data structures inside git so they've never lost. Also, they can always drop back down to the command line for any low level surgery that the client doesn't provide.

I use magit myself for most things.

I completely agree with this one. I encourage our developers to always use the cli, even if they are not familiar with the core concepts of git. I see myself as a mediocre git user, but there are some situations, however, where I prefer to use a GUI for more complex operations, like staging/un-staging specific lines or create/apply patches.

I'm with you. I've been using SmartGit for years and would never go back to the weak sauce of the command line, except for a few odd things that SmartGit doesn't cover (like bisect).

Every one of the tasks in the article is a simple, straightforward operation in SmartGit. Take "I accidentally committed something to master that should have been on a brand new branch!" or "I accidentally committed to the wrong branch!" for example.

Instead of an obscure series of four to six commands, you simply go to SmartGit's log view and drag the branch markers to where you want them. Easy and intuitive.

I know GUI tools are a hard sell for a lot of programmers. I honestly don't understand why. I think it may be the fear that you'd be giving up power, but SmartGit isn't a dumbed-down GUI. It gives you a more powerful set of tools, and much more visibility into the state of your repo.

You're not even giving anything up. You can still use the command line whenever you want, and SmartGit shows you the commands it used to accomplish each task.

Of course you still need to understand the underlying Git concepts to use any GUI effectively, but a tool like SmartGit lets you see those concepts.

I've worked with a guy who only uses GUI tools for Git and he's supposed to be a senior dev and doesn't know how to resolve a simple merge conflict and regularly wipes out other peoples' work with whatever he's doing with the tool.

No thanks.

Anecdotally, it's even easier to wipe out other peoples' work with the CLI.

Agreed, but then it's harder to blame the tool they use instead of themselves.

I agree. If you use something like SourceTree, you can also see the git command, in case you end up needing to know what it is. Best of both worlds.

I mainly use the GUI for day-to-day stuff. Only in rare cases will I need to mess with the command line.

I like to use a GUI for things like viewing staged/unstaged files, their riffs, and picking which files to stage for a commit, but for every other situation, the command line is just so much faster and easier to understand what's actually happening.

I stopped using a GUI (SmartGit) when I encountered an error which was talking about stashes and something like {0}. I had no idea what the error was. Now I know how these tools work but I think that you can only use them effectively if you learn how they work and how the underlying system works. If you fail to do so you end up with a leaky abstraction which will at some point (and believe me it will) present you with an error message you don't understand and you end up with a problem you can't recover (yet). GUIs are fine but only if you know the ins and outs of the underlying system.

Agreed, a GUI have most of the functionality and a clear visual representation of the state of your repo. When it's not enough the terminal is once click away

Interesting. I've always been too scared of git GUIs to seriously try them out. The fear being I will somehow mess up the repo by using the GUI wrong.

I am surprised that somebody claim that has messed up a git repo. Since I started using git, I haven't ever messed up with my code.

I always use git on the command line. Regarding GUI tools I like to avoid them, for me is too much noise. People get lost most of the time because they don't know what the tool is doing. After all is just one more layer on top of git core tool per se (aka, what you have in command line).

I've never really screwed it up that badly using the command line either. I don't know what these people are trying to do that they constantly mess up their repository so bad they can't fix it. Perhaps being too obsessed with having a perfect commit history.

I'm curious: What are the best free GUI for Git?

I'm surprised nobody mentioned Git Extensions yet. My absolute favorite Git UI, better than my previously favorite git-cola.

https://gitextensions.github.io/

I'm a big fan of GitLab. Clean design, intuitive interface, many features.

Disclaimer: I'm now a GitLab authorized training partner and reseller. The community edition is free. :)

I'm a fan of tig on the command line and Gitbox (Mac GUI).

gitk - it's built into git, and supplements (not replaces) the command line. It does tree visualization and diffs between commits.

Magit

Sourcetree, if you are not on Linux like me :(

I've seen repos completely borked because the gui kept a merging and pushing in the background. This was after spending a lot of time removing binaries from a repo and not being able to figure out how the same binaries kept ending up back on origin.

Sure, it's harder to screw up. But, dang it's just so remarkably slow.

If you're used to the commands from the keyboard, where you're likely already typing from your editor...can't imagine going back to the GUI.

I agree, and while I have not tried the other apps mentioned here, I do rely extensively on Atlassian SourceTree client for Mac and find it very useful.

I feel more comfortable and faster using git commands that a GUI.