how do I migrate properly from branch A.B to X.Y???

Hello community :slight_smile:

With 4.3 on the horizon the ages old question arises again: how the beep am I supposed to migrate from the current branch to the new one?

I asked one of my day-job colleagues who is kinda Git-savvy and he identified the major problem in that area being that the two branches simply manifest themselves from the depths of that Perforce bot, loosing all info that one day they had a common origin*. This makes all merging or rebasing or whatever black git magic one attempts a pure PITA :frowning:

so far (up until incl. 4.2.1) after days after days after days of rebasing, merging, patching and whatnot I ended up braking off the edge of my desk and wanting to k* someone with it in my rage :mad: lol…well, in the end we transferred our hand-full changes manually and pretty much started over.

THIS TIME the manual brute force approach is not an option for us.

  1. Our own code additions have simply outgrown that black non-magic MacGyver brute force trickery

  2. We seriously need to “professionalize” that process.

I could not find any satisfactory post/answer anywhere - are we the only ones who have problems with migrating branches? O.O
Or is it just my ignorance of Git/Github? xD

Anyhow we appreciate any help we can get to solve this mystery and give everyone a clean, defined process of how to do such a task in a way that inspires confidence instead of fear and rage. :slight_smile:

Caveat: not a git expert, but have been dealing with this the last 3 releases.

Here’s the best process I’ve come up with

git rebase --onto <branch_or_tag_you_are_moving_to> <branch_or_tag_you_were_based_on> <your_UE4_dev_branch>

So recently a move from 4.2.0-release to 4.3.0-preview:

git checkout our_dev_branch
git rebase --onto 4.3.0-preview 4.2.0-release our_dev_branch

Since it replays your changes on top of the new branches, you still have to manually merge any with conflicts. This can be painful if your changes are in fast-moving areas of the engine. But at least it is semi-automated, and you can abort at any time.

You can’t just push to origin right away because a normal “git push” will generally not work because of the mismatched commits from the Perforce bot (and really, if the perforce bot cherry-picked the corresponding git commit in master instead of creating a new commit, life would be a little easier for everyone).

If you don’t want users pulling from your fork to have issues, you need to resolve your origin with your local rebased repo. A ‘git pull’ will accomplish this, but it also generates a merge commit. In practice, this merge is not too difficult because it’s not really merging anything - all the changes are there both yours and Epic’s. I do recommend using a merge tool like Araxis, I’ve found it superior to anything else on Windows for this sort of thing (it’s not cheap though).

There is another evil option I won’t get into because I am by no means a git expert and don’t want to recommend something potentially dangerous, which is a force push. Which saves you time but creates headaches for anyone else pulling from that fork. I wouldn’t recommend it unless the “git pull” merge ends up really bad for some reason (this usually only happens if while rebasing you skip commits, which in the general case shouldn’t be often).

That actually seems to work fine for us. We did try rebase before, but apparently we did it wrong. Thank you!

Right now we’re not that concerned about other people pulling from our branch, so forcing a push to our repos is not a big issue.

I too can confirm that your guide seems to work. Thank you very much for your input! :slight_smile:

With 4.4 we can test it on a fresh new build :smiley: