Hacker News new | past | comments | ask | show | jobs | submit login
Oh shit, git: Getting myself out of bad situations (ohshitgit.com)
1209 points by adishaporwal on Dec 18, 2017 | hide | past | web | favorite | 508 comments

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second.

I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI.


- My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.)

- I don't remember the last time I made an irreversible change to the repo, or had an "oh shit" moment. And that's despite using some interesting git features.

- Staging individual files, folders, lines of code, or hunks is easy. Makes maintaining multiple trains of though / addressing bugs while working on other code a non-issue.

- It's easy to keep files uncommitted for long periods of time intentionally, without slowing down my workflow.

- It's much easier to get an overview of the changes I'm making.

I use the git CLI. I do it for one reason. I know exactly what i'm doing on it. I have nothing to prove to anyone, I'm not trying to impress anyone with my "hacker" skillz.

When I've tried GUI's, I'm not 100% sure what's going on under the covers. Sometimes they try to obfuscate things. While I'm probably not the worlds most advanced user, I know enough to know what I want to do, and how to do it. The CLI let's me do it. The GUI get's in my way.

It's not anything inherent to a visual UI though, it's just that most of the UIs that exist are trying to put their own model on top of git, rather than embracing git's model.

The one exception to this I've found is GitUp (mac only, sadly), and it's excellent. It's whole model is, "what operations can I perform on this graph," which is exactly the model git has. It's great.

I think you've put your finger on the schism of why so many git users prefer a GUI. The built-in porcelain is stupidly inconsistent and confusing. And yet, git's underlying model is so simple and powerful that I think it's worth suffering the bad CLI just to be more fluent and able to utilize git's power fully. The model itself is very easy to grok, it just takes some time to memorize the various random incantations and occasionally look something up, but I don't consider that a big deal for a core tool I use every day.

"C language is so simple and powerful that I think it's worth suffering the bad syntax and memory leak just to be more fluent and be able to utilize the machine's power fully."

Pick the right tool for the right job, man.

Joking aside, think about the ratio of tasks. Most of the git commands I do is deadly simple. There might be once-in-a-year complex tasks that are more suitable to CLI, but for 99% of the tasks I think GUI could have a net gain in total. Although I'm not a GUI user in this particular case, I'd advocate to use whatever most intuitive to you when possible.

Disclaimer: I don't think C syntax is that bad.

It seems like the other way around to me. For 99% of simple tasks, the cli is quick and easy. There are a couple of simple commands, I know and remember them. For the once-a-year complex tasks, maybe I need the gui to be able to more easily and quickly accomplish them.

It might not feelblike that big of a deal, but certainly there has got to be on any given day far more important things you can use those brain cycles for, yes? Low friction or not it's still friction. Friction that can be removed. Yet so many refuse to do so. There's something wrong with this this-is-how-we've-always-do-it picture.

You make it sound like tradition or a cargo cult—it's not. Git is fundamentally better than most of the alternatives, but in my opinion it's misguided to try to slap a better interface over the warts. Rewriting the porcelain would be good, but I don't think it's personally worth investing in until someone makes an attempt that's good enough to get traction and significant mindshare. In the meantime I've already made the investment in learning git and it pretty much stays out of my way.

Not to sound snarky / adversarial but why is it that (nearly) every article I see on Git has some sort of diagram within it? Yet "execution" is typically limited to CLI? That just feels suboptimal, if not just foolish.

> Yet "execution" is typically limited to CLI? That just feels suboptimal, if not just foolish.

It looks like you mindlessly associate a CLI with a poor -- or suboptimal -- user experience. In fact even your choice of weasel words conveys the idea that you want to mindlessly push an irrational belief in spite of not being able to provide arguments to support it. The truth of the matter is that git -- or any other VCS -- operated through commands that change the current state of the repo. The command line interface excels when the user wants to run commands. Any GUI developed for command line tool will end up doing nothing more than replicate what the CLI already does, and will do so poorly.

Not really. I associate a picture with 1000 words. So if the detailed example/ explanation is an image why isn't the actual process(es) a reflection of that?

Put another way, Git is a process that can be rendered pictorially. Words (i.e., CLI) are a less intuitive abstraction.

Pardon me for stating the obvious :)

The issue is with understanding staging and the working directory. The lightbulb moment for me was reading this article from Atlassian:


Understanding that git reset --soft moves HEAD but doesn't change the staged snapshot or working directory, whilst --mixed updates the staged snapshot to match the commit but doesn't touch the working directory was very useful. And knowing that reset --hard updates both staging and the working directory to the commit was where I suddenly "got it".

Right. And notice all the diagrams. So why use words when pictures better reflect reality?

> Git is fundamentally better than most of the alternatives

No way. Only if you define “good” as “good at the kind of project that git is good at,” where it will hold vacuously.

I suffer daily through the cyst that is git LFS, and it’s a joke. It would be funny if it weren’t so tragic. I hear that it’s not doing any better in large scale mono repo land. Google doesn’t use it, afaik. Microsoft does (but multi repo, last I heard), Facebook doesn’t (custom Mercurial, some tasty quotes at [0]). Not a glowing “fundamentally better”, exactly.

[0] https://code.facebook.com/posts/218678814984400/scaling-merc...

That's a fair criticism for sure, git makes tradeoffs that fall apart with large repos. You can, however, go a whole career without those things being a problem. Most code repositories are simply not that big.

And you can go a whole career without needing the extra staging features that git has and some other systems like mercurial don't. The ui gets a lot easier without that and for many developers that is probably the best trade off.

1. Git LFS is not part of Git. It's an unofficial extension, despite the name. I've got my own qualms about Git, but that's like complaining about GitHub's forking model as a reason Git is bad.

2. Microsoft uses Git in single large-scale mono repo form, for - believe it or not - Windows. It clocks in at about 3.5 million files, and a full clone weighs in at 300GB:


Microsoft uses Git in single large-scale mono repo form

They had to change git itself to be able to do that. So no, the article itself shows it was not ready for that big a repository.

Git LFS is not part of Git.

That’s my point: without LFS it’s even worse to work with large files. If LFS is the best option you have, forget it. That’s an entire area of projects (anything with assets) you can’t use Git for.

I believe MS has most of windows in a git mono-repo now, enabled by a custom git-supporting filesystem they've developed:


Pretty cool stuff. Doesn't seem to address the large-files case so much as the many-files case, though. I would love better git support for large files.

> The built-in porcelain is stupidly inconsistent and confusing.

That's why I end up using the plumbing commands to do things that porcelain commands don't let me do directly. For example, I'll use git diff along with git apply and recountdiff (from the patchutils package) to stage individual hunks or edit hunks prior to staging.

One could also setup aliases for some of the incantations. I personally have `git uncommit` aliased to the proper command line that I never remember.

I use aliases for the most common commands, gs, gd, gb, gco, ga, gc. You can guess what those do.

The way you confuse git porcelain with git CLI makes it quite clear that you know nothing about either. I'm yet to find a GUI for any VCS that comes close to doing a job as good as any CLI.

One way to make yourself feel superior to others is to adopt a level of pedantry that only you yourself can meet your own standard. If you then assume everyone around you is ignorant you are not as smart as you think.

git porcelain is a CLI. I am well aware that it is only a subset of git's CLI.

SourceTree keeps the same language regular git uses. But I highly agree. JetBrains IDEs add their own lingo out of support for multiple version control plugins I'm sure but its confusing and easy to screw up. SourceTree is the one GUI client I want on Linux...

This is one time when we wish source tree was written in electron!

VSCode is the only Git GUI that you need and it's available on Linux

Do you use it? I have it enabled, but when I tried to revert a few lines (which should be the simplest operation ever - NetBeans did it perfectly; may it rest in peace...) I got some horrific message that made me doubt what the operation will do. So I haven't gathered enough courage to try committing anything... With CLI at least I know what I did wrong.

VSCode doesn't consistently use git's language afaik, I could be wrong though.


This looks fantastic, thanks for mentioning it! I've been looking for a GUI that doesn't mesh poorly with [whatever patterns my team uses] / without always pushing other features or a signup.

Thanks for the recommendation. Fantastic looking software that provides a far better visualization of the repo than anything else I have used. Bravo.

I use CLI for almost everything but sometimes it helps to have a visual representation of the repo.

It's a really sweet piece of software, and I'm surprised it's not more popular. I'd be curious to hear how it ends up going for ya'll -- you can message me on twitter at @hazememry if you'd like.

So far I've found:

    it's reasonably fast until I throw it at a huge monorepo :)  but it still works (~2fps)!  even `gitk` errors on this one.
    missing some hotkeys (like prev/next commit buttons in preview)
    freezes on remote-repo actions like fetch/pull/etc.  likely due to our enterprisey ssh setup.
    generally missing a bit of polish.  click targets are small, could use some more config (and only in one location, "search commits" is in its own thing), etc
Aside from the remote repo freeze-up, I'm liking it a lot. Way better control than others I've tried (i.e. it has nearly all the features), undo support, and a much better mental-model for Git in general.

If I can figure out how to fix the remote freeze-up, it might become my daily driver, which would be a first for a Git GUI.

Yep, doesn't scale great to huge repos, sadly.

I hadn't thought about the prev/next preview missing hotkeys, but you're right. I realized what I do is go into preview with space, leave preview with space, and then use the arrow keys to select the next commit I'm interested in. So in effect, "space, down, space" is hotkey for next commit.

Bummer about the remote freeze thing. I think the dev is reasonably responsive to bug reports.

I've got a list of things myself I think could be better, but I've been too lazy to attempt any of them. But I do try to proselytize in the hopes it'll pick up a bigger community. :-)

I thought it's nice too, and just downloaded it to find out it's Mac only.

Yep :(

I'd thought a programming language, for manipulating data structures, would work well... but when I had a go at it, it wasn't as easy to use as I thought. It's because the typical usage patterns aren't simple.

A gui with drag-and-drop to rebase a graph also seems like it would work well...

I was in the cli only camp, but I just looked at GitUp and that actually looks really useful!

There are GUIs that are very close to CLI that don't try to reinvent a wheel and instead just map directly to what git does.

The best one, I think, being Magit for Emacs (if you can call that a 'GUI' given you can run it in the terminal).

If you get used to commit things by-line instead of by-file (which is generally highly recommended with git), and also clean up your history/squash things a lot, using git cli gets VERY tedious very fast; I'd rather do it in several keypresses because why not.

Sort of off-topic, but magit isn't really GUI :-) -- though it is very nice, if you're an emacs user. It's Achilles' heel is speed, though -- too damn slow. (Last time I tried it, anyway, which was a while ago.)

I think Magit could be classified as a TUI [1].

But that still doesn't help explain its benefits to someone who hasn't tried it. For the crowdfunding campaign that I ran earlier this year I wrote a few articles. For those unfamiliar with Magit I would recommend [2] and the more visual [3].

[1] https://en.wikipedia.org/wiki/Text-based_user_interface [2] https://emacsair.me/2017/09/01/the-magical-git-interface/#st... [3] https://emacsair.me/2017/09/01/magit-walk-through/#start

Well. That depends :) I don't develop in Emacs and use it solely for hosting Magit, in a separate window. So it's kind of a GUI I guess; more so than a CLI anyway.

> It's Achilles' heel is speed, though -- too damn slow. (Last time I tried it, anyway, which was a while ago.)

Don't remember a single of case of it feeling too slow in the last few years, whether on linux/mac... (maybe it just got better over time though)

interesting. i'm on mac; i'll have to give it another try. also we might just have different ideas of "too slow"; for common operations, anything more than instant is basically too slow. :-)

On macOS it helps to use Emacs 26.1 (unreleased but very solid) or to use a build with a backport of the vfork patch. For more information see https://magit.vc/manual/magit/MacOS-Performance.html.

I also plan to make Magit faster across all platforms.

very cool to hear that performance is a focus area!

It seems to be incredibly slow on windows, but fine on linux.

It seems like the sort of ui that needs to be near-instant in order to be usable, the premise being you can tap the various shortcuts to assemble a command very rapidly. But on windows this is an exercise in frustration because each command takes at least a second or two at best to execute and often much longer.

It's a Graphical User Interface.

I think that the distinction that makes a Commnad Line Interface is the REPL.

I consider anything with a non-linear UI that you can see a GUI.

GitExtensions was/is solid too; very little abstraction, it was just built for speed/efficiency. Someone recently told me it runs on Mono too now, but I haven't used it in years and never outside of Windows.

> I'm not 100% sure what's going on under the covers.

This. A thousand times over. I like to see exactly what git is doing and when; I don't want any magic stuff under the covers done for me.

GitHub's GUI is the worst. It has a "sync" button.

As soon as I saw that button I knew I'd have trouble using it.. what will "sync" do? Push my branches? Pull tracking branches? Will merge commits get implicitly created? Or will it just fetch? From what servers? I didn't want to risk having my local master get pushed into production just because GH wants to make things easy for me, so I just quit it and went back to the CLI.

GitHub's Atom editor recently added git operations. I use Atom but haven't had the time to try the git wrapping. Has anyone else used it?

It just pushes the current branch afaik.

So they should just call it 'push'. The word 'sync' is not in the Git terminology.

In its defense, git terminology is stupid. It took me way too long to reason out what the fuck a pull request meant. To your starting developer it seems to indicate the opposite of what it does.

The GitHub desktop client is very limited and seems mostly geared toward a lone developer or small team who has never used git before. In this context I think it's a reasonable decision to use a more common verb.

Nope. That does no one any good. Using git verbage would, at the very least, acclimate them to very common terminology used by the rest of the folks they will eventually encounter.

Well, I disagree, because the alternative for many is probably no source control.

Folks writing production crap would opt for no source control? Well, fair enough I guess. But I (and probably most competent sw engineering folks) would never hire someone who was completely oblivious to using source control. So hopefully that 'practice' would die through attrition.

You've got to meet people where they are. Someone who is familiar with how git works is going to find the git GUI client way too limiting to seriously consider using it, whatever verb they use for the push function.

So it never pulls updates on the remote? That seems like pretty unexpected behaviour.

It pulls and then pushes, I guess I should say, but I was considering "pulls and..." part of the push operation.

