子树是我正在寻找的工作流程吗？

Question

我正在尝试设置一个工作流程，用于在项目的不同工作环境之间移动。 所有这三个区域都是他们自己的独立文件夹（他们是网站），我希望能够在开发时间表上工作，直到我准备好进行QA测试，然后将我的版本推送到QA时间线。 一旦QA完成，我想把它推到生产中以供一般使用。 所有时间线都是他们自己的独立文件夹，因为它们是网站。 我在Visio中画了一张图片来说明我脑子里的工作流程。 使用的是我正在寻找的子树吗？ 或者有更好的方法吗？ 谢谢！ 注意：我现在正在使用自己的数据库服务器实例和FTP服务器运行Windows server 2012 R2，IIS 8，开发，测试和生产他们自己的独特网站。

Answer 1

从一个非常小的团队角度分享我的经验。 我们的生产和测试环境位于同一主分支上，但按分支名称（master，qc）和tag（master.01.date，qc.01.date等）分开。 我们做了很多rebase / cherry-pick / merge dev提交到主分支然后相应地发布到网站（QC / Production）。

Dev A和B在当前或上一次生产提交的某个地方分支。

Dev A完成，重新定位到主分支，发布到QC站点，并发送给QC团队。

这可能不适用于更大的团队或复杂的项目。 但这对我们来说很容易理解。 我希望我们在合并之前压缩提交，但是我们有太多的提交，但它们更容易追踪。

Answer 2

您可以在仓库中使用单独的分支，并让每个文件夹克隆仓库并签出相应的分支。 这将让您轻松地根据需要进行合并和分支（根据您希望历史记录的外观进行重新定位;根据您的描述，我认为您希望合并而不进行重新定位，因为那样您只需要一次提交，例如“合并” QA投入生产“而不是全部提交QA承诺”。 这将在每个文件夹中包含.git目录带来一点开销，但似乎值得方便。

还有可能检出文件夹中的错误分支。 如果您对此感到担心，您可以将每个文件夹设置为自己的空（或大部分为空）回购，其中包含您的实际代码作为子模块。 这将允许您将文件夹锁定到特定的提交（以及分支）。 例如，在将QA合并到生产分支之后，您可以将生产回购的关系推进到该新提交的子模块。

最好避免采摘樱桃，因为这会导致各种奇怪的问题并使历史更难以遵循。