Setting up a proper GIT workflow

Photo by Yancy Min on Unsplash

When working in a team or as an individual in a Software Project, it is mandatory to have a proper Git workflow. It will help you to release features and fixes via CICD to your clients easily without any confusion. Once the proper Git workflow is set up, Developers can focus on the software development adhering to the workflow and ship changes.

CICD

Branching Strategy

At the end of a sprint, when we’re ready to do a release, we create a new release branch from the main branch. Developers can submit their pull requests to the main branch. Within a Sprint, several deployments can be done to test the features (DEV testing). When all verification and testing are done (STAGING testing), a new release branch is created from the main branch and deployed. This release branch contains all the fixes and feature that is in the main branch.

Git workflow

Developers are not allowed to commit directly to the main branch. Instead, they have to fork the repository, finish the development in the forked repository, and create pull requests to merge their change/fix to the main branch.

If a hotfix needed to be released after the production release, we could do a cherry-pick. First, merge the pull request with the fix to the master branch. Then cherry-pick the hotfix commit from the master branch and apply that to the release branch.

Use a consistent naming convention for your feature branches to identify the work done in the branch. Check below examples:

• feature/{JIRA-ID} or {description}.
• feature/{JIRA-ID} or {description}.
• hotfix/{JIRA-ID} or {description}.

Personally, I prefer the JIRA Id.

Forking Workflow

This is one of my favorite workflows, and most open-source projects follow this approach.

The first step of this approach is to fork the repository that you want to contribute to. This fork is your own copy of the original repository. The next step is to clone this fork. Once the cloning is done, you can create a branch according to the guidelines you have established in the team. When you are ready to commit, You can push the changes to your forked repository. The final step is to file a pull request with the original repository.

There are more things to worry about when doing this for real, and you might want to practice with one of your own repositories first. Check this great video which explains this approach nicely.

There are other workflows such as Feature Branch workflow and Centralized workflow. As a team, you can discuss and decide which approach to follow. The most important thing is that we need to ensure that every team member understands and can utilize the decided workflow to ship changes without many hurdles.

Summary

In this post, I have described what we were doing in our team, but I understood that there are other ways to contribute and release changes to production. 

The branching strategy and the git workflow are a crucial part of your CICD process. According to my experience, having a CICD process will give us more time to focus on business logic and codebase.

References:

1. https://devblogs.microsoft.com/devops/release-flow-how-we-do-branching-on-the-vsts-team/
2. https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops
3. https://support.gitkraken.com/working-with-commits/cherrypick/
4. https://git-scm.com/docs/git-cherry-pick
5. https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow
6. https://youtu.be/k6KcaMffxac [Contributing to Open Source on GitHub for beginners]