CLI and GUI are both user interfaces and magic is in the eye of the beholder: if you know your tools, you can predict what will happen under the hood when you click on a button as much as when you submit a command (it's not magic anymore).

Personally, I use the CLI and often have no idea what I'm doing ;)

Even GUI based SQL tools show you a log of commands used... Git GUI clients don't even show you beforehand or after what the heck just happened... Sad.

It's definitely not true. I'm not sure what kind of gui did you use but both sourcetree and gitextensions show you the command log.

Guess I was wrong, but I never noticed said log. I use SourceTree.

Same here. Regrettably, if you UNDERSTAND git, a GUI won't work for you. If you're interested in understanding it, it won't work for you either.

A GUI works fine if you want to get things done. If you like to know what goes on under the hood, it's just confuse you.

I understand git quite well and use a GUI. I was interested in understanding it while using the git.

It's pretty sweet that GitExtensions displays the exact command executed. Actually, it made learning vastly easier for the people I taught after myself.

Some people do better with GUIs; others the CLI.

I feel this has become a bit of a standard excuse for git. The reason I use a gui isn't because I don't know how git works (while I do forget that too from time to time), but because I can't remember the default behavior and notation of the git cli. I'd be perfectly happy if the cli was actually made to be "low level", but it to a large degree isn't. So if I'm going to have to remember what some abstraction does, it might as well be on a higher level.

One example of this is the table at the bottom of this page: https://git-scm.com/blog/2011/07/11/reset.html

The git CLI is horribly inconsistent.


You might want to try Sourcetree if you haven't already. I felt the same way about Git GUIs for a long time, but Sourcetree actually does a good job of getting out of my way, and has a very nice commit history tree viewer to boot.

Actually I find Sourcetree one of the worst git GUIs out there. There are just so many bugs and kinks and glitches in it that I avoid it if possible.

I do like the Gitx-dev fork by Rowanj [1]. Clean and simple. Unfortunately just for Mac OS though.

[1] https://rowanj.github.io/gitx/

I haven't encountered any of these bugs. But I do use it only rarely, the CLI is where I live most of the time. Good to know about alternatives.

I've found Sourcetree to be way too slow. My team is currently using the GitFlow model, for various reasons, and that involves switching between branches fairly regularly. It also means that any commit to master involves a lot of steps. From the command line, this isn't a big deal because each of those steps takes a half second or so, but Sourcetree multiplies that by an order of magnitude, and the Sourcetree users are nearing a point of mutiny.

Source tree is the slowest software that I ever used. Git extensions is much much faster and I never had any performance problem with it.

I dislike SourceTree precisely because it uses git terminology. Git’s terminology is bad enough, but it completely breaks down for me in a GUI, because I expect that GUI’s conventions there. For example, on the Mac (as in English, I think), a command named “Remove” removes an item from a containing item. “Delete” also destroys the item. SourceTree, however, uses “Remove” for “git rm” because Unix thinks “remove” destroys items.

To make matters worse, what in a Mac GUI would be called “Revert” or “Discard Changes” is called “Discard”, something that, to me, feels more destructive than it is.

End effect? We have “Discard” being less destructive than “Remove”, while, to me, it feels the other way around.

(I may remember this wrong, but if I do, I think that’s a sign of the problem of not following platform conventions in your software)

Not available for Linux, which is a damn shame.

I like fugitive - it feels like cli git without having to leave the editor. GAdd adds the currently file/selected lines, GBlame pulls up git blame information the ability to reblame, GStatus show the status with the ability to jump to/stage/unstage files and so on. Tried Magit for a while but it didn't play nice with evil.

Still hoping for a git repl that just does graph queries/transformations though.

I use both.

Staging, especially partially staging hunks and lines when doing multiple things at once, is way easier in a GUI when you can scroll around for context and easily undo.

For everything else I prefer the command line, because it's faster and I know exactly what is going to happen. I can do what I need to do, no fighting. If I'm just committing everything, I use the CLI. If it's more complicated I use the GUI to stage and commit, and a CLI to rebase/merge/push.

I use sourcetree, but I would like a console feature that shows me what commands its running. Similar to sequel pro's "console" feature shows the raw sql being run.

There's an option in sourcetree, "always show output". This will keep the window that runs the commands open so you can always see what it did and git's output. I always keep this enabled.

the commands themselves are not actually the lowest level, though! (and in fact, are kind of crazily mixed togther; most of the trouble people have w/ git is bad UX for the cli, imo.)

True. Inconsistent and unintuitive options, oddly named commands (and this is coming from someone who enjoys using Unix clones).

How about if someone made a GUI with a console at the bottom that showed the commands being executed along with results?

I like typing and I don't think it slows me down too much, so I pass. But it's a good idea.

This is exactly the same reason I too use CLI. But a word of caution Git Bash on windows has some serious problem(s). I remember, I lost my commit and in reflog it doesn't show up on CLI, however GIT UI showed the same! Not sure what's the issue, but it occurred for me twice.

XCode rolled out a feature that allowed you to do an interactive commit just by click on/off switches. My first use of that feature screwed up the repo by committing the wrong pieces.

No thanks, it’s CLI for me, regardless if the IDE promises git support.

The problem, as I see it, is not with the GUIs, it's with the CLI. Just look at the `reset` command: it does several different things, depending on what switches you give it. How would you represent that in a GUI?

Some git guis log the git commands they execute. Just look at those.

I use either the GUI on Windows or a set of batch files I wrote to automate basic things.

As long as all you're doing is pull, branch, merge and commit, I don't think it matters.

You're entitled to your own opinion of course, but you underestimate the efficiency of the command line, especially when you already have one open for other development tasks.

I use one or more GUIs for visualizing branches, and old branch cleanup, and yes, committing single lines from hunks that can't be split.

However for everything else CLI is fairly close to optimal, including interactive adding/rebasing, and don't want to use whatever shitty editor your tool has in it, I want to use vim with syntax highlighting so I can properly format my commit messages. Even something as simple as viewing a full commit is faster in the CLI because you can just pipe it to less or send it to an editor versus whatever tradeoffs a GUI has to make to stay performant, make use of screen space, etc.

One last tool is Fugitive. This blows away anything else I've ever seen for interactively traversing history at the line level.

> committing single lines from hunks that can't be split.

Could you elaborate here? Personally I've always been able to commit just the pieces I need via `git add -p`. Never had problems staging a single line before.

Since this is text I should say: I'm not doubting you, I just like to know the limitations of the tools I'm using.

`git add -p` adds by the hunk, which is a unit of quantization bigger than a line.

E.g. if you have two consecutive lines changed, it's not possible to split them, they are one "hunk".

(Waiting for someone to chime in with how to split a hunk and change my life).

You use the 'e' option which allows you to edit the hunk. Remove the minus sign or the entire line with a '+'

Within 'git add -p' when you get to the hunk that you want to edit (split down to single lines), press 'e'. This will open an editor (vim in my case) which lets you edit the diff manually.

In there you can remove added lines (prefixed by '+') by removing them, and re-adding removed lines (prefixed by '-') by replacing the '-' with a space ' '.

And how is this faster/better than selecting a line with the mouse and pressing s without opening any other editor?

Do it in Vim (or emacs for those weirdos out there) and you're done before you would've even reached the mouse :)

Sometimes your changes are across multiple files, and it's easier to say, "yes, yes, yes, yes, split, no, no, yes, ..."

You can use 's' to split a hunk but it would indeed not work if you want to split two consecutive lines.

You can also use 'e' option to edit the hunk to e.g. remove one of the added line.

Nothing as easy as clicking a line in a GUI though.

Say you have 3 sequential lines, but you only want to stage the middle one. You can’t split it into smaller hunks by hitting ‘s’ during ‘git add -p’. I’m sure there’s a way I’m just not familiar with but I just use Sourcetree for this on the rare occasion it occurs.

You can split hunks manually by editing (hit “e” instead of “s” during staging). I end up doing this fairly regularly.

i think that’s his point? there’s a huge amount of useful, but advanced functionality in the git CLI

As mentioned before, manual edits can be made at that point. However I'll add that for this use case, a tool integrated in your editor will often be more adapted to manual staging. I have Tim Pope's vim-fugitive plugin in mind which is a quite wonderful way of using Git.

