Find the right pull request workflow for your dev projects

Centralized workflow

Centralized workflows common to older version control systems need to be re-engineered when organizations move to a distributed repository because pull requests only work in conjunction with two separate repositories or code branches.

However, a centralized workflow can still use Git or other version control systems as a centralized repository for all project changes. In this workflow, everyone commits changes to the master. One of Git’s attractions is that it allows teams to continue to use a centralized workflow, while they decide how and when it’s worth to try out other pull request workflows.

A big advantage of Git over a centralized version control system like Apache Subversion is that Git allows each developer to tinker on their own copy of a codebase independent of other changes, and then merge what they want when appropriate. Git also supports a branch and merg model which reduces problems with multiple people and simultaneous changes to a codebase.

Pull request workflows

Some of the popular pull request workflows include feature branch Workflow, forking workflow, Gitflow, GitHub flow and Gitlab Workflow.

The basic process for all pull request processes consists of several steps:

1. Developer pulls code from shared repository.
2. Developer adds new code in their local repository, which is now called a code branch.
3. Developer pushes the code branch to a shared repository like GitHub.
4. Developer files a pull request, which is sent to other developers interested in this change.
5. Other developers review the code and make changes.
6. Someone merges the new code into the official repository and closes the pull request.

Feature branch workflow

In a feature branch workflow, developers work on their local code changes, and then file a pull request to pull the code changes from their local repository or a separate branch repository managed by a repository service. A developer can also file a pull request if they have guidance problems from other developers.

Forking workflow

In a forking workflow, changes are pushed to a separate repository. Pull requests are sent to a project maintainer, who can decide whether to merge them back to the main repository. This workflow can also be used to notify a collaborator to pull in an updated code branch into their own repository.

Gitflow workflow

In 2010 Vincent Driessen developed Gitflow, which became a popular alternative to feature branching and forking workflows. The Gitflow workflow is similar to the feature branch workflow, except it uses a staging Develop repository to make it easier for developers to discuss code updates before they merge changes to the Master repository.

Gitflow is more flexible than feature branch and forking workflows. While Driessen believed that Gitflow was easy to understand and allows for the shared branching and releasing processes, other developers argue that it’s more complicated than most development teams require and have created their own streamlined variants.

GitHub Flow

GitHub developed GitHub Flow, which is a streamlined alternative to GitHub that is better suited for continuous integration and continuous deployment. Git co-founder Scott Chacon argued that one of the main issues with Gitflow is that it’s organized around the idea of a big release. This organization can complicate things when developers push one or more code updates per day. Here is an example GitHub Flow process:

1. In GitHub Flow, a developer creates a descriptively named branch off master.
2. A developer commits to that branch locally and then pushes updates to the same named branch on the server.
3. A developer sends a pull request when the branch is ready to merge or the developer needs help.
4. After the code is signed off by someone else, it can be merged into the master branch and pushed into deployment.

Chacon said that Git is complex and a developer should avoid anything that further complicates the workflow. He noted that Gitflow makes sense for more formal releases on a longer-term interval and the occasional hot fix. But, he feels that GitHub Flow is a better choice for companies that push updates daily.

GitLab Workflow

Meanwhile, GitLab defined another variant of Gitflow called Gitlab Workflows, which extends the discussion of Gitflow to include specific branches for explicit situations, such as production branches, environment branches, and release branches.

In this model, the production branch creates a separate branch from the master that represents what is currently “in production.” Said branch could be needed in cases where you can’t deploy to production every time you merge a feature branch. The “environment branch” approach creates branches that are aligned to specific, non-production environments such as “staging” or “qa.” And the “release branch” helps to clearly manage and track all the changes that are assembled for a specific release.

Another important part of the workflow discussion is how to foster and encourage collaboration within the extended team. GitLab made collaboration and encouraging contribution a top priority, so they created the GitLab Merge Request to manage code discussions and code reviews prior to the code changes in a given branch merger into the master.

Other approaches

Of course, every development team will to want to find the pull request workflow that works best for them. Outside of the options listed above, you can also consider the following options for pull request workflows:

• Gitworkflow: a dogfood workflow used on the git.git project that has a process to identify which topics can cause conflicts with other works in progress;
• OneFlow: an anti-gitflow workflow that addresses concerns over Gitflow’s difficulties to find things in the change history of large codebases; or
• An unnamed workflow developed by Scroll.com CTO Kushal Dave