In my development, I use Git all the time. As it turns out as many as 90% of all small engineering teams use Git as well. And I know that in the beginning it can be a little overwhelming balancing between setting up processes and standards and putting out new features in a swift manner and focus on expanding your project.
So, in my experience, these are the best practices for setting up a Git structure when you are working in a small team (I would define small as less than 8 people).
Separate Your Branches into Two Groups
Separate your branches into two groups - main branches and supporting branches. I should mention ahead - there is no difference in these branches from a technical perspective. The difference is only in how they are used. In reality, they are just plain old Git branches.
Main Branches
Master:
The origin/master branch represents the main branch of your application. The source code of HEAD is always in a production-ready state.
Develop:
The origin/develop branch is a branch that is parallel to the master branch. It stores the latest ready-for-release development changes. The source code of HEAD reflects the changes for the next release.
Supporting Branches
Feature:
Feature branches are used to develop a feature for a future release. This branch exists as long as the feature is being developed, but eventually, it ends up being merged in the develop branch.
- May branch off from: develop
- May be merged into: develop
- Branch naming convention: feature/name-of-feature (e.g feature/login)
Steps for Creating a Feature Branch
$ git checkout develop
- Switched to branch develop
$ git pull origin develop
- (get all up to date changes from develop)
$ git checkout -b feature/feature-name- Switched to new branch ‘feature/feature-name’
After it’s done it’s merged into the develop branch
(on branch develop)$ git merge feature/name-of-feature
Hotfix:
Hotfix branches are used for when a critical bug is found in production and a fix is needed immediately. When a critical bug in production arises a hotfix branch is created so that the problem is resolved within the appropriate time frame.
- - May branch off from: master
- - May be merged into: master or develop
- - Branch naming convention: hotfix/description-of-fix (e.g hotfix/login-fix)
Steps for Creating a Hotfix Branch
$ git checkout master- Switched to branch master
$ git pull origin master- (get all up to date changes from master)
$ git checkout -b hotfix/description-of-fix- Switched to new branch hotfix/description-of-fix
After it’s done it’s merged into the master branch
(on branch master)$ git merge hotfix/description-of-fix
Bugfix:
Bugfix branches are used for when a bug is found that has not been deployed on production yet. Probably found during the QA process, a bug that is not of critical importance is found and for the purposes of solving it a bugfix branch is created.
- - May branch off from: develop
- - May be merged into: develop
- - Branch naming convention: bugfix/description-of-bug (e.g bugfix/admin-login-bug)
Steps for Creating a Bugfix Branch
$ git checkout develop- Switched to branch develop
$ git pull origin develop- (get all up to date changes from develop)
$ git checkout -b bugfix/description-of-bug- Switched to new branch bugfix/description-of-bug
After it’s done it’s merged into the develop branch
(on branch develop)$ git merge bugfix/description-of-bug
Final Word
While I know that there are a million different ways to use Git, that every team is different and there is nothing really groundbreaking in this strategy, it has proven tremendously useful in my projects. It forms a model that is easy to follow and implement and allows developers to easily remedy any mistakes that may occur.
And if you ever have any issues, always remember:
