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).
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.