Git工作流：重定已发布/共享分支的基址

我们的团队在工作中热情地采用了一个重基工作流，但我们可能会有点得意忘形，这就是问题的关键：你是评判者

使用pull——rebase现在对我来说是一件不需要动脑筋的事。但是，我们也有多人参与的大型功能分支。我们希望周期性地引入主机上正在发生的更改。传统智慧会让我们合并，因为这是一个共同的分支。然而，在我们对重设基础的痴迷中，我们决定重设这些分支的基础。当然，这需要所有人的合作。工作流程如下所示：

1） 钢筋与每个人协调，以确保他们都已检入并推送到特征分支上，然后要求他们在获得全部清除之前不再对该分支进行任何工作

2） 重定基准将要素分支重定基准到主要素上，删除远程要素分支（git push origin:feature），然后推送新的重定基准要素分支（git push origin feature）

3） Rebase让everyone fetch更新其特征分支，然后删除其本地特征分支（git branch-D feature），然后创建跟踪远程特征分支的新本地特征分支。然后，所有人都得到了所有的清除

这个工作流程正在运行，部分原因是我们是一个小组，工作中断很小。然而，我担心我们正在学习糟糕的Git习惯（重新设置共享分支的基址），或者工作流无法很好地扩展

从好的方面看，我们的存储库历史是美好的

你觉得呢，Git大师？我们是在玩火，还是在玩弄合理的工作流程

更新：

自从我最初问这个问题已经两年了，我的工作流程也随之改变。我们仍然照例执行git pull--rebase，所以这一点没有改变。这是常识，它可以防止所有难看、混乱的迷你合并。（我们基本上保持同步，所以git拉取的成本很低——重新基址）

然而，除此之外，还有偶尔纠正错误的英雄行为，我们已经克服了我们的再基础疯狂。大多数情况下，合并是有意义的。然而，肆意的合并是有问题的，而且确实导致了我两年前所担心的混乱的历史

我们的解决方案有几个组成部分：

• 主分支是“原始的”。主题分支被合并，一旦合并，主题分支就失效。换句话说，在中合并主题分支意味着该工作已准备好进行生产，并且现在是主分支的一部分。看看我们的版本历史，很清楚发生了什么：主题分支合并到master中，就是这样

• 必要时，我们使用一次性集成分支。例如，如果我们有主题分支A、B和C，但它们都没有准备好集成到master中，但我们需要一起测试它们，那么我们只需创建一个QA分支（通常在master之外），然后将A、B和C合并到。在某些情况下，QA分支会被删除或重新使用。关键是，它不打算以任何方式成为永久性的，并且它没有与主分支相同的限制（您可以根据需要多次合并主题分支）。如果历史变得太混乱，您可以删除QA分支并重新开始（我们发现这是一种非常自然的方法）

• 合并时，始终使用

  git-merge--no-ff

  。这与两年前我们对“线性提交历史”的痴迷是如此巨大的逆转，值得评论。现在我们已经放松了线性提交历史，看到了合并是好的和有用的，我们已经开始依赖主题分支作为master的实际分支，而不仅仅是一系列最终成为master的提交

  git-merge--no-ff

  确保始终存在合并提交，即使它不是必需的

• 我们对提交消息和分支有一个众所周知的约定，更重要的是，它交叉引用了我们的问题跟踪系统。我们的问题跟踪系统使用数字问题编号，对于任何功能（或缺陷），我们都有一个问题编号（例如1234）。如果您正在处理该问题，您将创建一个分支

  \u 1234

  ，并使用

  “\u 1234:do blah blah”

  启动每个提交消息。这可能看起来有点强迫，但它确实对我们很有效，并显著减少/消除了困惑

• 使用git包装器来鼓励工作流粘附。这是我们目前正在进行的工作，但我们已经意识到这是完全必要的，以防止简单和可理解的错误，如分支错误的事情（我们最近遭遇了一场彻底的灾难，一位开发人员在一次性QA分支的基础上创建了一个主题分支：该主题分支被批准上线，它被合并到……而一堆未被批准上线的变更被吸进了其中）。我们的git包装器在您做一些不寻常的事情时需要确认（比如创建一个除master之外的分支，创建一个不命名为_NNNN的分支，做出一个不以_NNNN开头的提交，等等）。有时候，我们确实需要做这些事情，所以包装器不会阻止它，但它确实可以防止人们意外地做一些不应该做的事情

---

这听起来太复杂了，无法很好地扩展。只需定期将

master

合并到您的功能分支中，然后在需要合并回master时，您就可以先进行重基（删除中间不必要的合并），然后再合并回master，这可能要简单得多（大概是使用

--no ff

生成合并提交）。这只需要一个人处理重基，而且他们不必进行任何协调，因为没有其他人可以处理