Git workflow for Startups

February 14, 2021

Small or big, every technology company works with software developers. To increase productivity and to work in parallel, developers use a version control system (VCS) like Git.

Git:

Git is a free and open-source distributed version control system designed to handle everything from small to large projects with speed and efficiency. Git is designed to track changes in any set of files, and to coordinate work among programmers cooperating on source code during software development. Its goals include speed, data integrity, and support for distributed, non-linear workflows.

GitHub:

GitHub is a provider of Internet hosting for software development and version control using Git. It offers the distributed version control and source code management functionality of Git, plus some additional features.

Technology companies have defined a great workflow using Git to ensure smooth collaboration within the team and to effectively deliver appropriate code at any time of the software development.

Since Agile methodology is the most promising model in today’s tech companies, CI/CD (Continuous Integration / Continuous Deployment) plays a major role for teams to be release ready, develop features and fix bugs in iterations.

Developers work in parallel by using branches. A branch in Git represents an independent line of development. Each developer can work in isolation without impacting anyone else’s work. By default, the one branch that exists for all Git Projects is the master branch.

The types of branches we use in Git projects are:

master
develop
feature/
fix/
chore/
release/
hotfix/

The base branch for a project is the develop branch. This is the branch that holds the most updated working code and is being constantly updated with features and bug fixes.

When a new feature needs to be developed, a fresh branch needs to be forked from the latest develop branch. The branch naming convention is as described:

feature/ (for new feature addition or as called as a story)
fix/ (for bug fixes)
chore/ (for regular maintenance work)
release/ (for deployment to production)
hotfix/ (for emergency fixes in the production code)

How to fork a new branch from the latest develop branch?

$ git checkout develop
$ git pull
$ git checkout -b {{branch_name}}

For example:
$ git checkout -b feature/myNewFeature

The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into the develop branch.

One can work on a feature or fix branch independently and add as many commits as they want to. A recommended procedure is to write logical code in a section and commit often (as if working in small iterations).

How to commit your changes to your branch?

$ git add .
$ git commit -m “My meaningful git commit message”

For more details about wiring appropriate git messages, visit the blog “The Art of writing great commit messages”.

Once the development is done on the feature, it is time to push the branch to GitHub.

$ git push origin {{branch_name}}

For Example:
$ git push origin feature/myNewFeature

After working on a feature/bug, the developer needs to raise a PR (Pull Request) in GitHub against the develop branch. A proper title along with some brief description needs to be provided about the work done in that branch. Additionally, proper tags need to be assigned to the PR for better categorisation.

Team members must then review the work done on that branch that is visible in the PR. Members may comment or make suggestions on the code changes made, to fix identifiable issues, make optimisations and enhance code hygiene/quality. The owner of the branch must discuss the comments/suggestions with the team and make necessary amendments in the same branch and push the code changes.

With every commit, Git will run a CI pipeline (Continuous Integration) to run automated tests and any build related scripts. It is necessary to ensure the build-in CI pipeline passes for the final commit of the branch before it gets merged.

Note: The PR must be blocked from merging if the CI pipeline reports a failure of any kind.

As soon as we get a minimum of X approvals on the PR, the owner of the branch can submit their consent of merging this PR. (It is usually recommended to get 3 approvals on any PR in mid-size teams)

Only the senior developers or the leads must have the rights to merge code into the master, develop and release branches.

We consider the master branch to be the main branch where the source code of HEAD always reflects a production-ready state.

We consider the develop branch to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”.

Releasing code to Production:

Release branches support the preparation of a new production release. They allow for last-minute changes for a production release. Furthermore, they allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, the develop branch is cleared to receive features for the next big release.

The key moment to branch off a new release branch from develop is when the develop branch reflects the desired state of the new release. At least all features that are targeted for the release-to-be-built must be merged in to the develop branch at this point. All features targeted at future releases must wait until after the release branch is branched off.

Finishing a release branch:

When the state of the release branch is ready to become a production release, some actions need to be carried out. First, the release branch is merged into master (since every commit on the master branch is a new release by definition). Next, that commit on master must be tagged for easy future reference to this historical version. Finally, the changes made on the release branch need to be merged back into the develop branch, so that future releases also contain these bug fixes.

HotFix:

Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release which was unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version.

When finished, the bug fix needs to be merged back into master but also needs to be merged back into the develop branch, to safeguard that the bug fix is included in the next release as well. This is completely similar to how release branches are finished.

Note: Do not commit directly to the following branches:

master
develop
release

Resources:

Acknowledgements:
Special thanks to nvie.com for the images. These git flow images are well defined and self explanatory. We are using them in this blog only for educational purposes.

Please follow and like: