2

Working on a project with a lot of team members, we are now trying to polish our ways of working. Currently all work is done in integration branch which was branched off master few years ago. For one reason or another, there are around 600 commits done in master branch and not merged into integration, as well as around 1200 commits done in integration not merged into master branch. All releases are made entirely off the integration branch, master branch was not touched once in a year. We would like to use master branch as our stable branch, but in order to do so, we need to merge all the changes from integration and not keep any of the diverged changes done in master.

Is there a headache free way to remove "invalid" commits from master branch? Or should we simply create a new repository or another stable branch off current integration position?

Update Unfortunately non-fast-forwards and remote branch deletion are rejected, I am still waiting for a response from the person in charge of the repository hosting. I'm assuming it will not be that easy to change, it's a big corporation sadly.

David Kuridža
  • 7,026
  • 5
  • 26
  • 25

2 Answers2

3

If you can't do a remote deletion, then the easiest way is:

git checkout integration
cp -a . ../integration-source
rm -rf ../integration-source/.git
git checkout master
mv .git ../integration-source
cd ../integration-source
git add --all
git commit -m"massive commit to make master identical with integration"
git push
cd ..
rmdir projectdirname
mv integration-source projectdirname

ta-da!

If you can do a remote deletion:

git push --force origin integration:master
John Bachir
  • 22,495
  • 29
  • 154
  • 227
  • Ah, dang. Well now I've provided an alternate, slightly more complicated solution :) – John Bachir Mar 15 '12 at 20:05
  • Nice one, but merging master to integration will bring in all those commits we don't want. But still a very nice solution, +1 :) – David Kuridža Mar 15 '12 at 23:01
  • It's the only solution if you don't have non-fast-forwards and remote branch deletion. You'll have some useless/confusing history, but identical code. – John Bachir Mar 15 '12 at 23:02
  • On the second thought, it is the only solution based on given restrictions. History is already more or less confusing, hence there's no harm in doing it :) Will wait if SCM reports back by tomorrow, otherwise will do what you've proposed. Thank you for this neat workaround. – David Kuridža Mar 15 '12 at 23:07
1

You should be able to git reset --hard your master branch back to the point where you originally created your integration branch. That will leave you in the state you were when you first branched, essentially "removing" the future commits to master.

At that point, you could just merge your integration branch down to master and they would be identical. In fact, I would think that would just be a fast-forward merge with no conflicts.

To find the original branch point, you can use git merge-base master integration. Check out this Stack Overflow question for more ideas too.

Community
  • 1
  • 1
Brandan
  • 14,735
  • 3
  • 56
  • 71
  • Unfortunately non-fast-forwards are rejected, I'm still waiting for a reply whether they can be enabled for a while. Doing this, will there be any problems when others pull/fetch? – David Kuridža Mar 15 '12 at 18:20
  • I would be hesitant to force push non-fast-forwards. That could very likely screw up other people's local repos when they try to pull. But that was my point: if you reset to the branch point and then merge down from your integration branch to master, it **should** be a fast-forward merge. Did you try this and it failed? – Brandan Mar 15 '12 at 18:28
  • It is reporting as a fast-forward yet all 600 other commits get lost, hence non-fast-forward as well. At least that's my assumption :) – David Kuridža Mar 15 '12 at 18:39