Git is ubiquitous and pretty much standard for many Software Developers nowadays as far as Version Control Systems (VCS) are concerned. There are quite a number of ways developers work using Git. The workflows individuals/teams choose usually depend on factors like project type, project size, team size, dev tools integration etc.
In this post, we’ll be discussing two popular Git workflows you should know — Gitflow and the Forking workflow. Let’s dig right in!
Gitflow
Gitflow workflow. Source: nvie.com
Developed and popularized by Vincent Driessen, the Gitflow workflow is a branching model built around release management. It involves the use of two main branches (master and develop) and three supporting branches (feature, release and hotfix), with strict branch off and merge rules.
The master branch is the production/stable branch while the develop branch reflects the latest changes to the software for the next release. A feature branch is created when a new feature is to be added.
When all the features for the next release have been merged to develop and it is ready to be released, a versioned release branch is created off develop. This branch does not take any new features — only bug fixes. When the release branch is ready to be taken to production, it is merged into master and tagged with the release version. It is also merged into develop so that develop is updated with the fixes.
If a bug is discovered in production, a hotfix branch is created to fix it. This branch is merged into master (and versioned), as well as into develop or to release (if one currently exists).
You can learn more about this workflow from Vincent himself in his article titled A Successful Git Branching Model.
Forking workflow
Forking workflow
The Forking workflow is common in open source projects where anyone can contribute. Outside collaborators are not given write access to the official repository. They must first fork the repository, create a new branch, make the changes they want, then send a Pull Request to the official repository.
A fork is a server-side clone of a repository. You can fork any public repository on GitHub and you’ll get a copy of it on your own account. You can make any changes you want to this fork. Forks need to be regularly synchronized with the upstream (official) repository so that they can have the latest changes.
A Pull Request (PR) is a request to merge the changes from a branch in a fork to an upstream repository. A project maintainer may accept, reject or request changes to a PR before it’s merged.
You can learn more about this workflow with this tutorial from Atlassian.com.
Last modified on 2023-03-14