Git flow code review
Git and other source code management tools have become a staple in software development and coding. They help programmers keep track of their projects and ensure that the changes they make are not lost. There are many different ways you can manage your git projects, but this blog will focus on some tips to help you use Git more efficiently when performing code reviews with your team. Important
note: due to some changes months ago in version control platforms, the default main branch may be called A code review is a process of sending code changes to be reviewed and tested. During the code reviews, tests are executed to check if there is any regression in the new
code and teammates are checking the code to verify if there is anything wrong and if requirements are correctly implemented. When using Git, code review is a synonym for Pull Request. On GitHub or Bitbucket, a developer opens a
Pull Request (PR) to make a code review. On GitLab, this is called a Merge Request (MR). While the wording is different, the intent is the
same: a developer has some changes they want to merge into the main branch. The first good hygiene rule for making a code review/pull request is to commit all your changes in your own branch. Before making any code change, start a new Git branch where all your changes will be made. Having your own branch brings many benefits: This is the lifecycle of a branch: A Code Review (or Pull Request or Merge Request) is when the code is reviewed before being merged. It occurs when the branch is still active and before merging the branch into the defeault branch. At this phase, developers make sure the code is correct and ready to be merged and used by all other developers! To start
a new branch, make sure you have the latest version of the main branch and branch from it. When you want to see the difference between your branch, you can simply use the following command
Follow Git branch naming conventionWhen developing code with multiple developers, it's important to agree on conventions to name branches. If you do not establish conventions, you end up with multiple branches with similar names (e.g. bugfix1, fix-bug-from-customer, etc). There is no established convention and you need to define your own. What is common in many large tech companies is to use your login and the issue identifier you are working on. For example, imagine that my username is Sometimes you need to make a follow-up for a task. I generally add the suffix For example, the branch
Make a Pull Request/Merge RequestWhen you write code and push commits on your branch, these changes are only stored on your local computer. To start a pull request, you need to push your local branch to the remote Git repository. First, make sure you are on your local branch by using Once you are sure you are on your local branch, push your branch using For
example, if the local branch is
You can then start a pull request (or merge request) to merge the branch juli1/FBAR123 to your default branch (master or main). How to write a great pull request descriptionWhat seems obvious to you may not seem obvious for your reviewer. For that reason, it's generally highly encouraged to write a description in your pull requests that explain:
Such information only gives context to your reviewer. But it also avoids going back and forth with questions between the author and the reviewer. Finally, it also provides useful context for anybody looking at code changes later. There is an example of such message: Keep changes smallToo often, developers are trying to implement too many changes in one code review. This is a problem since the code review is large and takes long time to review. Imagine you have two changes:
Considering now these two cases:
For this reason, code reviews should be kept as small as possible to iterate quickly and keep shipping. Keep the following rule: 1 ticket/issue = 1 code review. And if the scope of your ticket is too large, break it down into multiple tickets/issues. Rebase on the master/main branchWhen you work on a local branch for some time, your current default branch (main or master) may be outdated and your pull request may have some merge conflicts. To avoid such merge conflicts, you need to rebase your branch. Rebasing your changes means that you are updating your base branch and making sure your changes apply to this new revision. To rebase your branch, follow the following instructions:
You may have some conflicts while rebasing. In this case, list
the conflicts ( Automate your code reviewsCode reviews are very time-consuming. Software engineers allocate between 10% to 20% of their time reviewing the code of their peers. Manual code reviews are necessary to make sure the solution taken to solve a problem is correct and no edge cases have been overlooked. However, manual code reviews are limited:
Automating code reviews provide feedback to the developer very quickly. It unblocks developers that can fix potential issues before waiting for final approval from teammates. Codiga automates your code reviews. It gives feedback to the submitter within seconds. It flags any safety, security, performance, or design issues directly on the code review (see the list of rules for all supported languages). And gives more confidence to the team that the code being merged is correct and exempt from any bug. Codiga does not replace the code review process. It provides feedback quickly to the developer that can fix issues and ensure code quality standards are met. It also gives more confidence to the team that the code does not have large issue. Why not use Git flow?Git flow is complex, with two long-lived branches, three types of temporary branches, and strict rules on how branches deal with each other. Such complexity makes mistakes more likely and increases the effort required to fix them. Release and hotfix branches require “double merging”—once into main, then into develop.
How to send code for review in Git?Under your repository name, click Pull requests. In the list of pull requests, click the pull request that you'd like to ask a specific person or a team to review. Navigate to Reviewers in the right sidebar. To request a review from a suggested person under Reviewers, next to their username, click Request.
What can I use instead of Git flow?GitHub Flow is a simpler alternative to GitFlow ideal for smaller teams as they don't need to manage multiple versions.. GitLab Flow is a simpler alternative to GitFlow that combines feature-driven development and feature branching with issue tracking.. What is the best Git branching strategy?Keep your branch strategy simple. Use feature branches for all new features and bug fixes.. Merge feature branches into the main branch using pull requests.. Keep a high quality, up-to-date main branch.. |