Different Types of Git Workflows
Every team that collaborates on projects usually has some kind of “workflow”. Workflow is the approach or method that collaborators share when they divide and conquer a project. A productive team has a well energized and efficient workflow method. But there are other ways to interpret the meaning of workflow. When working with site developers and other technically capable team members, workflow collaboration will most likely correlate to workflow code. Within this article, the focus will be on items related with code collaborations. The components involved in such collaborations are usually items such as: introducing changes, solving conflicts, using branches, and more.
As stated above, every company has its own team workflow that is tailored to the necessities of the projects and work the team has been assigned. Factors such as company size, team preferences, and job sector also play a role in this as well. For example, the larger the team, the harder it is to have everything maintained under control. Large teams may run into issues with conflicting data, clashing ideas, needing extensions on release dates, changing goals or priorities, etc.
By employing Git into your workflow, the issues above may be addressed more swiftly. Git is very adaptable as well and can be combined into every kind of workflow there is. We will continue the conversation of Git workflows below and discuss the top five types of Git workflows that may be applied to your business
The first type of Git workflow is Basic. This is also the most popular workflow among Git developers and the is found at the beginning stage of every project. The idea of Basic workflow is very comprehensible. There is one central repository. What this means is that each developer will clone the repo, work locally on the code, make a commit with various changes, and then finally put in in the central repository for other developers to take and put in their own individual work.
While the basic workflow is a fantastic method for creating and developing a simple website, it doesn’t do well with any complications. If two developers need to work on two separate functionalities inside one project, then Basic workflow is no longer an ideal method for the team. For example, one of the developers has just finished their functionality and wants to release it. They cannot release it if the second feature from the second developer is incomplete. If they want to make the release anyway then this will result in unfavorable issues for the developers, not to mention the project at hand. The next workflow methods will assist in addressing the solutions for this conundrum.
Feature Branch Workflow
The second type of Git workflow is Feature Branch Workflow. This workflow is where branches – the core feature of Git – are readily available to developers. Branches are independent “tracks” of developing a project. For each original functionality, a new branch must be made. This new branch is where the new feature would be developed and tested. Once the feature is ready, the branch can be fused to the master branch so it can be released to the job and be LIVE.
Merge Requests within the Feature Branch Workflow
However, the feature branch workflow assumes that all developers on the team have the same background, knowledge and position. This can be a problem, especially in larger teams that have a form of status hierarchy (for example, Junior Developer vs. Senior Developer.)
With this predicament, you may use merge requests and push permissions within the Feature Branch Git Workflow.
The suggested way to utilize this type of workflow would follow a hierarchal method that distinguish between various levels of staff. 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 Senior developers. The Seniors in turn can review the code and leave any necessary comments. If everything seems satisfactory to move forward, the request is accepted and the branch is merged.
Merge requests may also be combined with push permissions that allow developers to restrict pushing changes to specific branches in the repository. This also keeps the team in full control over the code.
Gitflow Workflow is the fourth workflow method. This method is suggested for large projects and collaborations. The bigger the project, the more control you need to have over what and when is released. The projects will necessitate more unit and integration tests, which are now counted in hours. These tests are not as common on branches where features are developed.
The answer to the above predicaments are Gitflow. Gitflow has not been around for long, it was actually created by Vincent Driessen in 2010. This workflow solution employs two parallel long-running branches: Master and Develop. The “Master” is always ready to be released on LIVE. This also means that the “Master” has everything fully tested and approved (which means that it is production-ready).
The “Develop” branch is the branch where all feature branches are merged. Then the “Develop” branch also becomes the branch where all tests are performed and accounted for. Once everything has been thoroughly checked, processed, and fixed, then it can be merged to the Master.
The fifth and final workflow method is the Forking workflow. In open source projects the final decision of who can push to the repo goes into the hands of the owner of the repository. However, the idea behind open source is that everyone on the team has the ability to contribute to the project. Yet, the idea of having a head Senior Developer and creator allowing unlimited repository access to their time sensitive projects to anyone on the team who wished to make changes or improve the code seems highly implausible.
Luckily this problem is easily solved by forks in the workflow. This concept means that at any time a developer wants to modify something in an open source project, they don’t clone the official repo directly. Rather, they fork it to create a copy where they make their changes. When the work is complete, they make a pull request so that the owner of the repository (i.e a Senior developer) can review the changes and decide whether to accept and merge them to his project.
At the center of the Forking workflow concept is an idea similar to feature branching. Instead of creating branches, a fork of the repo is made. Then rather than having to complete a merge request, all you have to do is create a pull request.
Guidelines and Examples
The discussion above of different workflow methods can seem like a lot of information at once. Below are two approaches of how to apply a couple of workflow models in the real developing world.
- Short lived work: A typical problem that most developers have is wasting too much time on cleanup. This problem can be easily handled by a merge, more specifically a squash merge. Pretend that I have created a feature branch and then went to create a series of checkpoint commits over the next hour:
git checkout -b private_feature_branch
git add file1.txt
git commit -am “WIP”
When that is complete, instead of running a typical git merge, I’ll run:
git checkout master
git merge –squash private_feature_branch
git commit -v
After that I will take a minute of my time to compose a detailed commit message.
- Larger work: There are times when a feature sprawls out into a lengthy, multi-day project. Most of the time these lengthy projects are accompanied by features with dozens of small commits.
As an example, I decided that my change should be broken into smaller changes, which would make the squash method inapplicable to my end solution. As a word to the wise, always ask yourself if the task or feature would be easy to code review. Then go from there. If the checkpoint commits followed a logical progression, then I will use rebase’s Interactive Mode. The Interactive mode is a powerful tool. This can be used to edit old commits, split them up, reorder them, or in this case erase some of them. On my feature branch:
git rebase –interactive master
This then opens an editor with a full list of commits. On each line is the operation to perform, the SHA1 of the commit, and then is followed by the current commit message. A legend is included with a list of possible commands. By default, each commit uses “pick,” which doesn’t modify the commit.
pick ccd6e62 Work on back button
pick 1c83feb Bug fixes
pick f9d0c33 Start work on toolbar
I then amend the operation to “squash,” which erases the second commit into the first.
pick ccd6e62 Work on back button
squash 1c83feb Bug fixes
pick f9d0c33 Start work on toolbar
When I save and close, a new editor prompts me for the commit message of the combined commit. Then the operation is complete!