0

We have 3 branches development, staging and production. On development we develop our application and it is deployed on dev server, where rest of our department can test it. When it is ok for them, then it is merged into branch staging, which is deployed on testing server, where our customer can test it and they can develop their testing API client connected to it. When it is ok for our customer, then it is merged into branch production, which is deployed on production server, where our application actually runs.

My questions are: What to do, when commits B and C are in branch development, and for some reason commit B must be merged into branch staging earlier than commit C. For now we are doing interactive rebase, which cause us problems with local copies and I don't think it is right approach. Should we use cherry-pick, or anything else?

And second follow-up question, is it ok, when these three branches are different (in commits or order of commits)? I am affraid of chaotic log graph and merging with a lot of differences. For now they are absolutely same, but it is causing us some headache (written above).

František Šitner
  • 56
  • 9

1 Answers1

1

Each feature should be developed in its own branch.

You merge (branch) B and C in develop, then branch B in staging.

That way, you can manage each feature lifecycle independently.

For a more complete workflow, see gitworkflow.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • So branch next is deployed on development server? And if I want to try other commit, I force push into that branch? And what about deploying on staging? Do I have to have other branch next?And what about if you have commits B, C and D and you want to merge commit C? – František Šitner Aug 20 '18 at 09:34
  • @FrantišekŠitner See https://stackoverflow.com/a/44470240/6309: each stage has its own branch, so if you want to merge a commit... you merge it that said branch. You deploy a branch (like next) on the server you want. – VonC Aug 20 '18 at 09:37
  • so our branch `development` is *pu* and our branch `staging` is *next*? And if topic is tested, then it is merged into `production`? And after that branches `development` and `staging` are resetted from branch `production`? – František Šitner Aug 20 '18 at 10:38
  • @FrantišekŠitner That is the general idea, yes. By using ephemeral branches (except production) that are never merged themselves, you keep the flexibility to merge to those branches any feature branch you want. – VonC Aug 20 '18 at 11:01