How to handle a Git discontinuity?
Let’s say that in our Git repository, we worked on branch
master for a while. Then, most of us started working on
coolfeature branch, while a few developers continued on
Now, the developers who worked on
master have lost interest, and what they developed since we forked isn’t very important. But we’d like the main development branch to be called
master again. Conceptually, we’d basically like the tree to look something like this:
*--master--X ----master \ / --coolfeature--
What’s the easiest way to achieve this? We really don’t want to try and merge coolfeature, and we’re happy for the commit marked X to be totally meaningless.
2 Solutions collect form web for “How to handle a Git discontinuity?”
Perform a force push with the new master branch.
git push -f origin master
Other people fetch the code, and perform a reset
git fetch origin master git reset --hard origin/master
The way I would do this and avoid doing a forced push:
- create a tag for the commit X that you don’t care about. (You’ll see why in a minute.
- Perform a
git revertof all the commits on the master branch since you branched off coolfeature. This puts the repository back to the state it was at the time you forked, but it doesn’t rewrite history, so nobody’s repository gets broken if they didn’t get the memo.
- Merge coolfeature onto master.
The point about tagging X is to mark the point before you did all the changes. Tags are cheap, and at some point you might want to know the point at which you backed out commits and made such a change.