Git Flow lessons for project development.

It’s really important to understand git flow and how it works to develop your application when collaborating on version control like git.

Hello everyone, after learning about what is git and how they works here. Today I want to give a lessons for you who are collaborating on git and needed to know what and how git flow works. Git flow is a way to act and work on your repository, it is like a pattern that must be followed. The main purpose using Git Flow is to maintain production application in the best state also this flow can control and track any works that are on going. Here is the lessons from my own experience and I hope it will help you to prepare your development with scrum methodology.

Preparation

First of all, create the master branch this is the production branch that only able to be merged when a work really done(passing the testing, code review, and accepted by product owner). Master branch can not be edited by any of developer member except scrum master of the team. This rule will maintain the master branch not polluted by any bad hands of developer :).

Second one is staging branch, staging branch should be the development branch that deployed a ready to test application. This branch is able to edit by any of developer member but of course there should be a rule to maintain this branch in a good condition that will not be a bug can grow :).

Then after the preparation step you should be curious about how developer be able to code their works, right? To answer this question you should understand what rule is applied to staging branch first. The rule is as below
1. Developer is not allowed to code in staging branch
2. Staging branch is branch that contain and collect all the user story branch(will be explained in next section) that should be merged to staging
3. Every time user story branch want to merged to staging this should request a merge request and pass the code review process.
4. Every merge request should request minimal 2 person of developer member(if the developer team is small as mine) to approve the merge request.

Now, you are ready to be the developer member. Remember my advice, to be a good developer you should follow the rule and guide so you will not break the flow in your team. Developer member able to complete any task that they want to take(agile development based). How to complete the task? yeah you should have your own user story branch.

Completing Task from One Product Backlog Item

In scrum there are PBI and in each PBI can be contain some of user story that should be completed in one sprint. Then, in the sprint review every PBI that completed will be reviewed by the product owner and can be rejected or accepted. Every user story in PBI can contain one or more task. Hold on what you want to learn is how to completing task, okay the explanation above is a little thing that you should know what is ‘task’ and ‘user story’ in scrum.

User Story Branch

That’s right to complete one task first of all you should create a user story branch. User story branch naming should be good to keep it tracked. User story branch naming should follow this rule

US-<the user story number>-<name of the story>

example

US-1-landingpage

Then, if in one user story only contain one ‘task’ you can start code on the branch, but, if you have some task for one user story you should create a new branch I recommend this method because in my team, user story is treat as task, so there is too many US branch. Then for the task branch rule is simple

T-US-<the user story number>-sub-<task name>

example

T-US-1-sub-membuatstaticlandingpage

This method maintain the flow of the branch. Also you and your friend can share task in one user story with no problem in the process of working. Then, after knowing about the branch structuring you should be curious ‘how the hell I should start code and what rule in it????’. Next section will be talk about rule of commit(part of the coding for developer), review and approving.

Commit Once and you should not regret it

Complete your code in local repository and you want to commit it to your remote repository. There is some rule for committing your change.

1. Commit message prefix, There are 4 main message prefix you should use. They are [CHORES], [RED], [GREEN], [REFACTOR]. Use [CHORES] when your change is about dependencies, main settings about your apps, and other things that you add which ‘must be’ in you apps. Use [RED] when your change is failing the pipeline but the change is must be in there as example a unit test when you are using TDD methodology this [RED] case usually happen. Use [GREEN] when your commit is not failing the pipeline and also the change is not categorized to refactor or chores, usually you will use the [GREEN] prefix to your change that implement any feature that already tested. Use [REFACTOR] when you changing inside implementation without change the code behavior, usually you will use it when you want to optimize the code and any other case. [RED]-[GREEN]-[REFACTOR] Basically you will use this flow when implementing you code using TDD methodology you can see the explanation here.
2. Commit Message, commit message should not be a random word or sentence that not explain anything, like ‘good implement’, ‘complete code’, ‘best thing’ or any other words. You should mention your main change in your commit message. This allow you to remember what you do on that commit, also make others can understand your developing flow because there will be code review for your merge request.

For example about this committing rule here is example of my works

Example of commit message

Then after you complete your code, of course you should combine you working to your head branch. Combining your work is not easy as you think there are some rule you should follow too, because you don’t want to ruins all the branch and other developer’s work right?

Integrate Branch

After I experienced some of the integrating method and read the explanation here I choose and suggest you to use ‘merge’ than ‘rebase’ but you can thinking about it by exploring more. So before you merge your works you need some rules of course, this will mange your teamwork flow.

1. Pull before Merge, this will be needed because you will not be able to merge before the head of your destination branch is updated in your branch. Also it is not possible to ask everyone in your developer team is there any update on X branch. So before you create merge request you should pull the update on your destination branch.
2. Don’t ever Merge failed commits, even if you want to present your works to your PO because failed commits means your work is not fully completed. Merging failed commits also will drive to some bug if you forgot to resolve it. So I highly recommend you to push only a branch that is fully completed done.
3. Don’t ever forgot the approval number, minimal you need 2 approval because sometimes you as developer forgot some little thing and your approval may notice it in the code review. You should help other member merging too, you have to do code review on other member works.
4. Choose the right target branch, it’s important to choose the right target. Integrate task branch only to the right user story, and integrate user story only to staging branch. Master branch merge from staging only if the PBI is already accepted by PO without any fixing.

Now, after knowing the rule above you are ready to merge any branch in your repository. Wait, there are something you should know about branching after merge. There are special case that maybe occur after sprint review or after task merged but not really needed in the staging or there are some bug get away from testing.

Special Case

What is this special case is a fixing method to some bug or rejected works. You should create new branch to fix the problem.

1. ColdFix branch, this branch can you use when staging already merged but on the sprint review your work is not accepted by PO. You have to rollback all change from that user story. This may be happened to all user story that wanted to be released but rejected by PO.
2. HotFix branch, this branch can you use when there are bug on master branch. Fix the bug in hotfix branch then after the bug is fixed you can merge to master branch again.

Then all the lessons for Git Flow is finished. I have shared all my experience and dedication in this lessons. Hopefully you can learn from this written explanation. Oh of course don’t forget to be discipline, because it’s needed more attention to pay if you want to keep your work as tidy as possible.

Hopefully my experience will be a lessons for you