0

My company have this kind of rules:

  1. Feature branch is created from master branch
  2. Once feature branch completed, we make a PR to develop branch
  3. Once PR approved, merge to develop
  4. After QA testing, feature branch will be merged back to master

This flow created lots of unnecessary merge-conflict when trying make a PR (although if PR with master there is no issue), how can we improve the situation?

Edit: It seems likely my company use trunk based development and use develop branch only for testing ground for new feature (sometimes feature are developed with several branch by different developer)

Improve this question
1
  • 2
    #1 shouldn't create any conflict! Commented Mar 5, 2020 at 12:00

3 Answers 3

Reset to default
1

We follow the following steps in our company. This might be helpful:

  1. Create a feature branch from the master
  2. Complete the work in the feature branch
  3. Merge master branch to the feature branch, resolve all the conflicts. To minimize the conflicts you can merge master to your branch at once a day.
  4. After resolving the conflicts check if everything work. Then push it to your branch's remote.
  5. Then checkout to master.
  6. Merge everything from feature branch to master. As we already merged everything from feature branch to master branch, merging feature to master shouldn't raise any conflict.

This way the master branch will always be clean. Conflicts would be resolved in the feature branches. Also if you want to pull request to master, first merge the latest contents of master branch to your feature branch.

In summery, to minimize the conflicts keep your feature branch up to date with your master branch as frequently as possible. And solve all your conflicts in feature branch to keep master clean.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

How you do qa/testing? do you use master? and what if bug happen?
no we have a dev branch too, we use master only when the testing is done! so the master only contains the release versions.
So do you make a PR from feature to dev?
0

You can improve this situation in this way:

  • Feature branch should be created from Develop branch
  • After Merging any PR in develop branch, everyone should rebase their develop branch locally and respective feature branches as well.
  • By following the above two steps, Master is only changed after QA Testing and develop is merged into the master branch.

Let me know if I have to explain any further.

.

Improve this answer

8 Comments

Point #1 not applicable, as the one that made that decision is my lead
on what basis, s/he decided to go with that?
I'm still new to the company, but I think he decided that each feature should be based on the stable code (already passed QA)
is master your production branch?
apparently it use trunk based development with short lived feature branch and long lived master branch, PR to develop only used for testing with several feature branches that related for feature delivery
|
0

The biggest portion of git's code is conflict resolution. The smaller your commits and the commits of your colleagues are the better the chance that git can resolve a conflict automatically. Very large commits are mostly the cause of conflicts.

The workflow looks good to me and shouldn't be the root cause of your constant conflicts. Even if I agree that feature branches should be branched from develop.

Improve this answer

1 Comment

It's due to lag in QA dept that lots of commit in develop don't go to master quickly as we wanted so newer feature branch can potentially based off on old code from master instead of newer in develop

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.