Git best practices for Agile projects and distributed teams

        Agile Software Development, Web Development

For those who are not familiar with Git, it’s one of the most popular version control systems, created by Linus Torvals for the development of the Linux kernel.

One of the best features of Git is that every directory on every computer is a full-fledged repository with complete history and full version tracking abilities, independent of network access or a central server. This allows teams to work on their own environments with a full version of the system, and minimizes code conflicts, because every team member works independently with their own code, until it is committed and pushed to the central repository.

However, that feature alone is not enough to avoid releasing issues to a production environment. For that reason, it’s recommended to follow these best practices:

Development, Staging and Production environments

At a minimum, every project should have three environments, all with the same server settings:

  • Development environment: It’s used to test work that is not yet stable. This allows the Agile team to try new features that are in development and receive feedback before they are ready to be released.
  • Staging environment: It’s used to test code that is about to be released to production. Ideally, when a future release is going to be tested, a full database backup from the live environment should be deployed in this environment, in order to truly test the effect of that release in the system.
  • Production environment: It’s the live site. Only fully tested and approved releases are deployed to this environment.

Git main branches

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 following branches 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

These are the conventions to create and merge branches in the system:

  • Feature branches:
    • Branch off from develop.
    • Merge back into develop.
  • Release branches:
    • Branch off from develop.
    • Merge back into develop AND master.
  • Hotfix branches:
    • Branch off from master.
    • Merge back into develop AND master.

In addition to that:

  • Before you create a new branch or merge a branch, ensure that your pull changes from origin (central repository) to ensure that your local repository is up to date.
  • Once you have merged your changes, ensure you push those to origin to make them available to the rest of the team.

About Luis Cuellar

Co-founder and Agile Coach, in charge of leading, managing and coaching agile project teams to achieve a high level of performance and quality in delivering projects that provide exceptional business value to government agencies and nonprofit organizations.
This entry was posted in Agile Software Development, Web Development and tagged , , , , , . Bookmark the permalink.

Comments are closed.