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 workflow like "git flow feature finish` I'm confused as to where the code review actually happens and how git-flow or git can facilitate that review.
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
We stumbled on this exact problem recently. We really like git flow, as it use a good level of semantic (using the same level that you use in team discussion : "I'll start feature A" more 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
Our current solution :
This is consistent with our practice, with the downside of requiring to delete the branch ourselves (as we do not git flow 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).
The process the team I work with uses for this is as follows:
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
For hotfixes we use a similiar approach and create the pull request in GitHub before we finish the hotfix.
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:
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.
Here is another suggestion.