2

We would like to have all our production releases on one branch. So when we're ready for an RC we want to bring that branch up to date with our development branch, do an RC build and apply hotfixes until we're happy to release that version. While this is happening the rest of our team would continue working on our dev branch.

The trick is, we don't want to merge the changes from our dev branch into this releases branch, we want it to just be an exact copy of the dev branch-so essentially ignoring any prior hotfix/etc work that happens on the releases branch as those would have been pulled into the dev branch anyway. One of the reasons for this is we work with a lot of binary files that don't merge well, the other is that our dev branch would have been more heavily tested and the replace would be much safer.

The final detail is that we do want to still have the old commits and tags in the releases branch, in case we need to hotfix an older version (we would branch for that).

If we can't find a solution to match this our alternative is to have a branch per release, but that seemed messy.

FlintZA
  • 872
  • 1
  • 11
  • 22
  • So you're essentially doing what's described in [*A successful Git branching model*](http://nvie.com/posts/a-successful-git-branching-model/)? – Roman Nov 20 '12 at 13:31
  • Your question makes no sense. What do you mean by "exact copy"? If it does not contain a certain set of changes, then it is not an exact copy (unless your definition of "exact copy" is substantially different than the usual one). If you want all branches to be the same, have them all reference the same commit. – William Pursell Nov 20 '12 at 15:19
  • @WilliamPursell Exact copy meaning if I had to checkout one in a working copy, and the other in a working copy, and do a binary file & folder compare on the two they would be identical. How would I have the branch point to a commit without losing prior history on it? – FlintZA Nov 20 '12 at 17:28
  • @R0MANARMY Yes we're trying to achieve something similar to that, but we don't want to bring our releases branch up to date with the dev branch by doing a normal merge (which would apply the changes from commits between when the two branches deviated and current state, and risk selection of a binary file from the releases branch which may have changed more recently). – FlintZA Nov 20 '12 at 17:31

2 Answers2

0

I developed this script awhile ago to do pretty much exactly what you're describing. To use it checkout your release branch, then run this script providing the name of the development branch you want to merge. It will create a new commit that records a merge of those two branches, but the tree will be exactly as it is in the branch whose name was supplied as the argument.

I didn't actually end up using this for real deployments so it hasn't been tested in the real world, only in development situations.

qqx
  • 18,947
  • 4
  • 64
  • 68
0

One solution would be to simply reset your prod branch to the next RC commit.
But that would lose the history of said prod branch.

The other solution is to merge --theirs: all the options are listed in "git command for making one branch like another".
qqx's script uses commit-tree mentioned in this answer.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250