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
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.
Our own code additions have simply outgrown that black non-magic MacGyver brute force trickery
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.
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).
