My company's policy is that any pull request must be done with a rebased branch. I have a local Dev branch and this has 'task' branches:
remote master --------
\
Dev ------------------
\-----task1 \
\---task2
When master gets updated, I rebase Dev on master. What is a optimal way to manage branches task1 and task2. They are still being worked on. Rebasing each task branch seems like the only way I can see.
Try first do rebase dev while preserving merges:
git checkout Dev
git rebase --preserve-merges master
That should keep task1 and 2 correctly rebased as well.
See "What exactly does git's “rebase --preserve-merges
” do (and why?)"
If you have a lot of task branches, then the best I can think of is to temporarily octopus merge them with Dev into a temp branch and then rebase temp onto master with --preserve-merges. Then reset the branch labels to the proper places.
$ git checkout -b temp Dev && git merge task1 task2
$ git rebase master --preserve-merges
$ git checkout Dev && git reset --hard temp^
$ git checkout task1 && git reset --hard temp^2
$ git checkout task2 && git reset --hard temp^3
$ git branch -D temp
It's still a lot of commands, but:
Since the tree is inherently preserved, it saves you from having to manually reconstruct the graph, i.e. less human error from having to graft each task branch onto the proper corresponding commit of the rebased Dev branch. It's just a matter of resetting the Dev and task branch markers onto the correct parent commit, which corresponds to the order they were used/named in the octopus merge.
If you have to do this kind of thing a lot, this should be straightforward to script and use as an alias.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With