You can also manually edit the hunk to remove the 2 lines you don't want to stage and use the recountdiff utility to update the hunk header.

  > Fugitive
That's interesting. I switched back from emacs to vim (neovim), and fugitive was recommended. it just looked like :commands for the normal git cli... maybe I missed something.

So even though I edit in vim, I jump back to emacs for magit for bigger commits or multiple smaller commits (where I need to see diffs to be sure I capture my changes).

I have desired something as useful in vim, but I didn't think there was anything. I'll take another look at fugitive.

You may want to give a try to vimagit so. https://github.com/jreybert/vimagit/

As soon I started to work with git, I installed fugitive. My learning curve of fugitive has been slow, and I have never be able to stage efficiently with it.

And then, a colleague showed me magit: I waited for a year that something similar comes to vim, trying to push this idea to fugitive https://github.com/tpope/vim-fugitive/issues/569 , without success.

Finally, some first experiments showed that partial hunk stage was feasible, and I created vimagit.

As you will see, it is far from whole magit features. For the moment, it "only" focuses on stage/unstage and commit feature (which is the main use case to me). The current workflow is quite robust: you can easily navigate through all the diffs to review them, stage by file/hunk/line/part of line, write the commit message (or amend the last commit), jump to the diff locations in their files... I continue to use fugitive for Gblame and Gdiff.

Next major features should be git stash (be able to prepare a stash like a commit, by file/hunk/line) and some git log related feature (to easily git commit --fixup a chosen commit in a log for example).

Yeah, fugitive seems pointless to me. Might as well just use the git cli...which I do, but when I want something quicker to navigate/visualize, magit is my go to.

See my comment in sibling thread. I am not familiar with Magit, but there's no equivalent on the CLI to Fugitive's flow for rapidly traversing history, it's really really useful, and lets me answer questions that other devs on the team just throw up their hands because a line may have traversed several different files over dozens of commits throughout its history. The reason it can't be done on the CLI is because you need multiple buffers and window management to make it viable.

All that said, I don't really use it for committing, mostly because I have a shell open right next to the editor anyway.

> One last tool is Fugitive. This blows away anything else I've ever seen for interactively traversing history at the line level.

Sorry if I'm being think, but how do you do that? Are you talking about Gblame?

Yes, Gblame then in the blame pane ‘o’ to open the commit, then in the commit pane navigate to a file name and ‘o’ to open the old file, then rinse and repeat. You can trace line history across files this way.

I've become a big fan of Git Extensions. I like that it doesn't try to layer its own agenda over the Git workflow, shows all the console input/output it uses, and warns me when I'm about to do something stupid, but overall I like it for the same 3 reasons that I like most GUIs:

- It's a live dashboard. A GUI gives me live, persistent information organized well on the screen. I appreciate the power of the CLI for accomplishing tasks, but I've never understood how people prefer it when it comes to simply viewing and understanding the state of something. I don't see why I'd want to run a bunch of commands to see stuff scroll by in my format-constrained terminal when I can have a live, all-up view of multiple aspects of a repo all at once, with relevant, context-sensitive commands on whatever I click on.

- It's discoverable. Most of what I've learned about git has been through clicking around in Git Extensions.

- The structure and organization of the UI helps me to understand how git operates. When I open the "Pull" dialog, for example, the way the controls in the UI are grouped and the kinds of controls that are used help me logically understand what "Pull" can do.

What GUI do you recommend? My experience has been that GUIs are the easiest and fastest way to make a mess that can't be corrected without dropping to CLI or re-cloning. (I'm looking at you SourceTree). I've long recommended that everyone who uses git know how to use the CLI even if they don't use it regularly.

I'd like to also point out tig. "Tig is an ncurses-based text-mode interface for git"

It doesn't have all the bells and whistles of a GUI, but if you need to look at all the branches, and commits to a repository. tig is an excellent tool. tig doesn't issue any commands though, its only a browser, you'll still need to know the CLI. (essentially a ncurses version of gitk)

I'm normally in a ssh session on a remote box where my compile & run cycles happen. tig is curses based, so no X11 needed, filled in a really nice itch of mine.

[1] https://github.com/jonas/tig

+1 for tig. I'm also a big fan.

I tested a bunch of Git GUIs. My requisites:

- Open source (and free) - Multiplataform

The one with the best usability was Git Extensions: https://github.com/gitextensions/gitextensions

It is somewhat old ugly, and open a little too much of dialogs, but the workflow really works. It guides you to make the right thing.

A great plus is that it already comes with Kdiff3, a great open source 3 way diff open source program.

Agreed, Git Extensions taught me Git visually rather than through a tutorial.

The Git GUI that ships with git is very good. It also shows how Git thinks (workspace/staging/commit) that most other gui's struggle with (they try to make it look more like a SVN workflow). For diffs and blame I use TortioseGit. I also extensively use the CLI for most branch actions.

If you're on a mac, I can't recommend Tower enough. It's a paid app but well worth the money. Otherwise Git Kraken is a foss offering that is also excellent.

Git Kraken isn't FOSS. The site says "Free for non-commercial use", and AFAIK the source isn't available anywhere.

I think maybe the term you're looking for is "freeware"?

Ah, you're quite right. I was under the impression it was FOSS - I used it a while ago, preferred Tower and so went back to that.

I second your recommendation of Tower. About a year ago, I made a comment right here on HN singing Tower's praise names. [0]

It's impossible to sing those names loudly enough.

  [0] https://news.ycombinator.com/item?id=12677542

Apparently, there is now also a windows version. https://www.git-tower.com/windows

Thanks, I had disregarded Tower until I saw your comment :)

I want to second that. Also the integration with diff tools like Kaleidoscope is a nice touch. (Even though Kaleidoscope feels like abandonware at this point)

Gitup is free and probably better.

Thanks for the tip, I'll have to check it out.

How is atlassian's Sourcetree?

I like it a lot, it make git as simple as mercurial. I don't think it is hiding complexity, but the visual arrangement makes sense. The staging area becomes actually useful, and I love that you can stage (or revert) pieces of a file, which is handy when you forgot to commit one thing before moving on to the next.

I've only had to merge a branch once, and here I was completely confused on what was going end. This may be SourceTree's fault or git's fault. Maybe my lack of understanding.

I hate git, I don't understand git, I don't want to have to understand git, and I think the command line interface makes every UI error in the book. But SourceTree has made me like git.

We have a bunch of projects that are stored in a mercurial repo so I've been using Sourcetree for that as I've found MacHG pretty unusable. I think it's pretty good, not as good in my opinion (the UI, mainly) as Tower for Mac which I use for Git, but makes Mercurial easy to use for this (somewhat) hardened Git user.

Incredibly slow. I was never annoyed so much when using a software...

> What GUI do you recommend?

I really like Magit, which is a git GUI you can use without leaving Emacs. It handles 90% of my git needs and is very tightly integrated into my IDE (Emacs). I still use some shell commands (like git mv) occasionally but those are simply m-! away.

Second that; I'm using Spacemacs just for Magit and nothing else, although it's mainly vim or clion for development. Haven't seen a single git client that would be close to Magit; too sad it needs Emacs, could have potentially been an awesome standalone...

Magit in emacs. Probably one of the killer applications for emacs.

+1, along with Tig (console gui).

Thanks for telling me about tig, now I'm justified for having browsed HN today.

It treats my "assume everything works like vim" habit well

tig is great -- it makes it very easy to stage individual lines of code (using 1) or to reset unstaged changes on a file (using ! in the status view).

it covers like 80% of my use-cases (which I use 99% of the time), and weirdly magit gets me the other 20% if I can remember which trail of breadcrumbs I follow through helm to make it happen. For the easier stuff I just drop down into the cli though.

I love tig!

Agreed. Best git interface I have ever used.

I'd hesitate to call Magit a git GUI though.

If we take Ranger for example, who calls itself the "CLI file manager", then Magit is rather a "git CLI".

>I'd hesitate to call Magit a git GUI though.

Why? It is designed for git and graphically displays revisions allowing you to pick and chose chunks of file and to revert individual changes.

I use sourcetree and it's pretty great, especially the aforementioned block-level staging.

Not the OP, but git cola works great for me.


I personally switch between the command line, git gui and gitk. I haven’t yet found a suitable GUI replacement for those two.

I use TortiseGit in my personal and work dev environments. It works works well. That being said, I have had to drop to CLI to fix things that were somewhat more hairy.

Tortoise was great on Subversion, but I don't like it for Git. The UI in thought to work with a centralized version control is isn't well adapted to Git.

My company uses Mercurial still and TortoiseHg is the best thing about it. I can sling big piles of commits around, patch, graft, and search, it's all so easy. I hope it works as well for Git or Git can catch up.

I recommend SmartGit; it's not cheap, but it's really, really nice.

SmartGit is really nice.

It's also free for hobby / open source

but worth buying for commerical work, but it is pricey, and I think getting the lifelong updates is the way to go.

SourceTree by Atlassian ... free.

For any Windows users out there, I use GitExtensions, which has served me very well over the years.

I use SmartGit. Way faster and more stable than SourceTree and GitKraken, in my experience.

+1 for SmartGit, and SmartSVN if you ever use SVN.

VSCode or Github Desktop (even if the project is on Gitlab).

Not the OP, but I had come from SourceTree to GitKraken and it's a joy to use.

Same for me! I used SourceTree in the past but at the moment I am using the free version of GitKraken for private projects and I am very happy.

I like GitKraken

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI.

Or, you know, understands and thinks in the semantics of the underlying tool and is already working in other text-based tools.

Or, you know, that is irrelevant when the person using a GUI makes fewer errors than those who aren't (which has broadly been my experience as well).

Even someone who perfectly understands git can make a typo or have a brain-fart of a day. A GUI significantly reduces the chances of something like that for all users.

Sometimes dev obsession with tool purity does more damage than good.

You're always one git reflog away of undoing the brainfart. Once you know the CLI well enough, you manipulate the git data model easily. When you're using a code review tool like gerrit, it's impossible to do something you can't undo.

A well made GUI conveys those semantics more clearly than the default command line interface. Automation is easier from the CLI, but I wouldn't be surprised if a GUI turned out to be best for manual interactions.

(Note: I use the CLI almost exclusively.)

Conflict resolution in a GUI with 3 way merge really beats out a command line.

Doesn't really make the interface any less crap; though I've yet to see a GUI that didn't shell out to the command-line interface (which almost always makes them very unreliable).

I believe GitUp directly links to git library and doesn't use a command line shell.

Yes, GitUp actually ships its own git library.

Yeah, I would guess that the parent commenter has a heavily graphical workflow based out of a big honking IDE like IntelliJ. For people doing development in a console anyway, it would take more time to start a git GUI and wait for it to launch than to be done committing and pushing from the CLI.

The counter argument is that if you make an error using the CLI, you end up spending more time fixing it than if you just had the GUI open and watching your repo already, and simply switch to it when you need to commit/push.

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI.

Nah, it’s just a lot easier than you make it out to be. GUIs are fine too, but if you read the documentation and don’t just memorize a fixed set of commands there’s nothing dangerous, slow, or inconvenient in going about a standard workflow using the CLI.

And yes, lots of people don’t have time for this. Totally okay. Don’t generalize to “anyone who uses the CLI is trying too hard”.

My biggest issue with a GUI is that most that I've seen introduce new terms for various stuff, e.g. "sync" in VS Code, or "revert commit" (in Source Tree maybe?) — there's no Git command called "sync" or "revert", so I'm not immediately sure what they do.

In a CLI I know exactly what's happening.

That's just my opinion though. If people feel comfortable working in a GUI all the more power to them.

Git does have a revert command.

Yeah, my bad. Must've been "reverse" then. I just remember the revert/reverse dichotomy.

Or perhaps it called revert but it wasn’t doing a git revert, it was doing a git checkout to simulate an SVN revert... I’ve seen this in at least one GUI. That kind of crap just makes it harder to unwind problems when things go wrong and to learn the tool.

> no Git command called ... "revert"

Maybe not in the way Source Tree uses it, but there certainly is[1]! I've had to use it a few times.

> git-revert - Revert some existing commits

[1] https://git-scm.com/docs/git-revert

My bad, then it was "reverse" in Source Tree (or whatever it was).

I like Magit because it doesn't try to hide git while still giving all the advantages GP mentioned https://magit.vc/

I work with a lot of people who have no idea how git actually works and it is infuriating. They all use the git desktop program, and almost every time I get called over to help, it’s because they didn’t sync or refresh or whatever the hell it does.

If you don’t have a good mental model for git, you’re gonna have a bad time.

Second this. I was one of those people that needed help when I was learning git. Went full CLI after that and never looked back.

I don't trust GUI clients; it's easy to not be able to discern the current status, easy to just commit all changes, some of the clients don't respect the pre-push hook, and I've seen other colleagues who have no clue what they're actually doing end up mixing pull and pull --rebase, somehow managing to make duplicate commits with slightly different contents and not having a clue what's going on.

Don't use clients if you don't even understand the basic git workflows. And those usually don't support the advanced oh shit situations this article is about.

> it's easy to not be able to discern the current status

Probably a failure of whatever UI you're using. I manage just fine.

The common statement from CLI types is that "it's just whatever you're better at using" which is true conceptually, but practically, again, CLI users make more mistakes either from fat fingers or lack of understanding of git.

Understanding git conceptually from a UI point of view is easy. You don't even have to have a full understanding of git to be effective at using it, if the UI is good. I'm shit with the git CLI, but I understand what git is doing.

Yes it's easy to do dumb shit in a GUI, the same is true for CLI. In fact, it's less likely that there'd be a button for doing something dumb than it is that a git novice would find some command on StackOverflow and attempt to use it without fully understanding the ramifications of it.

I've felt a good GUI would make using git far more intuitive, but I've yet to find a good one. They all seem to fail on one front or another (too hard to use, don't expose enough functionality, attempt to enforce one workflow, aren't available on platforms I want, are slow/resource hogs).

Usually I use the included gitk to view the repo, and the CLI to manipulate it.

For the most part using git is like five commands and it is definitely fast to use them from the command line if you have some sort of git understanding

Which do you use? I'm generally pro-GUI (I love Postman, for instance, and don't use curl much) but my experience with git GUIs has been that they were kind of half-baked and will not do what I expected, leaving me with a difficult-to-understand mess to clean up.

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI.

I've suffered a lot of git GUI bugs. The admittedly large repositories I sometimes deal with cause things to hang and stall, breaking my flow. I keep filing bug reports - truncated diffs because new files were "too large" (presumably someone trying to fix the hang and stall issue), a client that only renders the top half of the window consistently when on a portrait 4K monitor, etc.

The git CLI is simply second nature enough to me at this point that waiting for a GUI to load, refresh, etc. is rarely faster. It does happen, but it's not the common case. Getting a good summary of a set of changes is sometimes one of them. Picking individual hunks/lines is sometimes another - although I prefer to commit with such frequency when using git, that it's extremely rare I have changes that belong in different commits.

