Based on the feature branch model, the major Git platforms have extended the workflow to include merge/pull requests as integral parts.
The major enhancement (compared to the feature branch workflow) is the mandatory review process. Let’s discuss a scenario to show merge and pull requests. A developer, Manuel, develops a new function. He does so by creating a feature-1 branch and adding two commits (a8503d6 and 70996c6). When pushing to the remote repository, Manuel receives the following response:
git push --set-upstream origin feature-1
Enumerating objects: 7, done.
...
remote:
remote: To create a merge request for feature-1, visit:
remote: https://gitlab.com/git-compendium/workflows-github...
remote:
To gitlab.com:git-compendium/workflows-github.git
* [new branch] feature-1 -> feature-1
Branch 'feature-1' set up to track remote branch 'feature-1'...
The lines beginning with remote indicate the response by the Git server. In modern terminals on Linux and macOS, you can click the link directly (possibly together by holding down (Ctrl)). Alternatively, you can create the merge request via the web interface.
Manuel creates the merge request via the web interface and enters the name “Feature-1 merge request.” Note that this merge request isn’t a feature of Git itself, and you won’t find a reference to this request anywhere via git log. The metadata about the merge request, such as who created the request and when, is stored in the Git hosting provider’s database. If you switch providers at some point, this information is likely to be lost. A commendable exception is GitLab, which can import both the pull requests from GitHub and those from Gitea, including comments, as verified during tests.
Manuel enters Jane as the person responsible for the merge request. Jane reviews the new feature and asks for additional documentation for the new feature. Manuel adds the comment and commits the changes (commit e029614). Then, the version from the feature branch is installed on a test system. When the quality assurance (QA) team raises no objections to the new feature, Jane merges the changes into the main branch.
The workflow we’ve described is certainly widely used, not least because of the popularity of GitHub and GitLab. The processes aren’t complicated, and code review can eliminate errors before they reach the main branch. The workflow inherits the problem of branches running in parallel for too long when features are too large from the feature branch model. An additional problem with this workflow can arise if the time span between the pull/merge request and the merge itself is too long. Reasons for this delay can be that the code review doesn’t take place quickly enough or that too many problems are found during the pull request. Both extend the parallel runtime of the branches.
In contrast to the previous section, you may notice a few changes in the workflow. We wanted to highlight the difference between the purely Git-based workflow and the workflow presented in this section, which can only be implemented with appropriate Git servers.
You can fork foreign repositories using Git. In combination with merge/pull requests, you can also establish a workflow where all developers manage their own repositories to which only they have write access.
This approach is close to Linus Torvalds’ original idea. The inventor of Git, who had developed the software primarily to manage the Linux kernel, received a number of suggestions for improvements in the form of patch files as email attachments to the kernel mailing list. To save himself the work of incorporating and testing the patches, Torvalds suggested that patch developers maintain their own Git repositories where they can incorporate and test their own patches. Since GitHub didn’t exist back then, developers had to run their own Git servers, from which Torvalds could then pull, which is exactly what Git’s built-in server git daemon is for.
In a tech talk worth watching, Torvalds presented his motivation for creating Git in 2007, when it was just two years old. In his rather opinionated way, he condemned every other version control system, first and foremost Apache Subversion (SVN), which was the most widely used system at the time: https://www.youtube.com/watch?v=4XpnKHJAok8.
Forks with pull/merge requests are an extremely useful workflow for occasional contributions by different people on other people’s projects. However, with a manageable number of members on your team who are registered with the team in some way and who have permissions to access a central repository, you likely won’t need any forks for your project in this case.
Some advantages of using merge/pull requests include the following:
Some drawbacks of using merge/pull requests include the following:
Editor’s note: This post has been adapted from a section of the book Git: Project Management for Developers and DevOps Teams by Bernd Öggl and Michael Kofler.