git branch工作流程政策 [英] git branch workflow policy

问题描述

我是git的新手，对Git有所了解.
我公司目前有1个程序，该程序分为5个产品.每个产品由不同的团队处理.

目前我公司的git有5个分支机构，例如:

• dev =该分支供开发人员构建程序(dev.program.com)
• test(alpha)=该分支供测试人员测试程序(test.program.com)
• staging(beta)=此分支用于测试人员测试程序(错误的双重检查)并由客户端测试程序. (stg.program.com)
• staging-trx =分段的副本，供开发人员确保在将其用于生产之前从分段中挑选樱桃时确保没有错误冲突. (stg-trx.program.com)
• master =从staging-trx合并并准备投入生产(master.program.com)

这是我们的工作流程.

1. 开发人员完成程序的构建，开发人员将提交文件并将其推送到测试分支，然后测试人员将对测试环境进行压力测试.
在测试人员完成压力测试之后，开发人员进行拉动，从测试分支中挑选已提交的文件，然后推入暂存分支.之后，测试人员将进行Flash测试.
2. 测试人员完成Flash测试后，开发人员进行拉动，从暂存分支中提取已提交的文件，然后推入staging-trx分支中，然后开发人员将staging-trx合并到master分支中.

但是我有一些问题.

让我们说一个团队中有2个开发人员(Andy和Robert)并负责产品A.

• Robert正在处理新功能并修复了错误
• Andy正在修复错误

当前，Robert仍在构建一个新功能，该新功能将影响某些文件和代码的重大更改.因此Andy不能进行任何代码修订来修复该错误，因为几乎所有代码都已更改.

如果我为每个新功能都创建了新分支，那么测试人员会发现很难进行测试，而且还会有更多的网站仅针对新功能创建.这意味着不仅对于产品A，还有其他产品也将面临相同的问题.

那么，这种情况有什么解决办法吗?

解决方案

这通常是 gitworkflow 地址

>

仅合并feature个分支，而不是将A合并到B，将B合并到C，将C合并到D等.

每个开发人员(或一组开发人员)在feature分支上工作并将其合并到dev进行集成测试.

但是，要合并到其他开发生命周期步骤(根据您的情况进行测试，然后进行分阶段测试，再加上您想要的任何名称)，您不要将dev合并到test

您将选定的feature分支(最初合并到dev)合并到所需的分支(测试，暂存等)

那样，您只选择您认为已经准备好并且可以一起使用的功能的子集，而不是尝试还原未准备好"的功能. dev中的功能，然后将dev合并到test.

我在此处进一步详细说明该模型和 cherry-pick 即可将所需的修复提交回dev或test

---

feature已经在production环境中之后，我将销毁feature分支吗?

嗯...是的，摧毁" feature分支将删除指向该分支的指针.
但是从master上完成的合并提交中仍然可以看到属于该分支的实际提交.没关系，这对于以后调试该功能很有用:代替大的最终合并提交，您以后可以检查来自所述合并提交的第二个父提交的提交:它们是来自旧功能分支的提交.

---

虽然新的feature A分支已经在test分支中，并且测试人员仍在对新的feature A进行压力测试，但是生产中存在错误，Andy将修复hotfix中的feature B错误分支.

问题是，在Andy修复了hotfix分支中的错误之后，Andy应该在哪里合并当前的修补程序分支?
因为如果存在错误，并且开发人员已修复该错误，它将无法直接投入生产，因此测试人员将首先进行测试，以检查该错误是否已真正修复.

您将需要一个专门用于测试修补程序的 second test分支(不过我将直接在hotfix上进行那些测试)，然后合并回master，以更新产品.
关键是:当您确定并行开发工作时(例如在测试功能分支"和测试修补程序"中)，需要单独的分支. >

但同样，对于错误修复，这是紧急路径"的典型特征.对于这种情况，您具有较短的分支工作流程和专用的test-hotfix分支(根据需要命名).

另一种方法是简单地重置 test分支，然后仅合并您紧急需要的分支(在本例中为feature B):测试，将B合并到暂存等等...一直到master.
最后，一旦B准备就绪，您可以使用同一测试分支重新添加(合并)feature A，并在已经验证了B的环境中继续在A上进行测试.

重置测试的缺点是尽管它会阻止所有其他开发集成.
这就是为什么最好使用专门的分支.

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?

解决方案

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.

这篇关于git branch工作流程政策的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！