Git Workflow

There are several workflows that developers can adhere to in order to get organized. Over the next few blog posts, I will introduce you to a feature by source tree that will help you adhere to the git workflow which is in my opinion the best one; especially when Source tree helps you and your team adhere to it.

The image below illustrates an example of a git workflow. In this post I will elaborate on some of the reasons why you should adhere to such a standard. The next few posts I will illustrate the easiest and most effective way for you and your team to adhere to the work flow.
git-workflow-release-cycle-4maintenance

 

Starting from master all the way to feature branch, the stability of your code should be very stable at the master level all the way to least stable at the feature level.

1- Master is your most stable branch and it is usually the live version of your code. Any commits to your master branch must also include a version tag number.

2- Hotfix branch is branched of the master as this is a critical bug that needs to be fixed asap. When the bug is fixed it must be merged into the master branch but also into the development branch, that is in-order for your developers to have the code fixed on their development branch.

3- Develop branch is the branch used to integrate all your development work onto. All feature branches are integrate into the develop branch. Develop branch is branched of the master branch at the start of the project.

4- All Feature branches are branched of the develop branch, as soon as developers test their feature branch, they can integrate it into the develop branch for further integration testing.

5- When a release cycle if reached, a Release branch is created and named after the code’s version number. Release branches would be good to push to beta testers before code is pushed into the master branch.

6- Should any bugs be identified on the release branch, a bug fix should be committed on the release branch. When code is stable enough and ready to be pushed into master, the release branch must be merged into the master and develop branch. The reason why it must be merged with the develop branch as common practice, is that if any bugs were fixed on the release branch, merging the branch into the develop will fix those bugs on the develop branch too. This way your development team will have the most up to date and stable code.

In the next few posts I will elaborate on how you can easily follow this process without having to for example manually merge the release branch into the master and develop each time.

Michael Ghattas

Tech guy deeply interested in startups, growth, AI and just anything exciting. Currently involved with MTL New Tech and Wavo.me. Love travelling and exploring new cultures. In my spare time I like to read, write, code, and just hang out with friends. I actively trade the stock market and will be talking about my trades in the blog.

GIT