0

We have the following remote branches: master staging develop

each are tied to their own server and will deploy when a commit is pushed.

a team member will work on a feature branch myfeaturea which is based off master and merge into develop. In this scenario, the feature was deemed not ready for production.

another team member makes myfeatureb based on master and wants to merge into develop , but cannot because develop contains code that conflicts from the first team member

how can we make sure branches are synced, but also only approved feature branches get to production and not any commits from feature branches that aren't ready / approved?

If feature branches were based off develop and then approved for production, the feature would contain commits from develop that weren't ready for production.

I need a consistent flow and strategy to be able to merge and test different feature branches that are based off master so they are independent from other developer work and automatically ready to be merged into master. but we need to test them too, so we cannot let them conflict on develop either.

So should we somehow remove a commit from develop entirely when deemed not ready?

Improve this question

3 Answers 3

Reset to default
2

This sounds very similar to the workflow discussed in a question on the Software Engineering site, and most of my answer on that question is relevant.

I think the workflow you are looking for cannot exist, because you have two requirements which are fundamentally in conflict:

  1. You want feature branches to be independent, so that any one of them can be merged to master without the others.
  2. You want to be able to test combinations of those features on a single test server.

As soon as you merge two feature branches into develop and test them there, requirement 1 is violated: you have only tested the branches in combination, so you do not know what effect merging just one to master will have. One solution is therefore to abandon that requirement, and treat develop as a true integration test:

  • Merging a feature to develop signals that you expect it to be included in the next release.
  • Problems found in develop must be fixed by merging a fix there. In the worst case, you may have to revert an entire feature and re-apply it later.
  • Normal releases are made by merging the whole of develop into master, at times when all tests on develop have passed.
  • Feature branches are only merged directly to master if they are urgent "hotfixes", which need to "jump the queue". Such branches should be tested in isolation, not by merging to develop.

The other option is to abandon requirement 2, and test feature branches independently:

  • Scrap the develop branch entirely. Testing a version of the code which will never be released is a waste of time.
  • To test a feature, you first update it with all changes currently on master, then deploy it to a test server.
  • If it passes testing, it is immediately merged to master and released.

There are plenty of variations of these workflows which you will find discussed online, but none can give you branches which are both independent and combined at the same time.

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

1 Comment

thank you for this. it has become clear that what you say is true - this workflow cannot exist. there's no way to resolve conflict. it is best that we get rid of develop (which is basically a redundant staging branch anyway). ready features go into staging and staging into master. I will re-read your answer and what you linked. I appreciate it.
1

You're choosing a difficult path. This many separate branches will always be a burden. If you do continue with this approach then yes, you should remove the merge commit from the develop branch.

If I understand it correctly feature branches start from master. Why don't they start from develop? Once approved merge feature into develop. Then merge develop into staging. Then merge staging into master. Any merge on the develop branch that isn't merged into staging yet can be force-pushed out of existence.

Improve this answer

2 Comments

Can you help me understand your last sentence? What do you mean force pushed out of existence? and the reason they don't start off develop is because then they will include commits not ready for production. i agree though, it is burdensome. before we had a develop branch that was in a CI/CD workflow, we did just do develop -> staging -> master flow.
What I meant was: you can reset the develop branch. Removing the last merge. Then git push --force.
1

I want to suggest a more (in my humble opinion) sane strategy:

  • You start with only master and feature-branches (ditch develop)
    • When a feature is ready to be merged, it gets merged to master
    • If a feature is not ready to be merged, it doesn't get merged to anything and stays in its feature branch
  • If you want a branch for staging, as a snapshot of master at that time, create a staging branch when the staging phase begins
Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.