0

I have a release branch that has moved on significantly from what is in master due to a complete re-work of code over the last 9 months or so.

Because release has diverged massively from master, there are so many conflicts when creating a PR into master. The current contents of master are essentially irrelevant now as I've been working on the release branch for so long. I'd like to reset master to the initial commit (which is just repo initialisation with a .gitignore file), whilst maintaining the same history (aside from an additional revert commit).

I've tried the following on a master-backup branch taken from master and then attempted to PR the release branch into this master-backup branch after running the commands:

git reset --hard <initial commit id> - this resets the history

git revert <INITIAL COMMIT ID>^..<LATEST COMMIT ID> - this has the same conflicts and doesn't quite push all of the files from release into master correctly.

I'm not sure what else to do now. My ultimate goal is to replace master's contents with release whilst maintaining master's current history, with the addition of maybe a revert commit and of course the merge from release to master.

Any help is very much appreciated.

user483934
  • 387
  • 1
  • 2
  • 8
  • There's no reason to reset `master` to anything. Accept all of the changes from `release` during the merge. Something like: https://stackoverflow.com/a/25751748/1265393 – pkamb Sep 04 '20 at 16:39
  • This is what I had suspected should happen, but some of the changes include a complete restructure of files. When PR'ing/merging into `master`, the old files are still present. – user483934 Sep 04 '20 at 16:41

1 Answers1

2

It very much sounds like you want to run a git merge --no-ff release from master, assuming that master hasn't moved since release was started. Then you get to have release's content in one commit right after master (and a side branch with all the development of release.

If what you would like to have is a single commit after master with all of the changes of release, discarding the details of how release got to become what it is, this is what you do:

git checkout --detach release
git reset --soft master
git commit -m "All of release in a single commit"
# If you like the result:
git branch -f master
git checkout master

If master and release have diverged and you would like to force a merge between master and release and keep the content of release as is intact, then you could do it like this:

git commit-tree -p master -p release -m "Merge of release.... keeping release as is" release^{tree}

This will write an ID in the output. This is a new revision that has been created. It will be a merge of master and release, content will be just like release, no differences. So, feel free to check it out and if you like the result:

# once you have already checked out the new revision
git branch -f master
git checkout master
eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • `master` has moved on by 3 commits but these were small changes that they were replicated to `release` manually which is terrible and has made this a PITA. I suspect that will also cause issues I should also say that `master` has some branch policies on it which means I can only submit PR's and not merge into master via git bash for example. So I'll probably have to create a copy of master, run the commands onto that branch and then PR that branch into master. – user483934 Sep 04 '20 at 16:37
  • Ok... let me add a little additional hack – eftshift0 Sep 04 '20 at 16:39
  • I added a bit of additional context to the above comment - not sure if you managed to read that as I suspect I didn't edit quick enough – user483934 Sep 04 '20 at 16:39
  • I think I got the whole context. Let me know how it goes with the hack. – eftshift0 Sep 04 '20 at 16:43
  • 1
    This has done the trick! I took a copy of `master` and ran `git commit-tree` from release onto the copy. I've now created a PR from the copy into master with no issues and the build has passed. Thank you very much for your help! Had literally never heard of `git commit-tree` until today and was trying with the usual rebase, reset and reverts. – user483934 Sep 04 '20 at 17:14
  • It's ok... `git` has all kinds of tricks... and continues to get more... I am still learning. – eftshift0 Sep 04 '20 at 17:52