功能分支的 git flow
团队当前的 git 流程。
总共 3 个分支
main
develop
feature
当我们处于开发阶段时
当有新的 jira 票证时，我们将从开发中创建一个功能分支。
完成该功能后，我们会将其合并到开发中。
当我们想要更新主分支时，我们会将开发合并到主分支中。
但是应用程序现在向公众开放，我们希望有更好的git流程。
像往常一样，如果我们完成了该功能，我们会将其合并到开发分支中。
然后测试人员将测试该功能是否完成且没有错误。
测试人员测试完毕后，他们会要求我们（开发人员）仅部署该功能，
这与之前的做法完全不同
例如，如果开发人员完成了功能 A，然后测试人员已经在开发分支中验证了它，之后我们只需将功能 A 合并到主分支中。
因此我想知道对于这种情况是否有任何建议的流程。
The current git flow for the team.
3 branches in total
main
develop
feature
When we're in the development stage
When there is a new jira ticket, we will create a feature branch from develop.
After completing the feature, we will merge the feature into develop.
When we want to update the main branch, we will merge develop into main branch.
But the application is now open to public, we want to have better git flow.
As usual, if we finish the feature, we will merge it into develop branch.
Then the tester will test if the feature is completed without bug.
Once the testers've tested, they will ask us(developers) to deploy ONLY that feature,
which is totally different from previous practice
For example, if developers complete feature A and then the testers've verified it in develop branch, after that we have to merge only feature A into main branch.
Therefore I want to know if there is any suggested flow for this situation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当您定期释放一组在单个commit 中存在状态的功能时，GIT流量最有效。这就是为什么GIT流建议从（commit on）
开发创建Release分支的原因。这可能是一个或许多功能，但目的是发布该提交的所有功能。错误修复了这些功能的任何一个都可以在Release分支上完成，以便可以同时继续开发。考虑GIT流动的另一种方法是：
即使您希望对工作流程进行的所需调整在概念上是微不足道的，但我相信您不应该再使用GIT流动了。如果您为每个功能制作了新的
版本分支，则可以坚持使用GIT流，但是您需要按照它们创建的顺序发布它们，否则您最终需要需要要进行大量恢复以削减想要跳过的特定功能。基于对您情况的描述，我提出的解决方案是使用GIT使用的维护者，该方法称为 gitworkflows 。更改将包括：
开发分支为下一个。下一个MAIN。 （每周一次，或迭代通常效果很好。）main新功能。下一个进行集成测试。main中并部署到生产中。话虽这么说，在我的公司中，在我们的一个较大的存储库中，我们实际上是两者兼而有之。我们使用git流几乎是“标准”方式（并且功能分支仍然来自
开发），但是我们通过将它们合并到一个称为Next 的分支中来验证这些功能。有时将它们修复并再次合并多次，然后最终将它们合并到开发中。当我们从开发创建一个版本分支时，它已经很好地硬化了，并且对Release> Release>分支上的错误修复通常很小。如果您希望有时会一起发布多个功能，则此混合工作流程可能对您有效。但是，如果您的正常用例是一次发布一项功能，那么我可能会考虑跳过GIT流的开销。Git Flow works best when you periodically release a set of features whose state exists in a single commit. This is why Git Flow recommends creating a
releasebranch from (a commit on)developwhich you wish to test. This may be one feature or many, but the intention is that all of the features at that commit will be released. Bug fixes to any of those features are done on thereleasebranch so that new development can simultaneously continue ondevelop.Another way to think about Git Flow is this:
Even though the desired tweak you wish to make to your workflow is conceptually trivial, I believe it's enough that you should no longer use Git Flow. You might be able to stick with Git Flow if you made a new
releasebranch for every feature, but then you would need to release them in the order they were created, or else you'll end up needing to do a lot of reverting to cut out specific features you wish to skip.Based on the description of your situation, my proposed solution is to use what the maintainers of Git use, which is called Gitworkflows. The changes would include:
developbranch tonext.nexttomain. (Once per week, or iteration often works well.)mainfor new features.nextfor integration testing.mainand deploy to production.That being said, at my company in one of our larger repos, we actually do a combination of both. We use Git Flow pretty much the "standard" way (and feature branches still come off of
develop), but we validate the features by merging them into a branch callednext, sometimes fixing them up and merging in again multiple times, before finally merging them intodevelop. By the time we create areleasebranch fromdevelopit's already pretty well hardened, and bug fixes on thereleasebranch are oftentimes minimal. This hybrid workflow may work well for you if you wish to sometimes release multiple features together. But if your normal use case is to release one feature at a time, then I'd probably consider skipping the overhead of Git Flow.