![]() ![]() We can see that the difference between git rebase and git rebase -onto is that the former changes the base of a whole branch, meaning that it will find at what point current branch diverged from the target branch and will replay all the commits from this point on the new target branch, when the later changes the base of a commit by replacing its old base with a new base. | * Merge branch 'fix' into release (release) $ git log -graph -oneline -all -pretty=format:'%s%d' Let's see how it is different from more commonly used git rebase.įirst, rewinding head to replay your work on top of it. That's when I've learned about git rebase -onto from Michael Brown. This works but cherry-picking more than a few commits one by one (or even using range of commits) seems like an extra and error-prone work. We would need to create a new branch based on the head of the target branch (or reset branch with a fix to reuse it), cherry-pick required commits to it and only then push and create a PR. As our trunk and release branches are configured as protected on GitHub, we can't just cherry-pick fixes and push them to the target branch. We figured there are two pretty-much similar options: either we cherry-pick commits from trunk to release branch or we cherry-pick from release branch to trunk. Recently we were discussing in our team how to approach having fixes for bugs discovered during release both in release and the trunk branch to ensure we don't have to deal with large merges and possible conflicts in the release branch when we are done with a release and immediately benefit from those fixes on the trunk while we keep working on it. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |