Contribute like a Pro.A guide for git-branching model (Part 1)

Building a software in a team requires a clear understanding and proper management of the codebase. If the team members only know the "pull-push", you'll soon find yourself in the trap of resolving merge conflicts!

Developing while shipping the software may become tricky if the team is not familiar with version control. Git-flow plays a great role in agile development. I insist you to read every single word in this article, don't skim. Let's start exploring git-branching model.

Git-branching model

Implementing the git-flow, your repo should contain two main branches:

• master (or main)
• develop

Master branch is the main branch which is automatically created once you initialize a repo in a git. It is the origin of the repo and pre-exist. You'll find it written origin/master. This is the branch which must contain "clean codes", the codebase which is ready for deployment. You should not contribute or push codes direct to this repo! I'll tell you where to push your codes.

Develop branch is the branch which you should create. I advice you, to do this even if you're building alone. This is a branch which contains active codebase, the project at development state. Whether the feature is working or buggy, this is the right place for it. This is how you start:

# Create a develop branch and switch it on$ git checkout -b develop# Pull the codebase from master branch into your current branch(develop)$ git pull origin master

Other branches

Apart from the main two branches, there are three other branches. All these branches should be created within develop branch. These branches are:

• Features branch
• Hotfix branch
• Release branch

This is how you create them:

# Created as a sub-branch of develop branch (replace feature-backup with a branch name)$ git checkout -b feature-backup develop# Or a hotfix branch$ git checkout -b hotfix-443 develop

Naming convention and merging

Naming these branches follows the standard way. Such as feature-*,hotfix-* and release-*. So for example; feature-login, or release-1.0.1

After all your implementation in the feature branch (or any other branch apart from main branches) you should merge it back to develop branch then later to master branch (during production). This is how you do it:

# Switch to develop branch$ git checkout develop# Merge the feature branch$ git merge --no-ff feature-backup

Merging with flag --no-ff creates a new commit record. This helps to store historical information of the feature branch even after the merge. Thus, makes it easy to roll back in a particular feature just from the develop branch (even after merging).

Don't miss the next part of this article.

Thanks for reading!