Contribute like a Pro. Git-branching model (Part 2)
Tags: git, agile, opensource, computerscience
Published: 2021-11-28 18:36:30


**Refresh**

From [Part 1](https://maenblog.tech/contribute-like-a-pro) of this article, we discussed about `--no-ff` flag when merging. It helps to keep track of log messages of events happened in your sub-branch (feature branch) and you can easily roll back. Now lets look something else...


## Releasing process


Like the feature branch, it is a separate branch but created as sub-branch of `develop` branch. It is a branch which contains all necessary environment, support and features for production of your application. It's the branch you need only during production process. Two main things can be found in this branch:

- Meta-data(version number - tags, build dates)
- Minor bug fixes



## Create a release branch


When do you create a `release` branch? You should only create a release branch when all targeted features are fully developed and merged back to `develop` branch ready for release. **Divide and Conquer mindset** is very important when dealing with your software. I advise you to build your software in **feature-wise**  that is, you release one feature after another until the entire software is complete. If you're building alone, you **should not** start building another feature before releasing a current feature. Divide and Conquer mindset will save your time and energy too.

For example, say version 0.2 is a current production release (in develop branch) and we have a new release coming up called version 0.3. We will branch off from the current state in develop branch and create a new sub-branch of the develop branch called `release-0.3`. It's name will point to the coming release, shifting from version 0.2 to 0.3, a new release! This is how you'll do:
```
#Create a release branch
$ git checkout -b release-0.3 develop

#Bump the version from 0.2 to 0.3
$ ./bump-version.sh 0.3

#Make a commit
$ git commit -m "Bump v0.2 to v0.3"

```
Note that  `bump-version.sh` is just a custom bash script you'll write to change version of your software (you can also use [git actions](https://docs.github.com/en/actions/learn-github-actions) or CI tools) 

You can fix some minor bugs in this branch rather than doing it on the `develop` branch. But it is not advised to add large new features here.



## Release a release branch


Now the software is ready for production. Our sweet feature in a `release` branch should be merged into the `master`. Remember in [Part 1](https://maenblog.tech/contribute-like-a-pro), `master` branch will always contain "clean codes" with no bugs at this point in time. After merging our branch, we should `tag` it, just to mark the branch with a summary of what we've done for the future reference. And finally, updating the develop branch. In summary:

- Merge the release branch into master branch.
- Tagging the branch for future reference.
- Update `develop` branch with clean codes so that the future development also contain the bug fixes.

```
#Into master branch
$ git checkout master

#Merge the release into master 
$ git merge --no-ff release-0.3

#Tag it
$ git tag -a 0.3

#Into develop branch
$ git checkout develop

$ git merge --no-ff release-0.3

```


## What about hotfix branch?

As the name suggests, this is the branch which you'll create for the purpose of fixing bugs that maybe found (or arise) in a `master` branch. But we said, master branch must contain "clean codes" right? So why bugs in a master branch?  Well, the answer is - software becomes real when reach to a user. That's when you realize the bugs - Uncaught fish :) Here's the snippet:
```
#Create a hotfix branch 
$ git checkout -b hotfix-0.3 master

#Fix the bugs and commit
$ ./hotfix-version.sh 0.3
$ git commit -m "Fixed bugs in production"

#Update the master branch
$ git checkout master
$ git merge --no-ff hotfix-0.3

```

You can also update the `develop` branch with this fix just to contain the same clean codebase. After the fix, it's your choice to delete the branch or leave it for your reference. Up to this point, your codebase should be stunning with **zero conflict !**

Congratulations, you're Git ninja now!

Written from [here](https://maenblog.tech)