One of the major issue while using git is setting the workflow and branch creation/merge strategy. The complexity increases as the number of developers and no. of parallel feature development increases.

Atlassian has an amazing git tutorial and workflow blog. Beginners can refer it for more detailed learning git and it's usage concepts.
Also, a popular git workflow model is made by Vincent Driessen at nvie. That is an amazing model you can learn concepts along with workflow.
Here we are approcahing a more realistic way to implement a git workflow based on the problem I have encountered and trying to solve it in structured manner.

Factors we have to count while defining the git workflow

  • Normal releases
  • Hotfix releases
  • CI/CD integrations
  • Collaboration between multiple developers working on single feature
  • Release branch strategy

Here we are approaching a more realistic way to implement a git workflow based on the problem I have encountered and trying to solve it in a structured manner.

Before we start, let's check the thumb rule;

Always create the branches from the master.
Never take a pull from the develop branch.

Since we are considering master to be the main branch where the source code of HEAD always reflects the production code.

Normal branch strategy and workflow with Git

Refer to the above diagram.
Each feature development starts with creating a new branch from the master.
git checkout -b <new_branch_name> master

A single developer working on a feature

In this case, we can create feature branch directly from the master
git checkout -b feature_2 master

This will create the branch feature_2 and checkout to the new branch created. Once the development is complete this can be merged into the develop branch. develop branch mostly used in the development server, there most of testing and review process happening.

Assume there is multiple parallel feature development in progress and each feature is handled by an individual developer and all the feature branches can be merged into develop branch once it is complete. At the end of the development cycle/sprint develop branch will reflect the code which is ready to deploy into production.

Preparing the release branch

git checkout -b release_one master
This will create a new release_* branch for the deployment. If you want to deploy all the changes from the develop branch to master, then run the following command (assume current branch is release_one ).

git merge --no-ff develop
This will create new merge commit and all the changes will be there in the release branch.

If any one of the features in the develop branch is not deploying into production.

There are cases if the team decides, not to deploy a particular which is already merged into develop branch.

In this case, there are two ways to prepare the release branch.
Let's say we postpone the release of feature three.

  1. Revert the feature_three branch merge commit from the develop branch.
    Assume current branch is develop.
    git checkout -b release_one master
    git merge --no-ff develop
    git revert <commit_hash>
    This above commands will create new branch release_one from the master and then merge the develop branch changes into release_one.
    The third commnd will revert the feature which decided not to deploy in production.

  2. Merge the feature branches instead of develop branch. This will be useful if git revert is failing or feature includes multiple merge commits or conflicting issues etc.
    git checkout -b release_one master
    git merge feature_one feature_two feature_three

Multiple people working on a single feature

Refer the Figure 1. In this case each developer created the branch from master. Which is knows as developer branches. A recommended naming convention is developer/<feauture-name>.
Multiple developer branches can be merged into the main feature branch as shown in the figure. And this feature branch can be merged back into the develop branch.
Since multiple developers working on the same feature using different developer branches, they should collaborate and communicate each other and update their respective branches from the main feature branch.

Hotfix releases

In case of any production issue or patch for a security vulnerability, then it should be deployed into production whenever it's ready. This Git workflow will not follow the normal development path.
git_hotfix_release_workflow

In this case, the hotfix should be created from the master.
Recommended naming convention is hotfix-*.

git checkout -b hotfix-security-fix master
This will create a hotfix branch from the master. After committing the changes this branch can be deployed into production. Make sure that you are merging it into develop branch as well.

CI/CD integrations

Implementing continuous integrations and continuous deployments are possible with Git. There are opensource git management software like Gitlab, hosted solution Gitbub are feature rich and supports CI/CD integrations.

Refer more Git related articles.