git 分支工作流策略 [英] 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 = staging 的副本，供开发人员确保在从 staging 中挑选樱桃时没有错误冲突，然后再投入生产.(stg-trx.program.com)
• master = 从 staging-trx 合并并准备投入生产 (master.program.com)

这是我们的工作流程.

1. 开发者完成一个程序，开发者将提交并将文件推送到测试分支，然后测试者将对测试环境进行压力测试.
2. 测试人员完成压力测试后，开发人员进行拉取，从测试分支中挑选提交的文件并推送到暂存分支.之后，测试人员将进行 Flash 测试.
3. 测试人员完成 flash 测试后，开发人员执行 pull，cherry 从 staging 分支中挑选提交的文件并推送到 staging-trx 分支，之后开发人员会将 staging-trx 合并到 master 分支.

但是我有一些问题.

假设一个团队有 2 名开发人员(安迪和罗伯特)并负责产品 A.

• Robert 正在处理新功能和修复的错误
• Andy 正在处理已修复的错误

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

如果我为每一个新功能都创建新的分支，测试人员会发现很难测试，而且会为新功能创建更多的网站.这意味着不仅产品A，还有其他产品会面临同样的问题.

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

解决方案

这通常是

您只需合并 feature 分支，而不是将 A 合并到 B、B 合并到 C、C 合并到 D 等等.

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

但是，当涉及到合并到额外的开发生命周期步骤(在您的情况下进行测试，然后是 staging、qa、您想要的任何名称)时，您 不要将 dev 合并到 测试

您将选定的 feature 分支(最初合并到 dev)合并到您想要的分支(测试、登台等)

这样，您只需选择您认为已准备好并可以一起使用的功能子集，而不是尝试恢复未准备好"的功能.dev 中的特征，然后将 dev 合并到 test.

我在此处进一步详细说明该模型和在这里说明

重要的一点:dev 分支(用于将 feature 分支集成在一起)是transient:它为每个新版本创建/销毁(与一个固定的永恒 dev 分支不时合并到 master 不同).

您可以重新创建尽可能多的集成分支，以便一起测试功能(开发、测试、暂存等).
然后，准备好后，您只需将正确的 feature 分支合并到 master(或任何其他 release 分支)，删除您的 dev 分支，并为下一个版本重新创建它.

重复一遍:

feature分支多次合并:

• 一次dev进行初始集成测试，
• 然后在 test 中再次合并相同的 feature 分支(可以进行第二次构建，您不必在 feature),
• 然后直接在 staging 中再次合并(每次都是因为该 feature 分支被认为已准备好进入下一个生命周期开发阶段)

您不从(例如)test 到 staging.
您将已通过 test 的 feature 分支合并到集成生命周期的下一步(将 feature 合并到 staging分支)

---

<块引用>

目前罗伯特仍在构建一个新功能，该新功能将影响一些文件和对代码的重大更改.
因此，Andy 无法对代码进行任何修改来修复该错误，因为几乎所有代码都已更改.

是的，Andy 可以在 hotfix 分支中专门维护发布到生产环境中的最新代码.
Robert 和 Andy 都可以参与该分支，如果那里需要所述修复，他们将负责将他们的修复提交应用到 dev(由于代码已更改，也许该错误修复不再相关在 dev)

<块引用>

Andy 会从热分支合并到测试吗?因为我们的最后一步是 test =>暂存 =>staging trx =>主人

这个答案的全部意义在于说明您不必从 A 合并到 B 到 C.
对于 hotfix 分支，您很少将其合并回其他任何地方，因为 dev 或 test 分支的代码自上次发布以来已经有了很大的发展.您只需 cherry-pick 将您需要的修复提交回 dev 或 测试.

---

<块引用>

feature已经进入production环境后，我会销毁那个feature分支对吧?

嗯...是的，破坏"；feature 分支将删除指向该分支的指针.
但是，作为所述分支的一部分的实际提交仍然可以从 master 上完成的合并提交中看到.没关系，并且对于稍后调试该功能很有用:您可以稍后检查来自所述合并提交的第二个父级的提交，而不是大的最终合并提交:它们是来自旧功能分支的提交.

---

<块引用>

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

问题是，在Andy修复了hotfix分支的bug之后，Andy应该把当前的hotfix分支合并到哪里呢?
因为如果有bug，并且开发者已经修复了bug，它不会直接投入生产，测试人员会先做测试，检查bug是否已经真正修复.

你需要一个 second test 分支专门用于测试修补程序(我会直接在 hotfix 上进行这些测试)，然后合并回来到master，更新生产.
重点是:当您确定并行开发工作时(如测试功能分支"和测试修补程序")，需要单独的分支.p>

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

另一种方法是简单地reset test 分支，然后只合并你急需的分支(在这种情况下为feature B): 测试，将 B 合并到 staging 等...一直到 master.
最后，一旦 B 准备就绪，您可以使用相同的测试分支重新添加(合并)feature A，并继续在 A 在 B 已经过验证的环境中.

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

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 分支工作流策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！