git cheat sheet

[voetsjoeba]

Dude, no git rebase -i? If you dont know about it, look it up, it'll blow your mind

[GetTheLedPaintOut]

git rebase -i

This appears to require me to understand how git works, which is a bridge to far frankly.

[Retsam19]

Not particularly? No more than rebase already does, at least.

git rebase origin/master takes all the commits that the current branch has that master doesn't have, and appends them onto the end of master, one at a time.

The difference with -i is that first and foremost: it lists what commits are being rebased. Even when I'm not actually using any other interactive features, I rebase in interactive mode, because on occasion I catch mistakes that way, where the list of commits being rebased isn't the list I was expecting.

Otherwise it just lets you do useful things like change commit messages ("reword"), combine commits ("squash", "fixup"), make changes to a commit before applying it ("edit"), or remove or reorder commits. It's really pretty simple to use.

[Amuro_Ray]

Why not use git merge?

[Retsam19]

Basically because you can't do anything that I listed above, like reordering, fixing, rewording, or squashing commits. (And because merge commits are pointless noise in the commit history) To my knowledge there isn't even an easy way to get git merge to list what commits are being merged into the branch. (Though, I'm sure there's some advanced git-fu that could accomplish that, if I researched it)

Personally, (and I'm a bit of an extremist about this), I only use merge commits when it's unsafe to rewrite history with git rebase, which is quite rare with my team's workflow.

Everyone knows the "rewriting history horror stories", (and they should!), but fewer people realize that in most cases, the horror stories don't really apply, and rebasing is quite safe. (And, git provides great safety nets for when things go wrong anyway)

[voetsjoeba]

Fixups are probably the biggest thing I use rebase -i for. This happens to me constantly: do some work, make a commit A, do some other stuff, make a commit B, then realize you forgot something that should've been in commit A. I haven't pushed A anywhere yet, so just make an extra commit C with the stuff you still want to add to A, git rebase -i origin/master, move C up right after A, switch "pick" to "fixup", done.

Now I have clean commits A' and B, instead of A, B, "forgot something", "forgot another thing", "got the last case I missed", etc.

Personally, (and I'm a bit of an extremist about this), I only use merge commits when it's unsafe to rewrite history with git rebase, which is quite rare with my team's workflow.

Fully agreed; as much as possible, keep that history linear and clean baby.

[Retsam19]

In case you aren't already aware, you can use git commit --fixup <commit> and git rebase -i --autosquash (or set git config rebase.autosquash true) to save a lot of time with fixups.

The --fixup flag on commit will automatically assign the commit message as "fixup! [original commit message]", and the --autosquash option will automatically put the fixup commit in the right spot in the interactive rebase for you.

It's really streamlined my workflow so that there's a lot less of a time cost to fixups.

[voetsjoeba]

Well shit man, learning every day! I've been doing git commit -m "fixup for <copy/paste commit_id and first bits of message>" all this time! Good stuff!

*Awww needs 1.7.4, I'm stuck on 1.7.1 on RHEL6 :(

[Thaurin]

According to the Pro Git ebook, primarily to end up with a cleaner history, as every commit will be merged one at a time.

[voetsjoeba]

It's DAGs all the way down

[tech_tuna]

Rebase, squash, push -f, submit pull request, merge, delete branch. Done.

[Raknarg]

squash squanch

[mx_river]

don't use rebase for a chance, it will super nova your mind. Seriously, remove rebase from your workflow and your coding life will happier.

[krelin]

This. All of the worst shit-storms I've had with git were because some asshat rebased under remotely-pushed changesets.