Then, looking at perforce, I'm finding more and more cases where I'm dropping out of P4V and into command line tools. Any kind of mass move/edit seems easier to do through the command line. Command line diffs were way easier to review than P4V's file based diff interface when I had changes involving 1 or 2 line tweaks spread across dozens to hundreds of files (such as verifying function rename changelists didn't accidentally pick up other changes.)

I think anyone who's swayed by the beauty of a git GUI has much more patience than me.

"Sourcetree (Not Responding)" - I typed this out while waiting for my Visual Rust tab to focus. Euhg.

I could've made a commit from the command line in that amount of time.

I've found my sweet spot is using both a GUI (Github app, to be specific) and a CLI.

GUI for partial commits and reviewing my change, and then command line for basically everything else (merge, checkout, branch, etc).

I've tried out a few different GIT GUIs, and never really took to any of them. Settled for using the CLI + many BASH aliases. Anything I do frequently gets a concise alias to minimize typing. I have relatively short fingers, and I'm admittedly a pretty poor typist, so I really emphasize the concise part. Pretty much all the aliases are write only code. I do this for pretty much every other complex CLI application too, e.g., Docker, Heroku, AWS. A little abstraction really speeds up using the CLI. Aliases are my favorite feature of BASH, I think they've saved me literally months of typing at this point in my life.

Here's a few handy ones:

  alias currentbranch='git rev-parse --abbrev-ref HEAD'
  alias gpush='git push origin $(currentbranch)'
  alias gsync='git pull origin $(currentbranch)'

  alias ga='git add -A'
  alias gc='git checkout'
  alias gcm='git commit -m'
  alias gca='git commit --amend'

  # and my personal favorite (list recent branches)
  alias gb='git for-each-ref --sort=-committerdate refs/heads/ --format="%(HEAD) %(color:yellow)%(refname:short)%(color:reset)" | head -n 20'

My version of gsync is `git pull --rebase origin ${currentbranch}`, since I hate having random merge commits.

I use a git GUI for staging commits, but the CLI + text editor for everything else (and no aliases). The CLI is universal--I can go to another dev's computer and get them out of rebase hell without learning their particular git GUI interface. Knowing the CLI by heart is also useful if you ever have to use git server side through SSH. I have found that the CLI fits into my workflow better than the GUI for everything except staging.

Past experience with GUI frontends and other sorts of simplifying interfaces for version control tools has left me extremely reluctant to use anything more than git's out-of-the-box command line, despite its execrably wretched, unlearnable inconsistency. When things don't make sense with git, I can at least compare notes with coworkers, or search the web and find many discussions where other people have been similarly confused, and received useful advice. If I'm using some custom frontend interface, on the other hand, there are inevitably going to be situations it doesn't handle where I have to fall back to the command line, which I won't remember anything about because I will not have been using it, nobody else on my team is likely to be familiar with the tools I'm using, and discussions on the web are likely to be scarce. Better to just absorb the ongoing pain of git's terrible interface for day-to-day tasks so that I'm not completely hosed when things inevitably go wrong.

I work very well on a cli. I can do partial adds faster than you and don't had any 'oh shit' moments for a few years.

I do not care if someone is using a gui.

My takeaway: - If i can use git on an cli, i can use git on any server with an cli. I do need this for when i use git on my ansible maschine or on my home media server or when doing something with build infrastructure (jenkins -> git -> cli)

Additionally you can always use the command line if you need to. I use a GUI for 99% of what I do, then use the CLI for what I need it for.

I wouldn't say "anyone" is trying to hard but I have seen a lot of people who immediately disregard guis as soon as they internalize that the cli is more difficult. Reasons include wanting to be "badass" or "smart". Yet many also do not care about how got differs and basically ask "how do I save" and proceed to revolve their entire workflow on a few copy pasted or memorized commands.other they hear how "rebase" is only for "smart" people...

On the opposite side gui users can often be unaware of the actual model and instead be working with imperfect internal models with be GUI being a crutch.

In both cases there is lack of desire to learn but I'm often more sympathetic to the latter where people want just enough information to do their work well as oppossed to the former who often make things harder than they have to be in all areas and have lost touch with true expertise in favor of appearance of expertise.

Which Git GUI are you using?

The GUI is said to be a major leap forward in human conputer usage, in the context the CLI just strikes me as either (elitist?) jargon, or brogrammer bravado. In either case, not really a step forward but certain macho. I still don't get it.

I use https://github.com/jonas/tig for interactive staging and git CLI for everything else. Best of both worlds and I don't have to leave the terminal.

+1, not having to use a mouse is great. I also use zsh's inbuilt git aliases [0] which I can't recommend enough -- I've found using git CLI without them a pain now that I'm used to them. These together have me productive and happy.

[0] https://github.com/robbyrussell/oh-my-zsh/wiki/Plugin:git

Tip for new tig-players: whilst you can use tig perfectly fine with just the keyboard, it does support using the mouse. Just add `set mouse = yes` to `~/.tigrc` :)

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI.

Or just couldn't be bothered with leaving terminal. I refuse to reach for mouse for any repository operation when everything else I do from console.

I use both - to me the big advantage of getting used to GIT CLI is that you learn the tools to handle uncommon operations and automate tasks, which the GUI doesn't give you. When you need to start piping stuff through grep, for example.

GUI user here. Genuine question: when would you need to pipe stuff through grep? I get it would be a rare situation, but I can't think of one.

We have a naming convention that feature branches are named "feature-[descriptionOfFeature]" here and I wanted to bulk-delete all the merged feature branches that developers had left dangling, without killing the release branches and the like. Grepping helped there.

Like I said, super-rare situation.

In addition to better staging and committing, I love my git GUI for allowing me to easily see and work with every past commit.

Right click on any commit and I can create a new branch there, copy the SHA, do a mixed reset to that location, rebase on it, etc. SO much easier to visualize the actual tree of commits you're working with.

I'm sure some people do do all that from the command line. But every CLI coworker of mine has really only known the basics of branching and committing. The GUI unlocks the repo and all of its branches and commits as something you can play with and explore.

Git is, imo, way too simple to require a gui. How long is it taking you and your coworkers to make commits? git commit -am "message" (or add the files you want with git add, then commit); git push; git pr -m "message". The longest part of that is coming up with a good commit message. A gui isn't going to stop people from making mistakes because the mistakes aren't from complexity of the command line, they are from committing things you shouldn't, which will happen regardless of whether or not you use a gui.

For me, using a GUI makes it much less likely I'll commit the wrong changes as I can quickly review each staged file across the entire tree before committing, and also see if there are unstaged changes (including new files which was often the bane of an SVN workflow) which need to be included.

I typically use git gui to commit changes, the cli for other operations, and occasionally source tree to visualize branches and compare with remote repos.

The Git UI that comes with intelij can do all the essentials git statements and has a console that logs everything it is doing.

And you can also learn useful things by reading the console sometimes. There is no magic.

"- It's easy to keep files uncommitted for long periods of time intentionally, without slowing down my workflow." "- My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.)"

Do you mean that as "not committed", or "not pushed"?

If you mean not committed, then why is it a good thing? You should be committing often. Then you push after you are satisfied. It is much easier to revert mistakes that way.

Once upon a time I found a git GUI that I liked (SourceTree). Then Atlassian bought it and pushed their cloud nonsense on me so hard that I just gave up and reverted back to the command line. Eventually I bought the O'Reilly book and figured out how to do the neat things that SourceTree would let me do. Only this time the GUI wouldn't get borked while trying to stage individual lines.

