On: Some bad Git situations and how I got myself out of them

[wfunction]

Surprised there was nothing on messed-up merges or rebases. They're some of the worst to get out of when you're not totally comfortable with git yet.

[noufalibrahim → wfunction]

And reflog. It sort of like revision control of your branches and commands. Very useful to extricate oneself from various situations.

[web007 → noufalibrahim]

+100 for reflog. Even for the stupidest cross-merges I've broken reflog has been my savior.

https://git-scm.com/docs/git-reflog

[zubspace → wfunction]

Any points on how to continue from there? Been in a few "I give up" conditions during rebases that I completely stopped trusting git it any way.

The thing is, some repositories on github require you to commit only after proper rebasing. But I can never in my life remember how and need to google it...

[JimDabell → zubspace]

To abort a screwed up merge:

    git merge --abort

To abort a screwed up rebase:

    git rebase --abort

Both of these will take you back to immediately before you began the operation.

[wfunction → zubspace]

> Been in a few "I give up" conditions during rebases that I completely stopped trusting git it any way.

Been there too, with the same result.

> Any points on how to continue from there?

Honestly? Not always from the command-line, unfortunately. Basically, I just don't know the right commands to type on the command-line for everything I do with git, and it's not necessarily easy to find them either. I use the TortoiseGit GUI, and over there, it's a LOT more easy to see what is going on and to abort or continue rebases/merges as necessary, or to do fancier stuff. But the thing is, because I understand git and I know what should logically happen at every step, I can cherry-pick commits, revert them, abort/continue merges, rebase commits, or do whatever else the heck I want without getting into trouble anymore... even though I don't know how to do many of them on the command line.

Of course, it took a lot of suffering to get here. Starting with the GUI would of course be the wrong approach. But once you've understood what's going on, then I would recommend you entirely ditch the command line and switch to something like TortoiseGit (I hope you're either on Windows or your platform has something as good as that). The GUI actually shows you what your options are at every step, so you don't have to know all the valid commands at every possible state. You just need to know what effect you need to cause.

[totallymike → zubspace]

If you ever get yourself in a situation during a rebase, or find that a rebase went wrong, have a look at `git reflog`.

Running it gives you a log of all the things `HEAD` has ever pointed at, meaning you can find what you had before a rebase and check that out.

    git reflog
    git checkout HEAD@{10}

And you're usually good to go.

[sergiosgc → zubspace]

> Been in a few "I give up" conditions during rebases that I completely stopped trusting git it any way.

People use rebase in a far too casual way. Rebasing is a pretty advanced use case, one that is unnecessary for normal git usage. You sentence sounds like: I stopped trusting Ford because the car stopped working when I reprogrammed the ECU.

In short: If you are not entirely comfortable with git's inner workings, do not use rebase. Do not complain if you shoot yourself the foot with rebase.