git branch workflow policy

问题

I am new to git and understand a little bit about Git.
My company is currently have 1 program and the program divides into 5 products. each product is handling by different team.

Currently my company git have 5 branches such as :

• dev = this branch is for developer to build program (dev.program.com)
• test(alpha) = this branch is for tester to test the program (test.program.com)
• staging(beta) = this branch is for tester test the program (double check of error ) and client test the program. (stg.program.com)
• staging-trx = the duplicate of staging and for developer to make sure that no error conflict while cherry pick from staging before it is served to production. (stg-trx.program.com)
• master = merge from staging-trx and ready for production (master.program.com)

This is our work flow.

1. developer finish building a program, the developer will commit and push the files into test branch then tester will do stress test into test environment.
2. after testers are finishing the stress test, developer do pull, cherry pick the committed file from test branch and push into staging branch. after that, tester will do flash test.
3. after testers are finishing the flash test, developer do pull, cherry pick the committed file from staging branch and push into staging-trx branch, after that developer will merge the staging-trx into master branch.

But I have some problems.

Let say in one team have 2 developers (Andy and Robert) and responsible for product A.

• Robert is handling for new feature and bug fixed
• Andy is handling bugs fixed

Currently Robert is still building a new feature and that new feature will affect some files and major changes to the code. so Andy cannot do any revision of code to fix the bug because almost all of code has changed.

If I created new branch for every new feature, the tester would find it difficult to test, moreover there would be more websites to be created only for new feature. this means that not only for product A, but there are another products will face the same problem.

So, is there any solution for this case?

回答1:

This is typically what gitworkflow address

Instead of merging A to B, B to C, C to D and so on, you only merge feature branches.

Each developer (or group of developers) works on a feature branch and merge it to dev for integration testing.

But when it comes to merge to additional development lifecycle step (test in your case, then staging, qa, any name you want), you do not merge dev to test

You merge the selected feature branches (that were initially merged to dev) to the branch you want (test, staging, etc)

That way, you only select the subset of features that you deem ready and working together, as opposed as trying to revert the "not ready" features from dev, and then merging dev to test.

I detail that model further here and illustrate it here

One important point: the dev branch (for integrating feature branches together) is transient: it is created/destroyed for each new release (as opposed to one fixed eternal dev branch merged to master from time to time).

You recreate as many integration branches you need to testing features together (dev, test, staging, and so on).
Then, when ready, you only merge the right feature branches to master (or any other release branch), delete your dev branch, and recreate it for the next release.

So to repeat:

The feature branch is merged multiple times:

• one time to dev for initial integration testing,
• then the same feature branch is merged again in test directly (where a second build can occur, you don't have to rebuild in feature),
• then merged again directly in staging (each time because that feature branch is deemed ready to advance to the next lifecycle development stage)

You do not cherry picking from (for instance) test to staging.
You merge the feature branch which has pass the test to the next step in your integration lifecycle (merge feature to the staging branch)

---

Currently Robert is still building a new feature and that new feature will affect some files and major changes to the code.
So Andy cannot do any revision of code to fix the bug because almost all of code has changed.

Yes, Andy can, in an hotfix branch, dedicated to maintain the latest code released into production.
Both Robert and Andy can participate in that branch, and they will be responsible to apply their fix commits to dev if said fix is needed there (since the code has change, maybe that bug fix is no longer relevant in dev)

does Andy will merge from hot branch to test? because our final step is test => staging => staging trx => master

The all point of this answer is to illustrate you don't have to merge from A to B to C.
For the hotfix branch, you rarely merge it back anywhere else, since the dev or test branches have code which has evolved considerably since the last release. You only cherry-pick the fix commits you need back to dev or test.

---

After the feature has been already in production environment, I will destroy that feature branch right?

Well... yes, "destroying" the feature branch will remove the pointer to that branch.
But the actual commits which were part of said branch will still be visible from the merge commit done on master. That is OK, and can be useful to debug that feature later on: instead of the big final merge commit, you can later check the commits from the second parent of said merge commit: they are the commits from the old feature branch.

---

While the new feature A branch is already in test branch, and tester are still doing stress test to the new feature A, there is bugs in production and Andy will fix the feature B bug in hotfix branch.

The question is, after Andy has fixed the bug in hotfix branch, then where should Andy merge the current hotfix branch?
Because when if there were bugs, and developer has fixed the bug, it would not go directly to production, tester will do test first to check the bug is already really fixed or not.

You would need a second test branch dedicated for testing hotfixes (I would do those test directly on hotfix though) and then merge back to master, to update the production.
The point is: when you identify a parallel development effort (as in "testing feature branches" and "testing an hotfix"), separate branches are required.

But again, for bug fixes, that is typical of an "emergency path" for which you have a shorter branch workflow and a dedicated test-hotfix branch (name it as you want) for that type of scenario.

The other approach is simply to reset the test branch, and merge back only the branches you need urgently (feature B in this case): test, the merge B to staging etc... all the way to master.
Finally, once B is ready, you can use the same test branch to add (merge) feature A back in, and continue your test on A in an environment where B has already been validated.

The drawback of resetting test is that it blocks all other development integration though.
That is why a dedicated branch for this is preferable.

来源：https://stackoverflow.com/questions/56554355/git-branch-workflow-policy