#gitworkflows

[nedyaj-blog]

Examples of Git Workflows

According to Wikipedia, Git is a distributed revision control and source code management system that supports distributed, non-linear workflows. Each workplace has its favorite git workflow, and in this post we'll be covering the most common workflows for development teams.

Centralized Workflow

Centralized Workflow uses a central repository to serve as the single point-of-entry for all changes in the project - the master branch. Developers in a team clone this repository to their machines in which they can commit localized changes to the system without affecting the central repository. To make changes to the project, developers push their changes to the central master branch. However, before a develop can push any changes, they need to fetch the updated central commits and rebase changes on top of the updated project. Git handles conflicts between local and central commits by pausing the rebase process and giving the developer a chance to manually resolve the conflicts before continuing. While this is a perfectly capable workflow, Centralized Workflow does not utilize some powerful features that Git has to offer. For a more streamlined process, let's look into another workflow.

Feature Branch Workflow

Feature Branch Workflow adds feature branches into the mix which encourages collaboration and communication between developers. In this workflow, developers create feature branches to work on instead of the master branch. In doing so, multiple developers can work on a single feature without altering the main codebase. Because Git doesn't make a technical distinction between master and feature branches, developers can stage and commit changes to feature branches like they do in the Centralized Workflow. Once a feature is complete, a developer can push the branch onto the central server and submit a pull request to have the branch merged with master. Pull requests encourage developers to discuss and review the changes being made before it is a part of the main codebase. Once the pull request has been accepted, publishing the feature is very much the same as it is in Centralized Workflow - make sure that local master is synchronized with the upstream master, merge the feature branch into master and then push the updated master to the central repository. The Feature Branch Workflow is an incredibly flexible way to develop a project; however, sometimes it offers too much flexibility when it comes to larger teams. For a more organized way to managing feature development, release preparation, and maintenance, let's talk about the Gitflow Workflow.

Gitflow Workflow

Gitflow Workflow defines a strict branching model designed around project release that provides a powerful framework for managing larger projects. This workflow does not introduce anything new in terms of concepts and commands beyond what we've already covered, but it does assign specific roles to branches and how they interact. Like the previous workflows, Gitflow Workflow also utilizes a central repository and developers work locally to push branches to it. The difference lies in the specific branch structures of the project.

Historical Branches

Instead of one master branch, there are now two branches to record the history of the project - master and develop branches. The master still serves as the official release history while the develop branch serves as an integration branch for features. The rest of the workflow revolves around these two branches.

Feature Branches

Exactly like Feature Branch Workflow, each feature resides in its own branch which is pushed to the central repository once complete. The only difference is that instead of pushing changes to master, they are pushed into the develop branch. Feature branches never directly interact with master.

Release Branches

Once the develop branch has enough features for a release, a release branch is forked from develop. The creation of this branch indicates that a release is being prepared so no new features can be added after this point. Once the release is ready, it is merged into master and tagged with a version number. The release branch should also be merged with the develop branch, which may or may not be ahead since the release was initiated. Using release branches allows for one section of the team to polish the features of this particular release, while another team can be working on features for the next release. It also promotes well-defined phases of development when tagging each release with version numbers.

Maintenance Branches

Maintenance or "hotfix" branches are used to quickly patch and fix bugs in releases. Maintenance branches are the only type of branches that are allowed to branch directly off master. These branches should be merged into both master and develop and master should be tagged with an updated version number. The benefit of these branches is that it lets the team focus on fixing issues without interrupting the rest of the workflow.

Conclusion

In this post, we've covered three common workflows: Centralized Workflow, Feature Branch Workflow, and Gitflow Workflow. These workflows are just examples of what is possible, and are not strict rules for using Git with projects. The goal is to adopt or develop a Git workflow that works for you and your team so it is perfectly acceptable to adopt some parts of a workflow and disregard others. For a more in-depth discussion of Git workflows, as well as awesome examples and illustrations for better understanding, visit this article here.