5 types of Git workflows that will help you deliver better code

Here at Buddy we’ve been working together since 2008. We’ve done many projects of different size and type, continually evolving and improving the way we collaborate. Upon hearing "collaborate" we usually think of words like "manager", "milestone", "sprint", "scrum" or "kanban".

As you know, every team has its own workflow based on the type of project, company size, team preferences, and many other things. The bigger the team, the harder it is to keep everything under control: problems with conflicts become more common, release dates need to be postponed, priorities keep getting changed on the fly – the list can be endless.

Adapting Git is the first step to solving these issues, as you can apply it to practically every kind of workflow. Here are five most popular types of Git workflow that you can employ in your business.

Basic

Image loading...

The most popular Git development workflow and the entry stage of every project.

The idea is simple: there is one central repository. Each developer clones the repo, works locally on the code, creates a commit with changes, and pushes it to the central repository for other developers to pull and use in their work.

Feature Branches

Image loading...

The basic workflow is great for developing a simple website. However, once two developers start working on two separate functionalities within one project, problems begin to appear.

Let’s say one of the developers finished their functionality and wants to release it. However, they cannot do that because the second feature isn’t ready. Making a release at this moment could result in messing everything up (to say the least).

This is where branches - the core feature of Git - come in handy. Branches are independent “tracks” of project development. For each new functionality, a new branch should be created, where the new feature is developed and tested. Once the feature is ready, the branch can be merged to the master branch so it can be released to the production server.

Feature Branches and Merge requests

The feature branch workflow assumes that all developers on the team have equal knowledge and position. In bigger teams, however, there’s always some form of hierarchy in the company.

In this case, you can employ merge requests and push permissions which allow you to restrict pushing to selected branches in the repository and maintain full control over the code.

Before a branch is merged to Master, it needs to be verified and checked for errors. Junior developers can create a merge request and assign it to one of the Seniors, so they can review the code and leave comments. If everything’s okay, the request is accepted and the branch is merged.

Gitflow

Image loading...

The bigger the project, the more control you need over what and when is released. Your projects require more unit and integration tests, which now take hours to run. However, you don’t run such tests on branches where features are developed.

This can be resolved with Gitflow, a Git development workflow invented and described by Vincent Driessen in 2010.

This workflow employs two parallel long-running branches:

• Master
  • used for releases only
• Develop
  • created from Master, this is the home of all completed and stable features prepared for the next release

When you start working on a new feature, create a new Feature branch from Develop. Create as many feature branches in parallel as you want and need. When the work is done and the feature is tested, merge the code back to Develop.

Then, when the time to release comes, isolate the new features from the Develop branch on a new Release branch. Make sure that the release is well tested and stable.

Depending on the character of your project, it might be a good idea to release an RC (Release Candidate) version of your software to the public.

When the release is stable and all kinks are ironed out, merge your release branch back to Master and deploy to production!

Forking workflow

Just like on the open sea, in the open-source everything's up to the captain. In software terms, the owner of the repository decides who can push to the repo. Although the idea of open source is that everybody can contribute to the project, it’s hard to think of Linus Torvalds giving unlimited repository access to the Linux project to anyone eager to tinker with his code, isn't it?

This problem is solved by forks: any time a developer wants to change something in an open-source project, they don’t work directly on the project's repository. Instead, they fork it, effectively creating a copy of the entire repo. Then, the developer is free to work on the new feature in whatever fashion they please. It's worth mentioning that forking opens up possibilities of creating custom versions of certain components tuned for specific applications, too. A developer or a company can fork a repository and take the code in an entirely new direction which wouldn't be allowed by the owner(s).

In most of cases, however, when the work is done, a pull request is created, which compares the changes the developer introduced to their fork to the state of the forked repository. From there, the community and the project's owners can review, discuss, and test the changes. The final call remains in the hands of the project's skipper and their deputies.

Your very own Git workflow

The Git workflows that described here are just examples. The greatest feature of Git is that you can pick an existing workflow and easily adapt it to your needs. For example, in Buddy we use a modified Gitflow with an additional Stage branch. And it works perfectly for us.

Happy coding with Git!