问题描述
我们公司目前正在使用简单的主干/发布/修补程序分支模型，并希望就哪种分支模型最适合您的公司或开发过程提供建议.
Our company is currently using a simple trunk/release/hotfixes branching model and would like advice on what branching models work best for your company or development process.
工作流/分支模型
以下是我所看到的三个主要描述，但它们彼此部分矛盾，或者不足以解决我们遇到的后续问题(如下所述).因此，到目前为止，我们的团队默认的解决方案不是那么好.你做得更好吗?
Below are the three main descriptions of this I have seen, but they are partially contradicting each other or don't go far enough to sort out the subsequent issues we've run into (as described below). Thus our team so far defaults to not so great solutions. Are you doing something better?
合并与变基(纠结与连续历史)
应该 pull --rebase 还是等待合并回主线直到您的任务完成?就我个人而言，我倾向于合并，因为这保留了任务在哪个基础上开始和完成的直观说明，为此我什至更喜欢 merge --no-ff.然而，它还有其他缺点.许多人还没有意识到合并的有用特性——它不是 可交换(合并一个主题分支到 master 并不意味着将 master 合并到主题分支).
Should one pull --rebase or wait with merging back to the mainline until your task is finished? Personally I lean towards merging since this preserves a visual illustration of on which base a task was started and finished, and I even prefer merge --no-ff for this purpose. It has other drawbacks however. Also many haven't realized the useful property of merging - that it isn't commutative (merging a topic branch into master does not mean merging master into the topic branch).
我正在寻找一个自然的工作流程
有时会发生错误，因为我们的程序没有用简单的规则来捕捉特定的情况.例如，早期版本所需的修复当然应该基于足够的下游，以便可以将上游合并到所有必要的分支中(这些术语的使用是否足够清楚?).然而碰巧的是，在开发人员意识到它应该被放置在更远的下游之前，修复使它进入主版本，如果已经推送(更糟糕的是，合并或基于它的东西)，那么剩下的选项就是挑选，用其相关的危险.你使用什么简单的规则?这也包括了一个主题分支的尴尬，它必须排除其他主题分支(假设它们是从一个共同的基线分支出来的).开发人员不想完成一个功能来启动另一个功能，感觉他们刚刚编写的代码已经不存在了
Sometimes mistakes happen because our procedures don't capture a specific situation with simple rules. For example a fix needed for earlier releases should of course be based sufficiently downstream to be possible to merge upstream into all branches necessary (is the usage of these terms clear enough?). However it happens that a fix makes it into the master before the developer realizes it should have been placed further downstream, and if that is already pushed (even worse, merged or something based on it) then the option remaining is cherry-picking, with its associated perils. What simple rules like such do you use? Also in this is included the awkwardness of one topic branch necessarily excluding other topic branches (assuming they are branched from a common baseline). Developers don't want to finish a feature to start another one feeling like the code they just wrote is not there anymore
如何避免产生合并冲突(由于优先选择)?
在分支之间进行挑选似乎是产生合并冲突的可靠方法，它们永远无法再次合并?在任一分支中在 revert 中应用相同的提交(如何做到这一点?)可能会解决这种情况吗?这是我不敢推动主要基于合并的工作流程的原因之一.
What seems like a sure way to create a merge conflict is to cherry-pick between branches, they can never be merged again? Would applying the same commit in revert (how to do this?) in either branch possibly solve this situation? This is one reason I do not dare to push for a largely merge-based workflow.
如何分解为主题分支?
我们意识到从主题分支组装完成的集成会很棒，但是我们的开发人员的工作通常没有明确定义(有时就像四处闲逛"一样简单)，并且如果某些代码已经进入杂项"" 话题，根据上面的问题，不能再从那里取出来了?您如何定义/批准/毕业/发布主题分支?
We realize that it would be awesome to assemble a finished integration from topic branches, but often work by our developers is not clearly defined (sometimes as simple as "poking around") and if some code has already gone into a "misc" topic, it can not be taken out of there again, according to the question above? How do you work with defining/approving/graduating/releasing your topic branches?
适当的程序，如代码审查和毕业当然会很可爱.
但是我们根本无法保持足够的清晰来管理这个 - 有什么建议吗?集成分支，插图?
But we simply cannot keep things untangled enough to manage this - any suggestions?integration branches, illustrations?
以下是相关问题列表:
- 有哪些好的策略允许已部署的应用程序进行热修复?
- 内部 Git 使用的工作流描述发展
- 企业 Linux 内核开发的 Git 工作流程
- 您如何维护开发代码和生产代码?(感谢 这个 PDF！)
- git 发布管理
- Git Cherry-pick 与合并工作流
- 如何挑选多个提交
- 如何使用 git-merge 合并选择性文件?
- 如何樱桃选择一系列提交并合并到另一个分支
- ReinH Git 工作流程
- 用于进行修改的 git 工作流程'永远不会推回原点
- 樱桃挑选合并
- 适合组合操作系统和私有代码的 Git 工作流程?
- 使用 Git 维护项目
- 为什么 Git 不能将文件更改与修改后的父/母.
- Git 分支/重新定位良好做法
- 什么时候会git pull --rebase"让我惹上麻烦?
- 大型团队如何使用 DVCS?
- What are some good strategies to allow deployed applications to be hotfixable?
- Workflow description for Git usage for in-house development
- Git workflow for corporate Linux kernel development
- How do you maintain development code and production code? (thanks for this PDF!)
- git releases management
- Git Cherry-pick vs Merge Workflow
- How to cherry-pick multiple commits
- How do you merge selective files with git-merge?
- How to cherry pick a range of commits and merge into another branch
- ReinH Git Workflow
- git workflow for making modifications you’ll never push back to origin
- Cherry-pick a merge
- Proper Git workflow for combined OS and Private code?
- Maintaining Project with Git
- Why cant Git merge file changes with a modified parent/master.
- Git branching / rebasing good practices
- When will "git pull --rebase" get me in to trouble?
- How are DVCS used in large teams?
另请查看 Plastic SCM 在任务驱动开发上写的内容，如果您不选择塑料，请研究 nvie 的分支模型和他的支持脚本.
Also check out what Plastic SCM writes on task driven development, and if Plastic is not your choice, study nvie's branching model and his supporting scripts.
推荐答案
DVCS 新开发人员需要意识到的最麻烦的功能是关于 发布流程:
The most troubling feature new developers to DVCS need to realize is about the publication process:
- 您可以导入(获取/拉取)您需要的任何远程存储库
- 您可以发布(推送)到您想要的任何(裸)存储库
由此，您可以遵守一些规则来简化您的问题:
From that, you can respect a few rules to make your questions easier:
- 只有在没有被推送的情况下才对分支进行 rebase(自上次 rebase 以来没有推送)
- 仅推送到裸仓库(自 Git1.7 起强制执行)
- 遵循 Linus 关于变基和合并的建议
现在:
工作流/分支模型:
每个工作流程都是为了支持发布管理流程，并且为每个项目量身定制.
我可以添加到您提到的工作流程中的是:每个开发人员不应该创建一个功能分支，而应该创建一个当前开发"分支，因为事实是:开发人员通常不知道他/她的分支会产生什么:一个功能，几个(因为它最终成为一个太复杂的功能)，没有(因为没有准备好发布)，另一个功能(因为原始功能已经变形")，...
each workflow is there to support a release management process, and that is tailored for each project.
What I can add to the workflow you mention is: each developer should not create a feature branch, only a "current dev" branch, because the truth is: the developer often doesn't know what exactly his/her branch will produce: one feature, several (because it ended up being too complex a feature), none (because not ready in time for release), another feature (because the original one had "morphed"),...
只有集成商"应该在中央"存储库上建立官方功能分支，然后开发人员可以获取这些分支以重新设置/合并适合该功能的部分工作.
Only an "integrator" should established official feature branches on a "central" repo, which can then be fetched by developers to rebase/merge the part of their work that fits that feature.
合并与变基(纠结与连续历史):
我喜欢你提到的我的回答("工作流程内部开发的 git 使用说明")
I like my answer you mention ("Workflow description for git usage for in-house development")
我正在寻找一个自然的工作流程:
对于修复，它可以帮助将每个修复与错误跟踪的票证相关联，这有助于开发人员记住他/她应该在哪里(即在哪个分支，即用于修复"的专用分支)提交此类修改.
然后钩子可以帮助保护中央存储库免受来自未经验证的错误修复或来自不应推送的分支的推送.(这里没有具体的解决方案，所有这些都需要适应您的环境)
for fixes, it can help associating each fix with a ticket from a bug tracking, which helps the developer remember where (i.e. on which branch, i.e. a dedicated branch "for fixes") he/she should commit such modifications.
Then hooks can help protect a central repo against pushes from non-validated bug-fixes or from branches from which one shouldn't push. (no specific solution here, all this need to be adapted to your environment)
如何避免产生合并冲突(由于挑选)?
如 Jakub Narębski 在 他的回答，樱桃采摘应该保留在需要的罕见情况下.
如果您的设置涉及大量挑选(即这并不罕见")，那么就有些问题了.
As stated by Jakub Narębski in his answer, cherry-picking should be reserved for rare situations where it is required.
If your setup involves a lot of cherry-picking (i.e. "it is not rare"), then something is off.
是否会在还原中应用相同的提交(如何做到这一点?)
git revert 应该注意这一点，但这并不理想.
git revert should take care of that, but that is not ideal.
如何分解为主题分支?
只要一个分支还没有被推送到所有地方，开发者就应该重新组织它的提交历史(一旦他/她最终看到开发具有更明确和更稳定的形状):
As long as a branch as not yet been pushed everywhere, a developer should reorganize its history of commits (once he/she finally see the development takes a more definitive and stable shape) into:
- 如果需要，可以创建多个分支(一个由明确标识的功能组成)
- 一个分支内的一组连贯提交(请参阅修剪 Git 签入)
适当的程序，如代码审查和毕业?
集成分支(在专用集成中)存储库可以帮助开发人员:
Integration branches (in a dedicated integration) repo can help the developer to:
- 在该远程集成分支之上重新构建他/她的开发 (pull --rebase)
- 本地解决
- 推动开发到该存储库
- 与不会导致混乱的集成商核对 ;)
这篇关于哪些 Git 分支模型适合您?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！