哪些 Git 分支模型适合您？

我们公司目前正在使用简单的主干/发布/修补程序分支模型，并且希望了解哪些分支模型最适合您的公司或开发流程。

1. 工作流程/分支模型

   以下是我所看到的三个主要描述，但它们部分相互矛盾，或者不足以解决我们遇到的后续问题（如下所述）。因此，我们的团队到目前为止默认的解决方案并不是那么好。你在做更好的事情吗？

   • gitworkflows(7) 手册页 http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
   • (nvie) 成功的 Git 分支模型 http://nvie.com/git-model
   • (reinh) 敏捷团队的 Git 工作流程 http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

2. 合并与变基（纠结与连续历史）

   应该一pull --rebase或者等待合并回主线直到任务完成？就我个人而言，我倾向于合并，因为这保留了任务开始和完成的视觉说明，我什至更喜欢merge --no-ff以此目的。然而它还有其他缺点。许多人还没有意识到合并的有用特性——事实并非如此可交换的 http://en.wikipedia.org/wiki/Commutativity（将主题分支合并到master并不意味着将master合并到主题分支）。

3. 我正在寻找自然的工作流程

   有时会发生错误，因为我们的程序没有用简单的规则捕获特定的情况。例如，早期版本所需的修复当然应该充分基于下游，以便可以将上游合并到所有必要的分支中（这些术语的用法是否足够清晰？）。然而，在开发人员意识到它应该被放置在更下游之前，修复程序会进入主版本，如果它已经被推送（更糟糕的是，合并或基于它的东西），那么剩下的选项就是精挑细选，其相关的危险。您使用什么简单的规则？这还包括一个主题分支必然排除其他主题分支（假设它们是从公共基线分支）的尴尬。开发人员不想在完成一项功能后开始另一项功能，感觉他们刚刚编写的代码已经不存在了

4. 如何避免产生合并冲突（由于cherry-pick）？

   造成合并冲突的可靠方法似乎是在分支之间进行挑选，它们永远不能再次合并？在任一分支中应用相同的提交来恢复（如何执行此操作？）是否可以解决这种情况？这是我不敢推动很大程度上基于合并的工作流程的原因之一。

5. 如何分解为主题分支？

   我们意识到从主题分支组装完成的集成会很棒，但我们开发人员的工作通常没有明确定义（有时就像“四处探索”一样简单），并且如果某些代码已经进入“杂项”主题，根据上面的问题，它不能再从那里取出吗？您如何定义/批准/毕业/发布您的主题分支？

6. 适当的程序，例如代码审查和毕业当然会很可爱。

   但我们根本无法让事情变得足够理顺来管理这个问题——有什么建议吗？ 整合分支，插图？

以下是相关问题的列表：

• 有哪些好的策略可以允许已部署的应用程序可热修复？ https://stackoverflow.com/questions/143814/what-are-some-good-strategies-to-allow-deployed-applications-to-be-hotfixable
• 内部开发使用 Git 的工作流程描述 https://stackoverflow.com/questions/1049917/workflow-description-for-git-usage-for-in-house-development/1050628
• 用于企业 Linux 内核开发的 Git 工作流程 https://stackoverflow.com/questions/1856241/git-workflow-for-corporate-linux-kernel-development
• 如何维护开发代码和生产代码？ https://stackoverflow.com/questions/216212（感谢this https://stackoverflow.com/questions/216212/how-do-you-maintain-development-code-and-production-code/216219#216219 PDF!)
• git 发布管理 https://stackoverflow.com/questions/1042400/git-releases-management
• Git Cherry-pick 与合并工作流程 https://stackoverflow.com/questions/1241720/git-cherry-pick-vs-merge-workflow
• 如何挑选多个提交 https://stackoverflow.com/questions/1670970/how-to-cherry-pick-multiple-commits
• 如何使用 git-merge 合并选择性文件？ https://stackoverflow.com/questions/449541/how-do-you-merge-selective-files-with-git-merge
• 如何挑选一系列提交并合并到另一个分支 https://stackoverflow.com/questions/1994463/how-to-cherry-pick-a-range-of-commits-and-merge-into-another-branch
• ReinH Git 工作流程 https://stackoverflow.com/questions/855266/reinh-git-workflow
• 用于进行修改的 git 工作流程永远不会推回原点 https://stackoverflow.com/questions/582015/git-workflow-for-making-modifications-youll-never-push-back-to-origin
• 择优合并 https://stackoverflow.com/questions/232771/cherry-pick-a-merge
• 组合操作系统和私有代码的正确 Git 工作流程？ https://stackoverflow.com/questions/2195826/proper-git-workflow-for-combined-os-and-private-code
• 使用 Git 维护项目 https://stackoverflow.com/questions/2587721/maintaining-project-with-git
• 为什么 Git 不能将文件更改与修改后的父级/主控合并。 https://stackoverflow.com/questions/2588824/why-cant-git-merge-file-changes-with-a-modified-parent-master
• Git 分支/变基良好实践 https://stackoverflow.com/questions/2601967/git-branching-rebasing-good-practices
• “git pull --rebase”什么时候会给我带来麻烦？ https://stackoverflow.com/questions/2590260/when-will-git-pull-rebase-get-me-in-to-trouble
• 大型团队如何使用 DVCS？ https://stackoverflow.com/questions/787638/how-are-dvcs-used-in-large-teams

另请查看塑料 SCM 上写的内容任务驱动开发 http://www.plasticscm.com/features/task-driven-development.aspx，如果塑料不是您的选择，请学习nvie的分支模型 http://nvie.com/posts/a-successful-git-branching-model/和他的支持脚本 https://github.com/nvie/gitflow.

DVCS 新开发人员需要认识到的最麻烦的功能是出版流程 https://stackoverflow.com/questions/2473124/source-control-distributed-systems-vs-non-distributed-whats-the-difference/2473315#2473315:

• 您可以导入（获取/拉取）您需要的任何远程存储库
• 您可以发布（推送）到您想要的任何（裸）存储库

由此，您可以遵循一些规则来使您的问题变得更容易：

• 仅在尚未推送分支时才对分支进行变基（自上次变基后未推送）
• 只推送到裸仓库（自 Git1.7 起强制）
• follow Linus 关于变基和合并的建议 http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html

Now:

工作流程/分支模型:

每个工作流程都是为了支持发布管理流程 https://stackoverflow.com/questions/216212#216228，这是为每个项目量身定制的。
我可以添加到您提到的工作流程中的是：每个开发人员不应该创建一个功能分支，而只能创建一个“当前开发”分支，因为事实是：开发人员通常不知道他/她的分支到底会产生什么：一个功能，几个（因为它最终是一个过于复杂的功能），没有（因为没有及时准备好发布），另一个功能（因为原始功能已经“变形”），...

只有“集成商”应该在“中央”存储库上建立官方功能分支，然后开发人员可以获取该分支来重新设置/合并适合该功能的工作部分。

合并与变基（纠结与连续历史）:

我喜欢你提到的我的回答（“内部开发使用 git 的工作流程描述 https://stackoverflow.com/questions/1049917/workflow-description-for-git-usage-for-in-house-development/1050628")

我正在寻找自然的工作流程:

对于修复，它可以帮助将每个修复与错误跟踪中的票证相关联，这有助于开发人员记住他/她应该在哪里（即在哪个分支上，即“用于修复”的专用分支）提交此类修改。
然后，钩子可以帮助保护中央存储库免受未经验证的错误修复或不应推送的分支的推送。 （这里没有具体的解决方案，这一切都需要适应您的环境）

如何避免产生合并冲突（由于cherry-pick）？

正如所述雅库布·纳伦布斯基 https://stackoverflow.com/users/46058/jakub-narebski in 他的回答 https://stackoverflow.com/questions/1241720/git-cherry-pick-vs-merge-workflow/1248741#1248741，挑选应该保留在极少数需要的情况下。
如果你的设置涉及大量的挑选（即“这并不罕见”），那么有些事情就不对劲了。

会在恢复中应用相同的提交（如何做到这一点？）

git revert http://www.kernel.org/pub/software/scm/git/docs/git-revert.html应该解决这个问题，但这并不理想。

如何分解为主题分支？

只要分支尚未被推送到任何地方，开发人员就应该将其提交历史重新组织（一旦他/她最终看到开发采取更明确和稳定的形式）：

• 如果需要的话可以有多个分支（其中一个是由明确识别的功能组成）
• 一个分支内的一组连贯的提交（请参阅修剪 Git 签入 https://stackoverflow.com/questions/2302736/trimming-git-checkins/2302947#2302947)

适当的程序，如代码审查和毕业？

集成分支（在专用集成中）存储库可以帮助开发人员：

• 在远程集成分支之上重新调整他/她的开发（pull --rebase）
• 本地解决
• 将开发推向该仓库
• 请与积分器核实，确保不会造成混乱；）