I haven't looked back because I haven't found the need.

I'd consider myself an expert on Git, and I use a GUI of sorts for the vast majority of my Git work: Magit in Emacs.

It has many of the advantages that you describe; makes it easier to get an overview of what's going on, makes it easier to stage individual files, folder, lines of code, hunks, etc.

There are a couple of cases in which I need to fall back to the Git command line, but it's not very often, and I do find it substantially improves my life.

I'm in such agreement here.

I often see files that clearly shouldn't have been committed. I always bring up using Sourcetree or something else, but everyone seems to think that it's okay the way it is. I can't force it on them and to each their own. It is really frustrating though, because there's this stigma against using a git GUI, but the end results of using one are (in my experience) significantly better.

I don't know how much difference does it make using gui or cli. When i was interviwed for my first job i was asked questions on git. And they asked if i use gui or cli.I think they wanted to know if i really know how to use git through cli. I never used gui for git, maybe i will use in the future. I think Ohsitgit is a good resource which i was trying to find on internet for so long.

It doesn't have to be an exclusive or. I use the CLI for most things, but a GUI when it makes sense (like you mentioned, staging specific hunks). I find that for the most part, my CLI workflow is so straightforward I rarely get in an "oh shit" moment: git pull, git co -b featurebranch, a series of git ci -av, and a git push to open a pull request.

There's a git GUI??

Seriously though, I'm somewhat new to git and any problem I come across (which are many as a new learner) are solved with command line options. I'm not even familiar with the best GUI options out there and have been trying to learn what seemed to be the "standard" way of git'ing.

I’m a big fan of Gitkraken. Great for doing common actions in one click, and graphically viewing history. It’s crazy how negatively people judge me for using it though. It’s like telling someone I prefer Microsoft Word as my IDE.

Seconded for a GUI. I've been using gitkraken for almost a year now, never looked back.

(full disclosure: as of last week I actually work for the company behind gitkraken but I started using it far before I realized they were local)

On mac I can recommend Gitup. It's fast and easy. Also vs code has quite nice git integration. I just use it for making commits though. Everything else is faster from CLI.

Android Studio has a git UI built-in so it's really useful.

I always do `git add --patch`, it's very precise and I can edit lines before staging them. I really don't see why someone would work without it (or a GUI).

I use the CLI because I don't currently work on any group projects.

I’ve only seen the opposite effect in practice. My odd look as well.

So... which git GUI are you using?

Which git GUI are you using?

What git gui? Git kraken?

Which GUI do you use?

> I think anyone who uses the CLI is either trying too hard

Why do you think it's okay to share this opinion?

Because this is a forum and nothing I say matters.

The problem of course is the question - What gives anyone a right to do anything? What gives you the right to police the comments? What gives me the right to question your questioning? Meta-discussions always get sidetracked..

What makes you think it is not?

Because it's rude and antagonistic and it compels a lot of people to post to defend themselves. It's classic trolling.

It's not constructive, who cares what you think about CLI users? The fact I'm being downvoted says a lot about the state of this forum.

Your comment was also trolling: I would have avoided the leading question and just commented on the probable negative interpretation the some CLI users might make of the comment.

A git off my lawn moment: Every time I see someone complaining because they have to dive into the reflog to fix their own mistake, all I can hear is "I was operating my table saw without using a push stick and can't understand why I lost a thumb".

Friends don't let friends (especially those who don't learn how to use their tools) rewrite shared git history. If you don't understand rebase, amends, etc can do to your (and everyone else's) repo, DON'T DO IT.

On the other hand, doing it is the only way you're going to learn. Just do it in a safe environment, with a snapshot of the repository.

Yep. That is the important tip, right here.

    $ pushd ..
    $ cp -a my-project my-project-before-I-did-git-surgery
    $ popd
Then relax. This is extremely important before playing with nasty Git surgical tools such as huge rebases. Borked it up?

    $ pushd ..
    $ rm -rf my-project
    $ cp -a my-project-before-I-did-git-surgery my-project
    $ popd
Undo is a great thing, and it's also important to triple check the entire state of the repository before you push, because pushing is basically committing to whatever surgery you've done. If you're having to fix stuff with -f, you're going to run into trouble; try to avoid -f ever.

This is so wrong. :) With git you exactly do not have to backup your local workspace, because it already is backed up in git.

If it is committed, it is safe. You can go back to it. If you messed up your branch, just reset it to something that was good. No need to do manual backups.

No, it isn't, if you're playing with surgical tools that disrupt Git history, which was my point. It's a lot easier to revert to before you started than attempt to abort out of a huge rebase/squash/ugly merge conflict hell/rewrite of history. I'm not saying back up before every commit. I'm saying when `git status` is three pages long, you have 14,000 conflicts, and you're on a detached HEAD God knows where, it's your choice to spend the next hour typing the right Git commands to get back where you wanted to be, or just back out and try again. I know which one I'd prefer.

I'm sorry if I sound rude. I don't mean to be. I'm just saying that backing up your git workspace to recover from rebases or merges gone wrong is not necessary. Those are not "surgical tools", they don't modify existing commits. (edit: yes you can "edit commits", but they only create new commits, the old commits are not deleted in the process and they can still be found easily)

When you commit in git, that saves the whole project as a "snapshot". If you find yourself lost in some rebase hell or whatever, just reset HEAD back to a previous commit. It's simple as that! (git reset --hard <commit>)

Why I decided to reply to your comment was because this is a very crucial part of learning git. When you realize that you can always go back to what was before, you can start experimenting more freely.

> git reset --hard <commit>

Unless part of your surgery involves files that do not yet live in the history, or you're working on a detached HEAD in a mid-merge state, or... git reset --hard is a very dangerous operation unless you're 100% sure of the entire state of the repository. That is a very rapid way to lose work if you're not perfectly diligent.

And sure, you shouldn't have to back up .git or your workspace, but sometimes, it's a hell of a lot easier to ripcord out and say "screw it" if you have a complete workspace from before you decided to launch down the rebase hole or whatever.

You could run git reset without the --hard parameter to keep unstaged changes in the working directory

It's only easier to copy the directory if you haven't done the due diligence of learning git properly. It's a tool to avoid doing the ripcord approach -- ever.

Why not just create a new branch instead of copying your project over to a new dir?

Sure it's wrong if you know what you're doing. But that's not who the blog post is for.

Sometimes it's okay to take liberties with good practices - especially when learning, or when the world is on fire and a push needs to happen now.

> or when the world is on fire and a push needs to happen now.

The unwanted reality we live in.

>If you're having to fix stuff with -f, you're going to run into trouble; try to avoid -f ever.

I disagree. I don't have much experience using git with big teams, but at least for small team where a developer usually owns a feature branch, force pushing to the branch to take into account criticism on commits can be helpful. Of course, in that case, feature branches are considered non shared.

Git own "next" branch is actually force pushed to all the time, to remove patches which didn't make the cut for example.

Personal opinion - re-reviewing a pull request when someone has erased all context from your last review of that PR via a rebase and force push is a royal PITA. Especially for changes that span more than a few files. Did they address your concerns? The only way to know is to go back through all of the changes on that feature branch, and hope you don't miss anything.

This, in contrast with just reviewing the latest commit, potentially going back to the rest of the changes with an eye towards the latest commit.

It frankly bugs the piss out of me when people rebase and ask me to review their latest changes - it feels disrespectful of my time.

