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".
In this article, we'll have a closer look at five different Git workflows and the way they tackle various aspects of code collaboration: introducing changes, solving conflicts, using branches, and more.
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.
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.
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.
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.
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:
- used for releases only
- created from
Master, this is the home of all completed and stable features prepared for the next release
- created from
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
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!
Check out Devchild's excellent visual representation of Gitflow in practice:
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.
At its core, forking is similar to feature branching. Instead of creating branches, a fork of the repo is made, and instead of working with merge requests you create pull requests, which are a way of asking to include your changes in the forked project.
Did you know that Ubuntu started as a Debian fork? Read this article to learn more about the famous software that came to life as an effect of employing the forking Git workflow.
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!