Some Git projects can become exceedingly complex, involving many different developers working from remote locations and tens of thousands of lines of code.
There are also many commits to consider, along with a number of administration tasks.
It is all too easy for such projects to get out of control so it is therefore vital to adopt a project management system that can keep everything in order and deliver a successful outcome.
Key to this is choosing an appropriate workflow that suits your project and working practices. There are a number of different approaches and choosing one can be confusing. It should be remembered, however, that these approaches are simply guidelines, not rules set in stone. It is therefore completely legitimate to take aspects of different workflow approaches and create your own, tailored approach.
Here are four approaches to Git workflows that are worth your consideration.
A centralised workflow is best used in situations where the development team is already familiar with Subversion.
The centralised approach to workflow allows the team to enjoy all the benefits associated with Git without the need to adopt a completely new process. It can also operate as a gentle transition into more Git-specific workflows.
The centralised workflow approach uses a single central repository as a focus for all
project changes. Rather than ‘trunk,’ the development branch is named ‘master’ and every change is committed to this branch. This type of workflow does not need any branches in addition to the master branch.
Feature branch workflow
A second type of project management system within Git is that of the feature branch workflow. This system builds on the approach of the centralised workflow and is a logical next step as the team becomes more comfortable with the features of Git.
The feature branch workflow encapsulates new features into a series of dedicated branches, thus enabling the team to use pull requests in order to discuss changes before they are integrated into the main project.
It still uses a central repository, with master representing the official project history. Instead of making commits directly to a local master branch, however, developers create a new branch each time they begin working on a new feature.
The Gitflow workflow can significantly streamline a Git release cycle by the use of isolated branches for managing feature development. It also handles release reparetion and maintenance and a strict branching regime is helpful in introducing a welcome structure into larger Git projects.
Again, a central repository is used and the development team works locally to push branches to this central repository. The branch structure is different, however, and uses two branches instead of a single master one to record the project’s history.
The forking workflow follows a distributed workflow model that is designed to take full advantage of the branching and cloning features of Git.
It is regarded as a reliable and safe system for managing large development teams and is useful in managing commits from any untrusted contributors. Instead of cloning the official repository, developers who begin working on the project fork this repository and create a copy on the server. This is then their own personal public repository and other developers are not allowed to push to it. The developer then does a git clone to copy the repository to their local machine and this then serves as their own private development environment for the project.