GIT分支/合并策略（主干中没有垃圾）

我目前正在研究如何将subversion repo移动到git（bitbucket）。对我来说，最大的障碍是理解如何将当前基于SVN的分支/合并策略转换为git

我们的做法类似于“主干中没有垃圾”。具体来说，我们有两个分支（一个用于主动开发，一个用于分段/QA）和主干（生产）：

实际上：

每个开发人员处理一个新的开发特性，将其更改提交给开发分支

当特性准备好进行测试时，与特性相关的开发修订将合并到staging中

一旦该功能准备好展开，相关的暂存修订将合并到主干中

从subversion的角度来看，它有点像这样：

发展中的工作

• svn签出…/branchs/dev

  （即：在dev分支工作）

• svn commit-m“re-ticket#1234”

  （可能会发生多次提交，在本例中是修订版100、102和105）

将功能合并到暂存

• svn签出…/branchs/staging

  （即：在staging branch中工作）

• svn合并…/branchs/dev-c 100102105

• svn提交-m“re#1234 revs 100102105”

  （这样可以创建110版）

将功能合并到产品

• svn签出…/trunk

  （即：在trunk中工作）

• svn merge…/branchs/staging-c 110

  （假设staging中此功能只有一个修订版…可能会有更多）

• svn提交-m“re#1234 revs 110”

这种结构使我们能够实现以下目标：

• 独立开展开发工作的安全空间
• 集成测试环境，仅包含来自开发的准备工作
• 仅包含QA批准代码中的准备工作的生产环境
• 额外强调：我们努力避免“要么全部，要么什么都没有”的合并策略，并选择要移动到其他代码行中的修订

对于所有关于git分支/合并策略的谷歌搜索，我见过的最好的解决方案是主题/功能分支，然后将其合并到主代码行中。这似乎涉及到一个要么全部合并，要么什么都不合并的过程

在大多数情况下，我不在乎git中的流程在功能上是否相同，但该策略的特性是可比较的

对git新手有什么建议吗

谢谢

迈克

PS-经过更多的挖掘，我发现skullcandy工作流似乎是最接近我想要做的。我最好的猜测是，它将通过git完成（有大量的bitbucket拉取请求），就像这样（假设存在两个分支-master和staging）：

• git签出主机

• git分行功能-001

• （进行更改）

• git提交-a

• git推送-u原点功能-001

• 在bitbucket中为feature-001创建拉取请求，以进行暂存
• 拉取请求批准后，通过bitbucket合并到暂存中
• 在功能通过分段QA后，在bitbucket feature-001中向master发出新的拉取请求
• 拉取请求批准后，通过bitbucket合并到master中，删除feature-001分支

这似乎是一个很好的过程。最佳实践？我不知道

---

流程完成后，我不理解的一个“副作用”是，bitbucket报告登台分支在master之前执行？

您在文章末尾概述的工作流是基本的Github工作流，但它有一个缺陷。您的要素分支脱离了

master

，但它们被合并到

staging

和

master

中。这是第一次双合并后的结果

          - - - - - 5 [staging]
         /         /
        | Z - Y - X
        |/         \
1 - 2 - 3 - - - - - 4 [master]

请注意，

staging

和

master

具有相同的内容，但它们具有不同的提交ID和历史记录。这会使事情变得复杂。您不仅需要两次（可能以不同的方式）解决任何合并冲突，而且还扼杀了Git的一个主要特性：相同的提交具有相同的ID

等等，情况变得更糟了。因为您会立即合并到

staging

，然后是QA，然后在QA之后再合并到

master

，所以功能可以以不同的顺序合并到

master

和

staging

。这不仅会产生一个总的历史记录，还会产生具有不同解决方案的不同合并冲突。现在您真的不知道

master

和

staging

是否相同。您可以使用

git diff master staging

进行检查，但很难找到差异泄漏的地方以及原因

            - - - - - 5 - - - - 6 - 7 [staging]
           /         /         /  /
          /         / E - F - G -+-
         /         / /          /  \
        | Z - Y - X /  J - K - L    \
        |/         \|/          \    \
1 - 2 - 3 - - - - - 4 - - - - - - 8 - 9 [master]

在本例中，

EFG

和

JKL

都从

master

上的相同提交开始

EFG

在

JKL

之前合并到暂存中，但

JKL

首先完成QA，然后在

EFG

之前合并回

master

<代码>主控和分段现在可能有所不同。此外，您的历史图表粗俗且难以理解

我猜你在用？我在实践中从未见过这样的工作流，习惯性地合并到两个分支。这似乎太复杂了。您是Git新手，请保持简单。只需从主节点分支并合并回主节点。这将生成具有所需“特征气泡”的图形

现在，只有一种合并功能的顺序

此工作流中不需要登台。在合并回主功能之前，可以直接从功能分支对单个更改进行QA

看起来是这样的

git获取来源；git签出-b功能/1234源代码/主代码

处理该特性。

做出改变

运行开发测试

            - - - - - 5 - - - - 6 - 7 [staging]
           /         /         /  /
          /         / E - F - G -+-
         /         / /          /  \
        | Z - Y - X /  J - K - L    \
        |/         \|/          \    \
1 - 2 - 3 - - - - - 4 - - - - - - 8 - 9 [master]

          Z - Y - X   J - K - L
         /         \ /         \
1 - 2 - 3 - - - - - 4 - - - - - 8 - 9 [master]
                     \             /
                      E - F - G - -