如何用主分支历史覆盖开发分支

Question

Problem

In our workflow we have a development branch which becomes littered with features from time to time. Sometimes those features will never be merged to master because they won't work or the feature has been dropped.

Therefore the development branch consists of unneccessary commits.

Every half a year we try do recreate the development branch. We remove it and check it out from our actual master branch. Every developer needs to be aware of this event because they have to switch their local development branch with the newly created origin/development.

Often enough this just does not work. Because some developers are ill or on vacation and as they return they skip the email describing this event. They end up with confusion.

Question

How can we kind of cleanse the development branch to only have those commits that are equal to the master branch. Actually it should contain the same commit history as when we would freshly check it out from the master branch.

Answer 1

You could rewrite the history of the development branch to arbitrarily point to the same commit master does, from which point they would have exactly identical history.

git branch -f development master

However, since development is shared, it means that every repo user will have to update its now-obsolete local version of development , and this means conflict resolving... hard to say it'll be any more convenient that the workflow you described.

Answer 2

Actually it should contain the same commit history as when we would freshly check it out from the master branch.

If you really want the development branch to be identical to the master branch, then you may reset it:

git checkout development
git reset --hard master

But this isn't really an ideal thing to do, because it rewrites the history of the development branch. Ss you said, some developers might be on vacation and would get a surprise when they come back and pull development . Actually, every developer would get hosed, except for the one developer who does the hard reset.

So, a better plan would be to create a new development branch (with a different name), whose starting point is the master branch. Then, each developer may simply checkout this branch fresh from the start, without any issues.