Let’s get start this is not a standard Gitflow where you can find it inside the documentation. We kind of adjust it a little bit here and there to match our client’s criteria. The reason that why we mostly use Gitflow is because our client mostly are B2B. Where from architecture side better to start with a monolithic architecture. Different with Microservice Architecture, where it will be more match to use trunk-based development flow. We mainly have 3 different main environments.

Development Environment

First is development environment where when we build the feature. We upload it into development environment and QA will help us to test the feature. This environment, pretty much only for internal development team to test and verify a feature. Once it’s been verified, we will move the feature into staging environment.

Staging Environment

Staging environment is for like partners or maybe our business person to check some specific feature based on what we determine on this requirement.

This is kind of pre-production stage, where we would schedule it to go to production within 1 or 2 days and of course. The production is where our users or our clients can access and use our platform. In order to start working on specific feature, you require to create a feature branch. And the way that we create feature branch is from production branch.

The reason why we go with production branch because we try to start everything from the cleanest feature branch as possible. And that’s production because it’s basically what our users or our customers using right now. We don’t want to go with dev because dev has a lot of bugs to fix. Since, this is for internal development team only. The reason why we don’t go with staging because a couple of features that not been release yet to production is there. So, just to keep everything as clean as possible we start from production branch. When you done working with the specific feature you push your code inside that feature branch.

Pull Request Or Merge Request

It’s now time to create a pull request or merge request based on whatever platform you use to the dev branch, so our internal tester can test your feature. So, you have to create a merge request or a pull request. When you create a merged request or pull request there’s a possibility that it will raise a conflict. So, when it does raise a conflict, the way that we manage that we need to keep this feature branch as clean as possible and as close as possible to our production branch. At the end we want to release this feature inside the production.

When a conflict raised, we tend to create another branch from this feature branch. We named that as whatever the environment as, in this specific example is dev_conflict follow with whatever your branch name. So, when we create this new branch, we have to solve the conflict manually inside our local with the dev branch. Once the conflict is resolve, we close this PR, and we make another PR to dev using this new branch.

So, this way, this is the branch that will get dirty because we try to resolve conflict with dev only on this branch. But this original feature branch will keep as clean as possible. So, we can move a long when we need to merge it to staging or production. In this specific phase, I often get question. Let’s say, I merge my dev conflict branch and it’s merged to dev environment. Then our QA start testing and there’s some bugs found on dev.

So when I need to do some bug fix what should I do?
Should I push to this branch or should I push to this branch?

The answer is, you should push to the original feature branch. Once you have your fixed here, you don’t need to sync it with our dev conflict branch. Because your original commit from here already on dev. When you raised a new merge request to dev, it wont get any conflict because commit idea from your feature branch previously already on this. So, they only will check your new commit idea which is the bug fix.

So once you fix, you don’t need to sync it with our dev conflict branch because your original commit from here is already in dev. When you submit a new merge request to the devs. It won’t create a conflict because the commit idea from your previous feature branch is already here. So, they’ll just check your new commit idea which is a bug fix to dev so this is will be the new MR/PR to dev and I got conflict.

create the new dev conflict branch, and on some specific part of my code that conflict. It was change from the other developer, so at this point, what should I do? As long as you know who works on that and what feature branch that code from. You always need to mark, let’s say this is from feature A. You need to mark these 2 branches is dependent to each other. Means that this feature branch need to go away first or need to go to other environment first before working feature.

We not sure about GitHub but with GitLab we usualy use GitLab. We could mark this feature as “dependent to feature A”. So, this way we can keep tracking if there’s a dependent feature or dependent branch when the specific branch want to move to other environment. Let’s say your work is verified by QA on dev environment, and QA person marked this specific feature to be pushed to staging environment. This is kind of pretty much the same thing that you have to do. You have to create PR or MR to staging environment, the same thing if you get conflict. Let’s say you have conflict you got to create staging conflict and whatever the branch name is. Now we know that we need to destroy this PR, because we have conflict we need to create another PR or MR for staging.

This is pretty much the same if you have dependent branch. We need to make sure that our dependent branch or way the merged to the some specific environment first. Then you can create your MR That’s pretty much the same thing. And of course, the same thing when you want to release your feature to production. There will be no conflict raised when you create MR/PR to production because, you know our feature branch is based on production branch, and should go as long as possible.

how do we manage Hotfix inside our Gitflow development? So, Hotfix is a little bit different when it comes to manage it inside our GitFlow. With normal feature development, normally you will merge it first to dev. When it’s verified by QA, you move it to staging, and so on to production. But, with Hotfix, there are 2 categories that we could do with Hotfix.

• First is what we call an urgent bug. It’smeans that this specific bug need to be fixed immediately to production as soon as possible.

• Second is easy fix. So, easy fix that we found a bug on production and it’s easy to fix that, then we also include that inside hotfix. So, with hotfix, pretty much the same with feature we create that branch from production. But the difference is once we upload our change to hotfix branch. We create MR/PR into staging, so we don’t go to this first because this requires a lot of work since it contains a lot of unverified work from development verified by QA.
  

Since this is urgent or need to be to production ASAP. We upload that to staging create MR or PR, then QA person will verify on staging environment. Once it’s all good, then we move it to production. We create another MR or PR, So, pretty much that’s how you manage Hotfix inside our GitfLow development style. That’s pretty much explain how do we use GitFlow inside our project development. If you guys have any questions, please write it inside the comment. We will try to replay that as soon as possible, or if you guys also using a GitFlow or maybe any other flow like Tranbase. You can write it in the comment and why do you choose that. check others article in here.