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
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
So we have a work request for the development of a new feature.
- A temporary feature branch is created from development branch that is at v3.6.5
- Branch under goes changes as feature development is in progress
- Not just one developer is working on this but it’s a collaboration of more than one developer
- We finally have branch @v3.9.9 ready for release and testing on our staging instance
- 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 inputgit 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 inputgit branch
you will verify this
Getting features out
git flow release start feature-x-release
you can also add 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 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 that suits teams trying to get that MVP out there as fast as possible.
Hope this helps, Have fun doing and learning.
Top comments (0)