Don't use git rebase

[PhrozenByte]

Hi,

I would like to make a suggestion for using GitHub more efficiently: Never use rebase on public branches, you'll lose history. Use merge instead (personally I even prefer with --no-ff) - this allows you to easily track development between many branches. Rebasing should only be used on private branches (= branches that exist only on your computer; that's the so called "golden rule of rebasing").

A simple example: The commits 9476d2f and 1d79b4f are the same - but Git doesn't now that. GitHub will always tell you, that master and 1.4.1 branches aren't in sync. It says about the 1.4.1 branch: "This branch is 24 commits ahead, 61 commits behind master". Why is it 24 commits ahead? Does that mean, that some commits (e.g. bugfixes) weren't merged back into master and will appear again in the next release? No, it probably doesn't mean that, but you can't be sure. Don't use rebase.

More information: http://geekblog.oneandoneis2.org/index. ... rom-rebase

git-scm about rebasing: http://git-scm.com/book/be/v2/Git-Branching-Rebasing

Even people which prefer rebase don't hide the downsides: https://www.atlassian.com/git/tutorials ... f-rebasing

[crizCraig]

You're right that rebasing changes the commit hash, since part of the hash consists of the parent commit and the commit time, and both change during rebase. However, this is okay as git can handle merging and rebasing makes the history cleaner as it avoids merge-commits which can be very ugly. Rebasing can cause problems though if branches are used instead of tags for versioning since branches are moving targets, unlike tags which are static. It looks like both tags and branches have the name 1.4.1 in the repo on github, so just deleting the branches, and using the tags instead once they're finalized would probably clear things up.

[qaisjp]

crizCraig, modifying the public history is a very big *no no* and is never okay for big projects - you're thinking of "git pull --rebase", which prevents merge commits when pulling. The devs should follow a "proper" publishing system, and by this I mean Git Flow (or similar) - right now I think it's just a bit messy.

Edited May 19, 2015 by Guest

[crizCraig]

Ah yes, if you rebase already pushed commits, I can see how that is Very Bad Thing™. Someone had to've "git push --force" to the public branch which leads to fistacuffs at my office ^^. So key takeaway is that rebase is okay when all of your non-published commits are replayed *on top of* the published commits, basically "git pull --rebase". Thanks for the clarification.