A Simple Code Review Workflow in Unfuddle
You should include code review in your development workflow
It can be intimidating to get started with git merge requests and code review and integrating them into your existing workflows. But as your projects and your team grow, having these built into your processes can significantly aid your development. Here are a few benefits you will see:
While it may sound complicated, Unfuddle makes it very easy to get started with code review in your team. Here's how it works.
Using Branches in Git
You probably track bugs, issues, and upcoming features for your products in your tasks. That's great! But are you using branches in your git repository to maintain a healthy workflow? Many teams make code changes right in the master branch of their repositories. They then close the task and move on. This can cause many problems and make it more difficult to undo changes to the code.
Rather than working only in master, code review depends on branching. Before working on any new task, a developer should first create a branch and make all relevant modifications in that branch. When the work is complete, then the developer should create a merge request on the task in Unfuddle.
Merge requests give your team the opportunity to review and comment on the work BEFORE it gets merged into the master branch.
For example, if we are working to resolve a bug in our product, such as the one below:
We would first create a branch called "12-bat-gloves-bug" and make the necessary changes in that branch. When finished, we push our branch up to the repository in Unfuddle. Then we create a merge request from the task in Unfuddle, specifying the branch where we did our work.
Now the task has some new tabs that show the files and changes included in the merge request. Our team members can now easily see that this task has an open merge request waiting for review.
Now, it's time for the team to help out. Team members have the opportunity review each change and make comments right inline in the code. These are some of the types of issues a code reviewer might look for:
The team can comment on any of the lines in the changed files. These comments will appear inline with the code, but they will also appear on the task activity tab.
Code review discussions will often lead to modifications to the code. Any necessary updates should be made in the same branch in which the original work was done. Once the new changes are pushed up to the Unfuddle repository, they will automatically be included in the merge request. Conversation can continue until the team reaches consensus on the code and it is ready to merge.
So we've finished our code review and have decided that the code is good! Alright! Now, we need to merge the code into master. We can do this using our git client, as normal. Or we can perform the merge right within the Unfuddle task:
Finally, once the merge is complete, we can delete the branch where we did our work.
And that's it. You just rocked code review!