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!
Originally, posted here
Top comments (5)
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.
They're created as sub-branches of the develop, that's what i meant. Thanks
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.
Good post, I'm eagerly awaiting the continuation
Thanks, will be released soon.