Its essential to prepare a git branching strategy. This helps greatly in preparing a build management plan and deployment plans. You can also make a plan to test your new features, bug fixes and deploy it.
Generally, we have one Production environment which is being live for end users, and there are one or more environments called Staging, QA, Dev environment. For a clear and smooth management of source code, lets see how we can manage our code so that it does not create chaos.
This article talks about Git, source code management and version history solution.
Work Environments
I assume we are having one production environment and one stage (or QA or dev) environment. Production environment is for builds which is live and users are using it. Other environment where you deploy builds for QA team to test and certify changes that are going to be live on production.
Git Branches - Branching Strategy
1. Master Branch - Live on Production
There is one Master branch which is present in git by default. Master branch will reflect always code that is live on production. In simple terms, Master branch code is equal to production. Do not try to commit any code in this branch which is not tested, or is under development.
If you keep on commit your new feature work on Master branch, and if suddenly a bug came which needs urgent fix. How would you bring the state which is live on production. You may end up putting untested code on production along with your bug fix.
2. Stage( or QA or Dev) Branch - New Feature Development branch
This branch is the home for all new development work. If your sub-team is working on a new feature and is developing code for that, this branch will have code for those development features. But note that, this branch too should not have any untested code or incomplete code. This branch will have new development code for a feature that is complete or with minor bug fixes.
Now, the question arises where do we do the development work?
Where should we do new development work? Feature Branch
For every new feature you want to work, Fork a new branch from Stage branch. You can name this branch as Feature-XYZ etc. And, you can commit any incomplete or intermediate code there. You can test, do bug fixes complete feature from this branch. These branches usually have a limited life, and are deleted when the work is done.
3. Hot Fix, or Urgent Bug fixes for Production
There might be a situation where there is blocker bug came in production environment and you need to urgently fix it. Fork a new branch from Master branch, and name it something like: HotFix-XYZ or BugFix-ABC. Test it in that branch only, and merge it back to Master only when fully tested. These branches usually have a limited life, and are deleted when the work is done.
Code Merge Points
1. When should we merge code back to Stage branch
When we are certain that our feature is completely developed and is tested by developer, they can create a pull request for this branch. And, merge it in Stage branch, delete that branch. So, stage branch will have all development changes. You can prepare a build from stage branch and deploy in your staging environment where QE will certify this build.
2. When should we merge code to Master branch
As I said before that Master reflects production. So, when you are ready to deploy all new changes to production, you should create a pull request for stage branch. Merge it to Master. Do not delete stage branch.
3. Merge code from HotFix branch to Master branch
When we have tested code from HotFix branch, and is ready to deploy. This branch will merge into Master branch. Note: For every merge from HotFix branch to Master, we need to keep Stage branch in sync with Master.
Code or Build Releases
Every commit in Master is a new Production build or a new release. We should tag master branch for every such release. And, give it a name like 1.0.0, 1.1.1 etc. Tagging helps in identifying what code went live for which version of build. It can help in rollback to a certain point, if required.
Standard for Git Projects
Note, we should have our project per repository. And, do not treat a repository like a directory which can have multiple projects.
Standard for Jenkin Jobs for Builds
For these standards, we can have 3 jobs for every repository.
1. For Master Branch
This should prepare builds from master branch, and post builds into some artifactory with Master tag.
2. For Stage Branch
This prepare builds from stage branch, and post builds to artifactory with Stage tag.
3. For Feature or HotFix Branch
This job is parameterized to take branch name as parameter. This helps us in creating builds from our feature branch or hotfix branches which are not persistent.
Note: Tags is necessary in Jenkin jobs which helps in posting builds with different name in artifactory.
How to merge code - Code Merge Options
When you are about to merge code from some branch to a branch, there are three options are given:
- Merge and Commit
This option brings all commit history from source branch to destination branch. If the source branch has 50 commits, then all those 50 commits will come in destination branch. With this option, you will not loose commit history.
- Squash and Commit
This option combine all commits from source branch into one, and combine all those commit into one. With this, we loose commit history from source branch.
- Rebase and Commit
Forget about this option for now.
When should we use “Merge and Commit” and when “Squash and Commit”
When we commit Feature branch to Stage branch, we can use “Merge and Commit”, as we may use the commit history. But, while merging into Master branch, we can use “Squash and Commit”, as whey would I want to see any dirty commit or incomplete commit in master branch. I would just want to see complete feature commit as one. This serves my purpose.
Note: Above interpretation may change case to case.
Putting Restrictions on Branch/Code Merge
In git, you can force some standards or security like:
- Only certain people can merge code in certain branch.
Example: Only Gorav can merge code into Master branch.
- You can put restriction that before code merge, it has to be reviewed with ‘N’ number of people.
Example: At least 2 reviews are required before merge
Summary of Rules that I follow
- Have a Master (for production) and Stage branch (for Stage/QA/Dev environment)
- For every new feature development, fork a branch from Stage
- Upon completion of feature (testing done), merge back to Stage (Merge and Commit), and delete feature branch
- When the code is ready to deploy, merge it to Master. Dont delete stage branch
- Tag the master branch with release number
- Stage branch must be
- reviewed by at least 1 person
- Only certain person can merge code in stage
- Master branch must be
- reviewed by at least 2 persons
- Only certain people can merge the code
Have a look on How to enforce strict policies on git branch
