1

We are doing a mobile app development and currently, we have Dev - UAT - Staging - Main branches.

We branch from the Main branch as feature/fA for feature development. We do our development in that branch and when it is done, we create a merge request to the Dev branch. We go on with the tests and create a new merge request to the UAT branch if it looks good.

If the feature is approved to go live we create a merge request to Staging. Staging acts as our release candidate branch.

After releasing the application we merge Staging to Main, tag the release and update any ongoing features with Main.

Our problem is when we have multiple features going on at the same time, we face conflicts in our merge requests to Dev, and UAT. While trying to solve these conflicts, we had to pull the code from Dev and UAT to our feature branches, which contain other features. Some of those features might not be going to release so this infects our feature branch.

Limitations:

We can't test each feature independently because we create test packages on a schedule and those packages need to contain multiple release candidate features.

Possible solutions that I found:

  1. Feature toggle
  2. Create an extra branch for each feature in order to merge to env. branches so if there is a conflict solving them won't affect the feature branch. But creates extra work and the way we solve conflicts in each branch and feature must be consistent.

Can you suggest a branching strategy that will minimize the conflict and/or keep our feature branches clean?

6
  • 4
    Branching can't fix a broken release and testing cycle. The real problem is a lack of testing for individual features before merging into your Dev branch. I would focus instead on changing the process used for generating test packages so that your testing is concentrated on features instead, triggering the package process from your Feature branches. Commented Dec 22, 2022 at 8:54
  • 1
    You do not. You practice continuous integration with trunk-based development, where there is single branch to which everyone commits at least once a day, with preference to more frequent integration. If there is feature you do not want to release, you put it behind feature toggle.
    – Euphoric
    Commented Dec 22, 2022 at 9:21
  • 2
    Feature toggles are good. Better if most code gets compiled except for a few lines that actually use the feature.
    – gnasher729
    Commented Dec 22, 2022 at 10:02
  • "we had to pull the code from Dev and UAT to our feature branches, which contain other features. Some of those features might not be going to release so this infects our feature branch." this seems wrong, can you clarify
    – Ewan
    Commented Dec 22, 2022 at 11:58
  • Are you merging the feature branch into dev, and then re-merging the feature branch in UAT? Or are you merging dev into UAT? Commented Dec 22, 2022 at 14:01

1 Answer 1

1

You should use GitFlow.

Instead of Staging and UAT branches, create release branches

If you find an issue when testing a release, branch from the release branch and fix it in a hotfix. Don't try to fix it in the original feature branch.

6
  • +1 Once a feature branch has been merged into an integration branch, the only way is forward. Fix it there. Don't go back to the feature branch. Consider it a dead branch. If you want to retain the history of that branch in version control, use a non fast-forward merge, otherwise a squash merge can keep history cleaner. Commented Dec 22, 2022 at 14:15
  • GIt flow as described on nvie.com doesn't have release branches. Releases are done from master in git flow.
    – bdsl
    Commented Dec 22, 2022 at 14:49
  • who? atlassian.com/git/tutorials/comparing-workflows/…
    – Ewan
    Commented Dec 22, 2022 at 17:59
  • 1
    also, you are wrong : nvie.com/posts/a-successful-git-branching-model
    – Ewan
    Commented Dec 22, 2022 at 19:20
  • It seems like so many answers to git questions on this stackexchange is “use Git Flow”. It seems very subcultural. Commented Jan 25 at 20:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.