Git best practices with pull requests

Some time ago I published an article about git best practices in agile projects, which prevent the most common conflicts when many developers are collaborating together in a project, especially when they work remotely.

That workflow is enhanced by a feature offered by systems like GitHub and BitBucket called pull requests, which allows developers to follow a process that helps them avoid code conflicts, and also pair review the code that others are pushing into the project.

This is how a pull request looks like. In the example, a hotfix branch is being merged to master. The pull request holds the merge in a state that allows other developers to see what is being changed. If a developer agrees with the changes, she can proceed with accepting the pull request and executing the corresponding merge and then delete the supporting branch if needed.

The difference between using pull requests and following the standard git workflow is that with pull requests developers – especially the ones who are making the changes –  are more conscious of what is being changed, because the user interface highlights the code that is being deleted, added and modified, and it also shows the files that are being affected with he changes.

Another great feature of pull requests is that it allows developers to have conversations about the changes, and even add annotations in specific lines of code. Those comments make the merging process more transparent and visible to the entire team, and it also helps with documentation.

Adapting the standard git workflow to pull requests is easy. This is the revised workflow:

Git main branches

The main branches are the same. The origin server (or central repository like Github or Bitbucket) holds two main branches with an infinite lifetime:

  • Master: This branch always reflects a production ready state, and it’s the branch that it’s deployed to the production server. Releases are tagged from master.
  • Develop: This branch is used for development and integration of changes. It always reflects a state with the latest delivered development changes for the next release, and it’s deployed to the development environment to allow other Agile team members to have access to those new features and test them.

IMPORTANT: Master and develop should never be modified directly.

Git supporting branches

The supporting branches are the same as well. These are created temporarily in the system to make changes and collaborate without affecting the master and develop branches directly.

  • Feature branches: These branches are created from the develop branch, and are utilized to develop new features.
  • Release branches: These are created from the develop branch when the Agile team agrees that the code is stable and is ready to be released to production. This allows the team to isolate that release from the develop branch, so others keep developing new features and integrating those changes in the develop branch while the release is tested and approved. Release candidate branches are deployed to the staging server. Any bugs found during testing are fixed in that branch.
  • Hotfix branches: These are created from the master branch, and are used when changes on develop are not release-ready and a fix to production is required that cannot wait until the upcoming release is stable.

Git branching and merging

The revisions of the workflow are noted in the merging process. These are the conventions to create and merge branches in the system:

  • Feature branches:
    • Branch off from develop.
    • Create a pull request to merge back into develop.
      • If everything looks okay, merge and delete the supporting branch, else create comments in the pull request until changes look fine, or close the pull request and cancel the merge.
  • Release branches:
    • Branch off from develop.
    • Create a pull request to merge back into develop AND another one to merge to master.
      • If everything looks okay, merge and delete the supporting branch, else create comments in the pull requests until changes look fine, or close the pull requests and cancel the merge.
  • Hotfix branches:
    • Branch off from master.
    • Create a pull request to merge back into develop AND another one to merge to master.
      • If everything looks okay, merge and delete the supporting branch, else create comments in the pull requests until changes look fine, or close the pull requests and cancel the merge.

Once you have merged your changes in any of those cases, ensure you pull those from origin to get them in your local environment.

Tagged under: