Git practices with Git flow and semantic-versioning
Tags: github, devops
Published: 2021-08-24 17:40:24

There are a few things i wish i knew when i started software development and among them are methodologies like git-flow and semantic versioning.

We shall start off with understanding what git-flow and semantic versioning then finish up experiment with git-flow.

###GIT STRUCTURE
Setting up the right git structure earlier will set your project for success
![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qz8plggztl7da1hgcqz7.png)

####OVERVIEW
We create two mandatory branches which are the Master and Development branches that we shall base our temporary branches from. 

**Temporary branches:** 
* *Hot fixes*: This is from the master branch and merged back into master. This branch is used when a fix can’t wait for the next release from development and a fix is urgently needed.

* *Releases*: This is got from development branch and is merged back into development. This branch contains what is staging

* *Features*: This is the same as the releases branch coming from our development branch. This temporary branch is used when creating new features, minor updates and patches.

**Using the above structure we created with semantic versioning**
Semantic versioning is a means of versioning releases in your development environment. This can help you keep track of everything and help reduce the so-called dependency hell during release.

For example: **v1.1.1**(M.M.P standing for MAJOY-MINOR-PATCH). So, 1.2.1 to 3.3.4 would translate to 2 major changes that are not backward compatible, 3 minor changes and 4 patches backward compatible from version 3.0.0. 

**What are major changes?**
Changes made to configuration that are not backward compatible. This will include:
addition of application workflows
* supporting functions to new application workflows
What are minor changes?
modification made to configuration that are backward compatible. This will include:
* modification to features to improve performance
What is a patch?
This includes bug fixes that are backward compatible

###Using our git structure and Semantic versioning together

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dbbu9b9ewlizzy9ldtg8.png)

So we have a work request for the development of a new feature.

1. A temporary **feature branch** is created from development branch that is at v3.6.5
2. Branch under goes changes as feature development is in progress
3. Not just one developer is working on this but it’s a collaboration of more than one developer
5. We finally have branch @v3.9.9 ready for release and testing on our staging instance
6. A temporary **release branch** is created based off development @3.6.5 and is used to introduce changes from the ready feature branch

Okay !!! I guess Ninjas want to start doing this the hard way but we have git-flow to help us with this.

### Let's open up that shell and wrap up this ###
Setting up git-flow. for this case Ubuntu
`apt-get install git-flow`

* **Initializing git-flow** : In your project `git flow init`
You will prompted to input your master, development and temporary branches(support, hotfix, feature). You can rename this branches to suit your branch-naming-convention

note : incase you want to change your master branch to let's say main just run : `git flow init -f`

* **Start feature development** : `git flow feature start feature-x`
If you input `git branch` you will notice feature-x branch has been created
* **Publish a feature** : `git flow feature publish feature-x`. 
The feature is now available on remote, allowing other developers collaborate on to feature-x

incase your development branch is updates to continue working with what's up to date run `git flow feature rebase`
* **Collaborating developers** : `git flow feature pull origin feature-x`
* **Finish up a feature** : `git flow feature finish feature-x`
And that's it, feature-x branch has been merged into development and been deleted. if you input `git branch` you will verify this

Getting features out
`git flow release start feature-x-release`
you can also add <commit-sha> to the end of the above command to 
create a release branch based off of development branch at a certain point in time.
`git flow release finish feature-x-release`
don't forget to use tags

Finally Hotfixes
`git flow hotfix start feature-x-patch`
Again you can add a <commit-sha> at the end of above command to start at a certain point of the master branch.
`git flow hotfix finish feature-x-patch`

Other considerations
* Don't forget to set up branch protection rules for your development and especially `master` branch.
* Assign one or two team members(preferably two) the responsibly of monitoring policies you set around git usage.
* keep looking out there for new standards to improve your current standards

###Conclusion:
Git-flow does make things easier and keeps things sane but am not saying methodology is one shoe-size fits all, You will need to adjust it to your needs. I would also encourage you to look up [Trunk development](https://trunkbaseddevelopment.com/#trunk-based-development-for-smaller-teams) that suits teams trying to get that MVP out there as fast as possible.

Hope this helps, Have fun doing and learning.