With regular git and GitHub, I can do a code review by simply creating a pull request of the feature branch I’m working on to the master branch. How would I do code reviews with git-flow? With a workflow step like git flow feature finish (which merges the feature branch into the develop branch), I’m confused as to where the code review actually happens and how git-flow or git can facilitate that review.
1
We stumbled on this exact problem recently. We really like git-flow, as it uses a good level of semantics (the same level that you use in team discussions, e.g., “I’ll start feature A” rather than “I’ll create a branch, checkout it”), while git is very “implementation” level (which is good and useful also, but different).
The problem we have is with git flow feature finish, as it merges the branch into the develop branch. We want a pull request to be sent and (this is important) merged by the reviewer, not the committer, to emphasize team ownership.
Our current solution :
- Someone uses git-flow to create a feature branch.
- When done, he creates a pull request (using GitHub).
- The review takes place with potential additional commits.
- The pull request is merged using GitHub by the reviewer.
- There is no
git flow feature finish(as the branch is already merged).
This is consistent with our practice, with the downside of requiring us to delete the branch ourselves (as we do not use git flow feature finish). Our next step will probably be to reimplement some parts of git-flow (as it is mainly about chaining git commands) to take this into account (having the “cleaning” part of the finish, without the merge).
1
The process the team I work with uses for this is as follows:
- Create a feature branch:
git flow feature start module_1 - The code is updated on the feature branch
- As changes are committed they are pushed to GitHub (or once at the end if preferred)
- When the feature is completed a pull request is opened in GitHub comparing
developand the feature branchmodule_1 - The team reviews the pull request and makes comments
- Any changes from the pull request are made to the feature branch
- Once all changes are incorporated on the feature branch the feature branch is finished:
git flow feature finish module_1 - The
developbranch is pushed to GitHub (GitHub will automatically mark the pull request as closed/merged when this happens)
Normally all of this process is done by the original author but that is not required. Anyone on our team can step in and pick up this process at any point. All they have to do is checkout the feature branch and continue on with the process. Who ever runs git flow feature finish module_1 will have the luxury of their local feature branch being deleted but anyone else who checked out the branch with have to do this manually if they want to using something like git branch -D feature/module_1.
For hotfixes we use a similiar approach and create the pull request in GitHub before we finish the hotfix.
2
Here is another suggestion.
- Do the regular git flow process to create a feature, but do not finish or merge it.
- Create a pull request, but do not merge it. Wait for the approver to leave a comment. The comment is the mark of approval.
- Do the git flow finish. (Either the approver or the developer can do this, depending on what the team agreed upon.) The pull request will be marked as merged on github. You still need to delete the branch on origin.
If you’re doing code reviews, then I will assume that you have a central repository that contains the “official” code. Developers pull from and push to this central repository.
When you use Gerrit, Gerrit itself becomes the central repository (it has built-in SSH and HTTP servers that let users interact with it in basically the same way they already are). When using Gerrit, the workflow becomes:
- Developer makes changes on whatever branch, commits locally.
- Developer pushes those changes to Gerrit.
- Gerrit creates review items for others to review.
- Peers review the code, making comments and accepting or rejecting the commit.
- When the commit is accepted, then Gerrit makes those changes available for others to pull from the branch.
When using a central repository, other developers can see the submitted changes after step 2. Gerrit introduces the code review workflow, and so other developers only see the submitted changes after step 5.
This works well with git-flow (or any other branching scheme) because Gerrit supports reviewing changes made on any branch.