It is often said that, you should not rebase commits that you have already pushed. What could be meaning of that?
+5
A:
The ProGit book has a good explanation.
The specific answer to your question can be found in the section titled "The Perils of Rebasing". A quote from that section:
When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with git rebase and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours.
Update:
Based on your comment below, it sounds like your are having difficulty with your Git workflow. Here are some references that may help:
- The
gitworkflowsman page: See "Merging Upwards" and "Topic Branches" - ProGit: See "Private Managed Team"
- Jarrod Spillers blog: See "git merge vs git rebase: Avoiding Rebase Hell"
Tim Henigan
2010-04-26 16:37:05
Thanks for the explanation. So, just to make my understanding clearer, after I push certain changes, I should not use `git rebase` ( --interactive ?) to rewrite that history, this is sure recipe of fail.On the other hand, if I have rebased certain changes to topic branch (from branch X) and push it, its perfectly normal to rebase again after another developer changes topic branch. Essentially, I have been using `merge` for quite sometime, but we are in same boat as, http://darwinweb.net/articles/86 and the history is almost unusable.
Hemant Kumar
2010-04-26 18:13:34
@Hemant: Rebasing commits after pushing to a public repo is generally a bad idea. That being said, the advice from the darwinweb article you cited sounds reasonable if your workflow resembles theirs. See my updated response for a list of other references which might help.
Tim Henigan
2010-04-26 19:24:39
+1
A:
A rebase alters the history of your repository. If you push commits out to the world, i.e., make them available to others, and then you change your view of the commit history, it becomes difficult to work with anyone who has your old history.
Rebase considered harmful is a good overview, I think.
dsolimano
2010-04-26 16:40:50
+4
A:
Rebasing rewrites history. If nobody knows about that history, then that is perfectly fine. If, however, that history is publicly known, then rewriting history in Git works just the way it does in the real world: you need a conspiracy.
Conspiracies are really hard keep together, so you better avoid rebasing public branches in the first place.
Note that there are examples of successful conspiracies: the pu branch of Junio C. Hamano's git repository (the official repository of the Git SCM) is rebased frequently. The way that this works is that pretty much everybody who uses pu is also subscribed to the Git developer mailinglist, and the fact that the pu branch is rebased is widely publicized on the mailinglist and the Git website.
Jörg W Mittag
2010-04-26 17:45:26
+1. I think the `pu` branch of git.git is an extremely helpful example of how to use rebase in a (public) workflow. For those not familiar with it, the general idea is to rebase topic branches which don't have any commits in `next` (the unstable branch just before merging to master), then rebuild the `pu` branch by resetting to `next`, and merging all the topic branches. (Source: Documentation/howto/maintain-git.txt http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/howto/maintain-git.txt;h=d527b307707c676e82a08f18cb9fdd7d3abcb228;hb=HEAD )
Jefromi
2010-04-26 18:46:55