At Optemo, we frequently have a topic branch that runs for days or weeks before we are ready to merge it in to master and deploy it to the production site. When we are finally ready to merge such a branch, we would like to have a code review in Gerrit which captures all of the changes that will be added to master. This page describes two possible approaches we have found for achieving this. The approach we prefer, especially when multiple programmers are working on the same topic branch, is Workflow 1. However, if only a single programmer is working on the topic branch and the branch is not expected to be very long-lived, Workflow 2 is also an option.
We are by no means Git and Gerrit experts yet, so let me know if you have any comments or alternative approaches to suggest.
Workflow 1: Using merge
In this workflow, you use merge when you need to update the topic branch with the latest changes in master:
- git checkout <topic branch>
- git fetch origin
- git merge origin/master
You follow the same process when you need to update your topic branch with changes made to this branch by another programmer:
- git checkout <topic branch>
- git fetch origin
- git merge origin/<topic branch>'''
When you are ready to push the changes for code review, you merge your topic branch in to master and use the --squash option to create one big commit.
- git checkout master
- git pull origin
- git checkout -b <temp branch>
- git merge --squash <topic branch>
- git push origin HEAD:refs/for/master
Note that once the change has been submitted by the reviewer and merged in to master, you should stop using the old topic branch. New work should happen in a new topic branch created off the latest version of master.
Workflow 2: Always rebase on top of master
In this approach, whenever you need to update the topic branch with the latest changes in master, you follow the following steps:
- git checkout <topic branch>
- git fetch origin
- git rebase origin/master
This takes the changes in the topic branch and applies them on top of master's HEAD.
When you are ready to submit the topic branch for code review, you follow a similar process. You rebase the topic branch on master, then push the changes in the topic branch for code review. You can do an interactive rebase using the -i option, which will allow you to squash all the commits on the topic branch together in to one big commit:
- git checkout <topic branch>
- git fetch origin
- git rebase -i origin/master
- git push origin HEAD:refs/for/master
Note: If you are following this workflow, it is important that you do not use merge to update the topic branch with the contents of master. If you do, and you later perform a rebase prior to submitting your changes for code review, you may find that you have to redo work you did in earlier merges. Specifically, you may have to manually resolve conflicts that you previously resolved.
