哪些Git分支模型适合您？
我们公司目前正在使用简单的主干/发行版/修补程序分支模型，并希望就哪种分支模型最适合您的公司或开发过程提出建议。 工作流程/分支模型 以下是我所见过的三个主要描述，但它们在某种程度上相互矛盾，或者不足以解决我们遇到的后续问题（如下所述）。因此，到目前为止我们的团队默认的解决方案不是那么好。你做得更好吗？ gitworkflows（7）手册页 （nvie）成功的Git分支模型 （reinh）敏捷团队的Git工作流程 合并与重新计算（纠结与顺序历史记录） 还是应该pull --rebase等待合并回到主线，直到任务完成？就个人而言，我倾向于合并，因为这保留了任务开始和完成的基础的可视化插图，我甚至更喜欢merge --no-ff此目的。但是，它还有其他缺点。另外，许多人还没有意识到合并的有用特性-它不是可交换的（将主题分支合并到master并不意味着将master合并到主题分支）。 我正在寻找自然的工作流程 有时会发生错误，因为我们的过程无法使用简单的规则捕获特定的情况。例如，早期版本所需的修复程序当然应该基于足够的下游，以便可以将上游合并到所有必要的分支中（这些术语的用法是否足够清楚？）。但是，碰巧的是，在开发人员意识到应该将修补程序放置在更下游之前，将修补程序放入了母版中，如果该修补程序已经被推送（甚至更糟，已合并或基于此内容），那么剩下的选择就是挑剔的选择，其相关的危险。您使用什么样的简单规则？这也包括一个主题分支的尴尬，它必然排除其他主题分支（假设它们是从同一基准分支出来的）。开发人员不想完成一项功能就可以开始另一种功能，就像他们刚刚编写的代码不再存在一样 如何避免造成合并冲突（由于选择问题）？ 建立合并冲突的肯定方法是在分支之间进行选择，它们再也无法合并了吗？是否可以在任一分支的还原中应用相同的提交（如何执行此操作？）可能会解决这种情况？这是我不敢推动基于合并的工作流的原因之一。 如何分解成局部分支？ 我们意识到，从主题分支组装完成的集成会很棒，但是我们开发人员的工作通常没有明确定义（有时像“四处寻找”一样简单），并且如果某些代码已经进入“杂项”主题，根据上面的问题，它不能再次带出那里吗？您如何定义/批准/毕业/发布主题分支？ 适当的程序，例如代码检查和毕业，当然会很可爱。 但是我们根本无法解决问题，有任何建议吗？整合分支，插图？ 以下是相关问题的列表： 有哪些好的策略可允许已部署的应用程序可修复。 内部开发使用Git的工作流程说明 用于企业Linux内核开发的Git工作流程 您如何维护开发代码和生产代码？（感谢此 PDF！） git发布管理 Git Cherry-pick vs合并工作流程 如何挑选多个提交 如何使用git-merge合并选择性文件？ 如何挑选一系列提交并合并到另一个分支 ReinH Git工作流程 进行修改的git工作流，您将永远不会回到原点 樱桃挑选合并 适用于OS和私有代码的正确Git工作流程？ 用Git维护项目 为什么Git不能使用修改后的父/母合并文件更改。 Git分支/重新建立良好实践 什么时候“ git pull --rebase”会惹上麻烦？ 大型团队如何使用DVCS？ 还请查看Plastic SCM在任务驱动开发方面写的内容，如果您不是选择Plastic，请研究nvie的分支模型及其支持脚本。