Shreya Das
- May 23
- 5 min read

Git WorkFlow and Branching Strategy

What is Git?

Git is an open-source version control system(VCS) that helps to track the changes in the code.

What is GitHub?

GitHub is the version control web-based software service where developers collaborate, create, and manage their code and also can track the changes in their code. With GitHub, developers can communicate by sharing their code and other artifacts to create a software project.

What is the Basic Difference between Git & GitHub?

Git is the VCS Software where developers can keep their work in local
GitHub is a cloud-based VCS service provider. If developers want to keep their work whatever they are doing through Git and want to keep the online version of it, they can use GitHub.

Benefits of Git Hub:

GitHub allows developers to store their work also can collaborate with others
This cloud-based platform facilitates the interaction of people who can view, contribute, and share each other’s work
It provides an environment that encourages the improvement of code and also provides a system with which coders can keep track of the changes made during the coding process
It is the community where people can participate in working code and solutions. These collaborations can be public or private. It is all about collaborative effort, collaborators come together to create, review, and improve the code as well as drive new ideas, and solutions from the project repositories

Workflows in GitHub:

Git users follow the Branching concepts in GitHub. It is the most popular branching workflow concept for all kinds of users not just for developers. The Git Flow was made by Vincent Driessen, it is a very easy to understand branch based workflow.

Why Branches?

When we have a team to develop a software and everyone has to develop simultaneously then branching concepts helps developers to develop their features in a separate workspace. When developers are done with their respective features then they can merge their code in the main branch. This way every developer's work can be kept separate from others which helps to fix the mistakes easily.

This way we can keep protecting the main code and any changes done in any branch do not affect the other branch of code.

**Note: Git branching strategy varies based on organization policies. This article will cover one of the branching strategy.

Git flow is based on two main branches and those two are long-lived branches.

master/main
- master branch contains the production version of the code. When all the development is done the code can be merged into the master branch from the release branch
release/develop
- release branch contains the pre-production code. When the code of feature branches is done they can be merged to the release branch.
features
- Feature branch is created to develop a specific feature of the software, it doesn’t have any direct connection with the master branch. Once the development of the feature is done then it can be merged with the release branch. Once the merge is completed feature branch can be deleted.
- It can be one feature branch or multiple feature branches based on the sprint

Below is the high-level flowchart of how the workflow works on GitHub:

Branch creation flow

Branch merging flow after development

Before going to the Branching Strategy example, let's cover important Git commands used in this article

Create git repo->initialize git-> create/modify the code->git add->data moved to staging area->git commit->git push->GitHub

Git Repo: Git Repo represents Git Repository which is nothing but a folder
Git status command: Git status is to check the status of the Git software
Git init command: Git init to initialize the git into the folder (make a track of the normal folder as git folder). It needs to be done only one time throughout the project.
Git add: Through git add we can add the new or modified files to git staging
Git Staging: Git staging is not committed files i.e. the files are ready to commit
Commit command: commit is the checkpoint. Any changes in the file we can add through git commit.
Git push: Through git push all the source codes that are committed can be sent to the GitHub repo.
Git clone: To create a working directory(Git Repo) in the local from the remote server

Below is one of the examples to showcase the GitHub workflow:

Step 1: Create a new Repository in Git Hub with "User A"

By default master branch is getting created.

Step 2: Create a folder in the local

Step 3: Initiate git to the folder

Step 4: Clone the GitRepo created in GitHub

Git repo is cloned successfully into the local git repo. By this way we can connect these two folders i.e. Local GitRepo with GitHub GitRepo.

Step 5: Create Branch

First check the status of the Repo. By default, it should point to the master branch

Now create new branch release branch

Now create another two feature branches and check the branch status using git branch command

Step 6: Add files to the feature branches

1. Created two files

2. Check the status of the git Repo using git status command

3. Currently git is pointing to the master branch, but we want to add those files into the feature branches

4. Switch the branch from master to feature/changes1

5. Now git is pointing to the feature/changes1 branch

6. Add the NewFile1.txt to the feature/changes1 branch

7. Now check the git status to confirm the file added properly

8. NewFile2.txt file is still showing as untracked as we have not added this file to any branch

9. Commit the file into the Git Repo

10. While doing commit we have to give a commit message.

11. Now push the NewFile1.txt to the GitHub repo using git push command

12. Now if we check into the GitHub the new repo with new file will display

13. Now switch from feature/changes1 branch to feature/changes2

14. Add NewFile2.txt into this branch

15. Now commit the file

16. Push the File to GitHub repo

17. Now We have to push the release branch to GitHub

18. Need to switch the branch first

19. Then commit and use the git push command

Step 7: Merge files from the feature branches to release branch

1. Create a pull request from feature/changes1 branch to release branch

2. Add a reviewer "User B" before the merge to have the peer review. By that way we can eliminate the error of the code and we can work as a collaborative way

3. Now reviewer i.e "User B" login to the GitHub. He reviews the code from their side and approves it for merge or they can request, if any changes required