DEV Community

Cover image for Contribute like a Pro. A guide for git-branching model (Part 1)
Ruheza, NS
Ruheza, NS

Posted on • Updated on

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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).

git-merge(2).jpg

Don't miss the next part of this article.

Thanks for reading!

Originally, posted here

Oldest comments (5)

Collapse
 
achimgrolimund profile image
Achim Grolimund

Good post, I'm eagerly awaiting the continuation

Collapse
 
maen profile image
Ruheza, NS

Thanks, will be released soon.

Collapse
 
matthewpersico profile image
Matthew O. Persico • Edited

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

Within? I thought that branches were separate entities; I don't think they are nested. You can create other branches based on the current HEAD of develop, but I've never heard the terminology "nested" before.

Collapse
 
maen profile image
Ruheza, NS

They're created as sub-branches of the develop, that's what i meant. Thanks

Collapse
 
matthewpersico profile image
Matthew O. Persico

I hate to be pedantic but you will confuse people with that terminology. There are no such things as "sub" or "nested" branches. They are all "branches", they all have the same properties. There's even a "default" branch (master or main), but it is still a branch. There is no "trunk" in git; it can be modeled by a branch that everyone syncs to, but that's just convention. Under the hood they are all branches. Your three other purpose branches can be described as being "branched from" or "branched off of" devel. But if you wanted to then merge them back to "master", you could, with a little git magic.