Reputation: 8855
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.
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.
Upvotes: 0
Views: 194
Reputation: 522171
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.
Upvotes: 0
Reputation: 22047
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.
Upvotes: 1