Here at Buddy we’ve been working together for over 7 years. 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 shall focus on stuff related with 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, etc. etc.
Employing Git is the first step to solving these issues, as you can adapt it to practically every kind of workflow. Here are five most popular types of Git workflows that you can employ in your business.
The most popular workflow among Git developers 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, makes a commit with changes, and push 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 has 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 developing a project. 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 LIVE.
Feature Branch 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 (Junior vs. Senior.)
In this case, you can employ merge requests and push permissions.
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.
Merge requests can be combined with push permissions that allow to restrict pushing changes to specific branches in the repository, so you can keep full control over the code.
The bigger the project, the more control you need over what and when is released. Your projects require more unit and integration tests, which are now counted in hours. Usually, you don’t run such tests on branches where features are developed.
This can be resolved with Gitflow, invented and described by Vincent Driessen in 2010.
This workflow employs two parallel long-running branches:
“Master” is always ready to be released on LIVE, with everything fully tested and approved (production-ready).
“Develop” is the branch to which all feature branches are merged and where all tests are performed. Only when everything’s been thoroughly checked and fixed it can be merged to the Master.
In open source projects it is the owner of the repository who decides who can push to the repo. However, the idea of open source is that everybody can contribute to the project. Still, it’s hard to think of Linus Torvalds giving unlimited repository access to the Linux project to anyone who’d like to change or improve its code.
This problem is solved by forks: any time a developer wants to change something in an open source project, they don’t clone the official repo directly. Instead, they fork it to create a copy. When the work is finished, they make a pull request so that the owner of the repository can review the changes and decide whether to merge them to his project.
At its core forking is similar to feature branching, but instead of creating branches a fork of the repo is made, and instead of doing a merge request you create a pull request.
Your very own
The workflows that I described are just examples. The greatest feature of Git is that you can adapt it to your needs and create your very own workflow. For example, in Buddy we use a modified Gitflow with an additional stage branch. And it works perfectly for us.
Share your workflow in the comments so we can add it to the list and help other developers find their perfect flow!