Basic Git branching workflow - AsyncAuto
Basic Git branching workflow
August 30, 2019 byalex
Permitted branches:
master anything that goes to production goes via this
develop – contains code for whatever there is in master + new feature pending release into master
feature/<feature_name>: for a new feature that you are working on. You will create this branch from develop.
hotfix/<bug_name>: There is a bug in production. You will create the branch from the master.
If your production system is facing a breaking issue. There is a 500 error. The customer is not able to make payment. The customer is not able to place an order. The hotfix is called hotfix because you are making small quick changes in the production environment. One needs to pay attention to what constitutes a hotfix:
It should be very a critical issue
some very critical error
It should be something that can be fixed in a short duration of time
the fix should be solved in minutes(max a few hours).
It should be a small change
Most errors are some silly mistakes that require a character change or line change. At max, a few lines change.
When creating a hotfix, create your local branch from master.
Any other change other than a hotfix is considered a feature. A feature can consist of:
addressing new corner cases
When creating a feature branch, create your local branch from develop.
I am done with a feature development in feature/<feature_name>. What shall I do now?
Once you are done with the feature testing you need to merge the branch with develop.
The problem with merging with develop branch is that the code in develop is supposed to contain code that is supposed to go into master soon.
So you should merge code to develop when you are sure that your feature is ready to go to production.
If not, complete your work and park the feature for a while.
If your feature has a specific release date, do all the necessary testing in the feature branch itself and try and not block the production pipeline by merging too early. After testing merge into develop closer to release date.
follow the merge request checklist for the feature branch
I have merged my feature branch into develop, but i encountered a bug while testing in develop?
If the code is not in production yet, you don’t need to create a new branch to fix the bug in develop. Solve the bug in develop itself.
Can I create multiple feature branches?
Yes. If you are working on a feature that got de-prioritized and wants to work on a new feature, you can park the feature and create a new feature/<feature_name> branch from develop branch.
Creating a new branch checklist:
name it properly –
feature/<feature_name> for a feature branch
hotfix/<bug_name> for hotfix
make sure your local develop and master branches are up to date. Run git pull on both these branches. Remember, others are contributing code too.
Create a branch from the right branch
from develop for feature branch
from master for master branch
Merge checklist – feature/<feature_name> branch:
pull the code from a remote develop branch into your local feature/<feature_name> branch.
While you were working on your feature in the silo, someone else could have an updated feature branch. Your merge is accepted faster if you resolve any merge conflicts arising from race conditions.
push code to the remote server
Create a merge request on a feature branch on Gitlab/Github via the UI.
Merge checklist – hotfix/<bug_name> branch:
pull the code from a remote master branch into your local hotfix/<bug_name> branch
While you were working on your feature in the silo, someone else could have an updated master branch. Your merge is accepted faster if you resolve any merge conflicts arising from race conditions.
push code to a remote server
Create a merge request to master and develop branch on Gitlab/Github via the UI
You can avoid making mistakes in remembering the details. Install git-flow to take care of these cases. 👉https://github.com/nvie/gitflow.
We use a subset of git flow branching strategy. For details 👉https://nvie.com/posts/a-successful-git-branching-model/
Adding something to the bottom of every post in Wordpress
What does it take to build good software?
One response to “Basic Git branching workflow”
This document needs to be updated-
Hotfix is an exception to the regular dev cycle. When you release code as feature or bug, it goes through the regular dev process where testing is done in the testing environment and then release happens to production.
Hotfixes are critical mistakes on production that should be fixed immediately. It cant wait for the typical dev process to finish. Hotfix is an exception.
Basic Git branching workflow - AsyncAuto
Basic Git branching workflow
August 30, 2019 byalex
Permitted branches:
master anything that goes to production goes via this
develop – contains code for whatever there is in master + new feature pending release into master
feature/<feature_name>: for a new feature that you are working on. You will create this branch from develop.
hotfix/<bug_name>: There is a bug in production. You will create the branch from the master.
If your production system is facing a breaking issue. There is a 500 error. The customer is not able to make payment. The customer is not able to place an order. The hotfix is called hotfix because you are making small quick changes in the production environment. One needs to pay attention to what constitutes a hotfix:
It should be very a critical issue
some very critical error
It should be something that can be fixed in a short duration of time
the fix should be solved in minutes(max a few hours).
It should be a small change
Most errors are some silly mistakes that require a character change or line change. At max, a few lines change.
When creating a hotfix, create your local branch from master.
Any other change other than a hotfix is considered a feature. A feature can consist of:
addressing new corner cases
When creating a feature branch, create your local branch from develop.
I am done with a feature development in feature/<feature_name>. What shall I do now?
Once you are done with the feature testing you need to merge the branch with develop.
The problem with merging with develop branch is that the code in develop is supposed to contain code that is supposed to go into master soon.
So you should merge code to develop when you are sure that your feature is ready to go to production.
If not, complete your work and park the feature for a while.
If your feature has a specific release date, do all the necessary testing in the feature branch itself and try and not block the production pipeline by merging too early. After testing merge into develop closer to release date.
follow the merge request checklist for the feature branch
I have merged my feature branch into develop, but i encountered a bug while testing in develop?
If the code is not in production yet, you don’t need to create a new branch to fix the bug in develop
. Solve the bug in develop itself.
Can I create multiple feature branches?
Yes. If you are working on a feature that got de-prioritized and wants to work on a new feature, you can park the feature and create a new feature/<feature_name> branch from develop branch.
Creating a new branch checklist:
name it properly –
feature/<feature_name> for a feature branch
hotfix/<bug_name> for hotfix
make sure your local develop and master branches are up to date. Run git pull on both these branches. Remember, others are contributing code too.
Create a branch from the right branch
from develop for feature branch
from master for master branch
Merge checklist – feature/<feature_name> branch:
pull the code from a remote develop branch into your local feature/<feature_name> branch.
While you were working on your feature in the silo, someone else could have an updated feature branch. Your merge is accepted faster if you resolve any merge conflicts arising from race conditions.
push code to the remote server
Create a merge request on a feature branch on Gitlab/Github via the UI.
Merge checklist – hotfix/<bug_name> branch:
pull the code from a remote master branch into your local hotfix/<bug_name> branch
While you were working on your feature in the silo, someone else could have an updated master branch. Your merge is accepted faster if you resolve any merge conflicts arising from race conditions.
push code to a remote server
Create a merge request to master and develop branch on Gitlab/Github via the UI
You can avoid making mistakes in remembering the details. Install git-flow to take care of these cases. 👉https://github.com/nvie/gitflow.
We use a subset of git flow branching strategy. For details 👉https://nvie.com/posts/a-successful-git-branching-model/
Adding something to the bottom of every post in Wordpress
What does it take to build good software?
One response to “Basic Git branching workflow”
This document needs to be updated-
Hotfix is an exception to the regular dev cycle. When you release code as feature or bug, it goes through the regular dev process where testing is done in the testing environment and then release happens to production.
Hotfixes are critical mistakes on production that should be fixed immediately. It cant wait for the typical dev process to finish. Hotfix is an exception.