1

I don't know if I am over-complicating stuffs but here is our setup.

  • 3 Code hosting servers (QA, Stage, and Production)
  • 3 main git Branches (dev, stage and master) for respective servers
  • 10-15 developers working on git sometimes working on same file concurrently.
  • Developers are only allowed to merge and push to dev, Maintainers handle the code releases to stage and production.
  • any issues are done in their own branch checked-out from master branch (sometimes from connected branch).
  • each branches are merged individually to the main branches.
  • issues or task has varied release dates so master is not always up to date. Sometimes one issue from dev can take months to go to master/production.

Currently we are facing quite a bit of code conflict issues on dev, which is also wasting lot of our time. Also the code history or graph as of now is starting to look like spider web.

Previously what we had was a linear setup where every one would commit to dev, then maintainers would cherry-pick the commits to stage or prod. That setup was easier for developers but nightmare for maintainers.

If any one has experience with this kind of setup, please advise on how did you made your work easier? I know communication is the key here, but without a dedicated person I find it really challenging right now.

| improve this question | |
  • aren't feature branch same as a common branch which multiple devs use? – Ruchan Sep 5 '18 at 9:08
  • 3
    @Ruchan It sounds like you have some organisational problems, namely work not being prioritised correctly, and the rest of your development process is being contorted to work around this. Fix the root causes and the rest might fall into place. – Frayt Sep 5 '18 at 9:45
  • 3
    That’s why you use feature flags. Developers can merge their code to master and maintainers turn the feature on via configuration when it’s ready to go live.You need to separate the concepts of merging code and releasing a feature. – RubberDuck Sep 5 '18 at 9:45
  • 3
    @Ruchan more complex than dealing with merge conflicts and cherry-picking commits? Just food for thought. – RubberDuck Sep 5 '18 at 10:27
  • 2
    Thank you guys for the help and suggestions, I will take these things into consideration and make change as necessary. – Ruchan Sep 6 '18 at 7:17
2

I'm not totally clear on what your process is. But!

If you use feature and hotfix branches correctly you should only get merge conflicts when you actually have a conflict.

Developers branch from develop -> feature123 and build a feature, commiting the feature123 as they go.

When they are finished they merge from develop -> feature123 again to pick up any changes that have happened in develop form other features or hotfixes while they have been working.

Here, if someone has changed the same code as you, you will get a merge conflict. You will have to decide how your feature should work with the changed code.

Once the developer resolves the conflict they can merge feature123 -> develop

Once all the features for a release are finished you can merge form develop -> master

Maintainers branch from master -> hotfix123 and make changes in hotfix123. Once they are complete they merge hotfix123 into both master AND develop

Here they can get conflicts from other hotfixes which change the same code (hopefully rare) and from new features added by developers.

This will be the most difficult merge as the Maintainer and Developer are in different teams and will need to cooperate on the merge.

| improve this answer | |
  • this method is goto method for sprint releases, where all changes in a sprint are released at once. For my case, as mentioned, we do selective release of features. All things in dev are not necessarily production ready. – Ruchan Sep 5 '18 at 11:21
  • hmm you might want to make that clearer in the question. also, dont merge to dev unless the feature is complete – Ewan Sep 5 '18 at 11:39
0

The developers should regularily merge master in, last time when done with the feature, and only merge back to master when their work is correctly integrated. This ensures that master is always usable by others.

This is important to ensure they work against the latest released code. It is in their own interest, so they should pick it up quickly. It is much easier to do incremental merge fixes than waterfall merges.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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