I've taken to making the change as a fixup commit and leaving it in the PR for code review. Then when the changes are approved a quick `git rebase -i --auto-squash` cleans everything up before merging the branch back into `develop`.

> force pushing to the branch to take into account criticism on commits can be helpful

Hm? Criticism on commits should be additive. The commit was made, response was made, and a new commit addresses the response. Rewriting history breaks a lot of things and removes context. Another approach:

1) Add commit addressing criticism.

2) Squash when merging feature in to master, which is one of the only cases where I think rewriting history is OK.

Much cleaner master history, no rewriting history (which you should never do once another checkout sees your branch, including GitHub), and a number of other benefits. If you're routinely force pushing feature branches, something is broken in your workflow, IMO.

practicing safe version control is better than abstinence

I see what you did there...

This is a place where Mercurial wins out. Hg has the concept of phases that makes it much harder to screw up rewriting history:


Replacing a table saw with a circular saw (bad analogies abound) doesn't remove the opportunities for losing appendages. Especially for those who don't learn how to use the tools put in front of them.

"It is impossible to make anything foolproof because fools are so ingenious."

Yes, Git is a sharper tool with fewer blade guards than other version control systems, including HG. That sharpness and relative lack of safety mechanisms, however, lets you do things you can't in other systems. The real problem is that folks use these tools without attempting to understand them and cargo-cult onto a workflow which leaves them open to screwing things up.

To continue the "git off my lawn" moment - I've had to use the reflog exactly zero times in the past few years, despite using rebase locally on a fairly frequent basis (and sadly remotely to fix other's bungles as well). This is only because I respect git for its sharp edges, and when it comes time to re-write history with rebase, I work carefully.

Reminds me of a time I saw a funny Makefile mistake. SRCS contained both .cpp and .c files, and someone copied a recipe that only replaced .c ones.

Then they used the resulting variable in 'make clean'. That was more of an, 'oh shit, git pull' sort of thing though.

I use the reflog all the time to fix my own rebase mistakes; it's just on rebasing I've done locally, and where the results haven't made it out to a shared repo.

Rewriting shared history fits the metaphor pretty well.

But you can still chop off your thumb in your local history, and that's safe to fix - you just have to know where the duct tape is.

rebase can be dangerous, but so productive. I think it's important to teach new devs how to properly use it. Especially if you're working in a continuous deployment environment, where you may need to quickly revert something.

Reverting something does not require a rebase. It requires an aptly named command "git revert". Additionally, in the event that a deployed feature needs to be reverted, any halfway decent change management policy will want a history of what you reverted and why; a git revert commit can show both very cleanly.

And, frankly, since all rebase does is re-write history, I fail to see how it's inherently productive, especially in the context of re-writing the history of previously shared commits. Yes, it is capable of cleaning up and reducing the number of commits you have to read through when looking at history, but that's such a rare event that optimizing for it (especially by normalizing dangerous commands like `git push -f`) seems, well, premature.

Completely agree. Rebase is practically only safe on single developer feature branches which haven't been merged or completely isolated repos that produces patches only. Keeping track of all requirements in the former is hard, especially if the dev doesn't know git pitfalls. No one should default to rebase in a day to day workflow, but it is quite common.

Rebase is mostly useful for cleaning up local commits or feature branches. You can rebase without force pushing master.

driving can be dangerous, but so productive. I think it's important to each new adults how to properly use it.

You already have git-revert, for reverting commits without rewriting history.

You're misunderstanding the purpose i'm describing. Imagine 100 commits a day, maybe more. (I worked at a company that averaged 500 or more commits a day to the master branch. There were 1000 developers working in a monorepo). Some code is out in production, and suddenly we realize a specific commit is causing a problem. The idea here is to revert the commit as soon as you can, and then spend your time fixing it. When reverting code is easy, and the company has good logging to identify problems, you can deploy more often. It's a good thing.

But to enable this "revert-first" culture, you have to design your commits to basically be super easy to revert. That means no merges in the master branch, you want to keep your revision history as clean as possible. One commit, as little dependencies as possible. Rebase is the right tool to use for this. The goal is a tidy linear history.

> But to enable this "revert-first" culture, you have to design your commits to basically be super easy to revert. That means no merges in the master branch, you want to keep your revision history as clean as possible.

How are these concepts related to each other? Merges don't make reverting any harder.

That sounds quite chaotic and impossible to keep stable. I wonder who was responsible to find problems and fix the master after messing up?

It was actually quite clean, and the environment was extremely stable. The trick is, every commit was "self-contained". Reverting it would go to another previous stable version. Creating a self-contained commit can be done many ways, and rebase is one common tool used to do it. Another is the use of git merge with --squash and a cherry-pick.

git revert is exactly the tool for the situation you are describing

Sorry again, you're not understanding my point. Git revert is of course used... but i'm not worried about the mechanics of the revert itself. I'm worried about each revert being a "self-contained" piece. That the project was stable after the revert. That's the bit that was important. A Linear history of commits is the important bit. Not how to do a revert.

Git revert has undesired side effects for merges. If you have a merge-only workflow (GitFlow, for example), and your pull request breaks something, a revert commit will not help you.

After a revert, all the commits that were merged, are still merged, but then they're deleted. The next time you pull, git will delete the changes in your working branch.

In a merge workflow, you have to either fail forward (fix the problem, rather than backing out the merge), or reset/rebase the shared branch, and email repair instructions to everyone on the team.

Create a feature branch, revert the revert, and then fix the problem. It sounds a little weird but it works fine.

It’s a lot of paperwork to avoid a perfectly safe and normal git command.

No it isn't. You'd always want to create a feature branch so that you can PR the fix - it's a change going into master, it should go through the normal change-going-into-master review flow. And you'd always have to run some command to indicate that this was the branch where you wanted to undo what you'd done to master. That the command is called "revert" is a little weird, but it's no more paperwork than any other command would be.

To be fair, rebasing a shared branch really isn't all that safe. You can potentially make life hard for a lot of people.

That’s not fair. That’s fear, uncertainty, doubt. Those people pulling that shared branch will see a big honking warning message, which can easily be resolved if you communicate what’s happening and why you rebased the upstream.

When you say, it’s not safe, it sounds like you could lose work or someone could be hurt, when it’s more likely that the removed ancestors could be merged back in by someone not using ‘git pull —rebase’, or other devs being put out by having to resolve some conflicts. It’s not great, but it’s a far cry from unsafe or DANGEROUS! MUST AVOID! PUBLIC SHAMING!

Anytime you normalize a workflow around using unsafe commands, you risk desensitization to those very warning messages you're relying on to save you.

If you have one rebase with a force push a week, people will quickly stop asking "who did the force push", since it has become normal. They'll instead just let the force push come through to their local repo, just to find out that the force push rolled the repo back a year. Now productivity is halted dead until someone goes in and fixes it and makes yet another force push.

The worst part to me is that it makes the repo lossy. The entire purpose of having version control is actively subverted in the name of "clean".

I think this is fine, but then I'm comfortable with what a force-push is (a remote reset) and I know that the commits still exist even when the ref is moved, and how to inspect the history of a bare repo to move the ref back.

I don't understand the business requirement for a non-lossy repo. In my experience, we need to be able to link a release to a specific commit, and we need to show that the changes were reviewed & tested before they were deployed. We use tags for this.

I also think the entire purpose of source control is to be able to answer question like "who changed this? when was it changed? why?".

> Now productivity is halted dead

Because of a bad push to a single repo? I really like the distributed nature of git, which lets me stay productive even when other repos and branches elsewhere are having issues. I would avoid treating git as 'SVN but newer'.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact