在企业版github中模拟tfs样式更改集

Question

我有三个环境;开发，测试和升级/生产。在我们之前使用Team Foundation Server的模型中，我们将有三个代码分支，这些分支与这三个环境中的每个环境相匹配。

开发人员可以在本地工作，当他们完成代码时，他们会将其检入dev分支。签入时，TFS会自动创建一个名为变更集的内容。此签入将启动文件构建到代码中，然后将代码部署到开发环境中。

当开发人员对开发中的代码感到满意时，他们只会将他们的变更集合并到测试分支中。他们会提取所有未合并到测试中的可用变更集的完整列表，他们会选择他们并将其检入测试分支。同样，这将启动构建，并且将部署输出文件以进行测试。

一旦QA对这些变化感到满意，开发人员会将此变更集合并到prod分支中。启动构建，文件将部署到临时区域。开发人员和QA会将这些文件提升为prod。

所有这些都允许多个开发人员使用此变更集心态处理相同的文件。当特定变更集（或变更集集）合并到另一个环境中时，只会合并这些变更。

在我对git的相对较新的曝光中，我似乎无法找到一种方法来选择特定的＆＃34;拉取请求＆＃34; （我假设它类似于TFS变更集）从一个分支到另一个分支。当我尝试从一个分支到另一个分支发出拉取请求时，它不仅要拉入我的拉取请求，还要拉入其他开发人员在下层分支中发出的每个其他拉取请求。实现这一目标的神奇方法是什么？

注意 ：很遗憾，我们没有＆＃34;发布＆＃34;的概念。我们有五个Scrum团队在一个网站上工作，有200多页。每个Scrum团队都有自己的冲刺，可以在冲刺期间发布多个scrum故事。我们内部只有一个DEV环境，一个TEST环境和一个PROD环境。这五个Scrum团队不仅使用我们的环境，而且这些DEV / TEST / PROD站点也被各种其他团队用于与我们销售的应用程序以及客户帐户管理和购买的集成工作。我们无法改变该基础设施。

注意 ：这不是关于这个＆＃34;变更集＆＃34;的讨论。方法是正确的还是正确的。这是如何在github / git中实现此行为的问题。

注意 ：我们是一组基于Scrum的敏捷团队。我们从故事中工作。我们拥有超过25名开发人员的大型团队，任何时候都可以积极开发60多个故事。当一个故事准备好生产时，我们将它作为原子单位推广到生产环境。因此，将变更集视为一个故事。

Answer 1

我有两个想法：

1. 不要这样做。相反，你应该看看git-flow。 http://danielkummer.github.io/git-flow-cheatsheet/和http://nvie.com/posts/a-successful-git-branching-model/是很好的解释。在它的核心，git-flow是分支的命名约定，所以它根本不依赖于git。从本质上讲，您拥有每个开发人员或开发团队都在处理的功能分支。完成功能后，它们会合并到develop。 develop已完成功能＆＃34; - 不是＆＃34;已完成＆＃34;而是＃34;功能齐全。＆＃34;当我们认为有时间发布时，我们会分叉到一个新的release/someversion分支（名称以匹配发布名称），然后使用QA来加强发布。 release/someversion分支上的提交只是错误修复。一旦它足够好部署，我们fast-forward master分支到发布分支，因为我们将其推向生产。 master然后表示生产中的内容。在我们部署时，我们还将release/someversion合并到develop中，以便将错误修复纳入开发主线。然后，项目经理/产品负责人可以将develop分支视为＆＃34;最新的＆＃34;并且开发人员可以继续他们的功能分支，直到他们完成功能。 （提示，使功能变小 - 比如一小时或一天。功能不是发布。）

那为什么这比你做的更好？如果该功能已经完成，已经足够准备好让QA开始敲击它，那么它已经做得足以成为下一个版本的一部分。挑选和选择彼此的功能将导致你进入非常微妙和不可预测的错误。由于您在每一步都重新合并，因此您可能会错误地合并，从而产生错误。您现在也正在创建每个步骤的独特产品，因此您可以使用与在开发和测试中检查完全不同的功能集来进行生产。 （这会做坏事吗？问你的药剂师这些药物在一起服用时是否会相互作用。）

Git-flow适用于节奏很好，你有很好的协调，不常见，更大的版本。随着您越来越接近持续交付，这个仪式将阻碍您。此时，您可以选择翻转GitHub flow或类似的轻量级命名约定。

1. 如果你真的，真的，真的（见上文＆＃34;你不应该这样做＆＃34;评论）说服你应该这样做，首先，去{{ 3}}并希望你能说服自己。如果您仍然真的，确信您需要这样做，那么您经常需要convince a rubber duck您的提交一起为整个功能创建一个大型提交，然后squash变更集分支之间。

这有一些不利之处＆＃34;南瓜和樱桃挑选＆＃34;做法。你失去了历史。由于您要将历史记录在一起，因此您必须将功能保存在非常包含的捆绑包中，并且经常编辑捆绑包作为一个整体。源代码控制的主要前提之一是您获得审计历史记录 - 如果出现问题则回滚，以及在需要了解为什么某些内容以这种方式工作或与谁交谈时引用。 （请参阅＆＃34; git blame＆＃34;。）当您压缩时，您有意删除该学习工具。 2.您以不同的顺序播放功能。因此，您经常进行合并。是什么让git如此棒，合并很容易。是什么让git合并变得容易，你做的很小。这种将与此功能相关的所有内容压缩成一个巨大的提交并在分支之间挑选它的方法意味着您正在进行非常大的合并...这意味着它很难。

是的，我知道你一直很喜欢它一直以来的方式，你真的不想让别人告诉你你的宝宝是丑陋的。抱歉。你的宝宝很难看。从好的方面来说，它并不需要。 Git流程很棒，绝对可以提高团队所需的速度。

Answer 2

您之前的行为功能失调。虽然并不罕见：http://nakedalm.com/avoid-pick-n-mix-branching-anti-pattern/

在Git中，你最有可能想要做两件事。第一个是遵循Git Flow：http://nvie.com/posts/a-successful-git-branching-model/

完成此操作后，您可以查看为二进制文件创建部署管道，而不是源文件。您应该从MASTER进行构建，并且该构建将遍历您的环境。很高兴在这里和离线讨论。