2

在尝试坚持 [ http://nvie.com/posts/a-successful-git-branching-model 的分支模型 ，即使用功能分支并将它们合并回开发分支时，我有时会遇到以下情况：

功能base（既是功能分支又是 Python 包）被认为是完整的并合并到develop. stuff现在，需要的功能 (=branch&package)base被分支出来，在开发时我意识到stuff需要一些修改/增强，base从一开始就应该存在。那么我应该在哪个分支修改包base？

  • 在分支中这样做stuff似乎是错误的，因为无论何时（以及是否）合并回来，base都应该成为修改的一部分。devstuff
  • （重新）分支到base，修改，合并到两者develop，stuff另一方面会创建许多合并，我不确定合并到功能分支是否是一种好习惯。特别是如果它只是一个小而重要的修改
  • 并且提交两次（通过git cherry-pick）也感觉不对。
  • base变成一个git submodule听起来有点矫枉过正的声音
  • 重新定位stuff到更新develop将使历史看起来更好，但如果其他人拉出原始分支会导致常见问题stuff- 在我的单开发人员案例中不是问题，但这个问题的可能性表明我正在做一些更根本错误的事情。 ..
4

1 回答 1

0

根据https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html的“规则：主题分支”，建议似乎是

  • 如果您发现需要其他分支的新功能才能继续处理您的主题，请将其他内容合并到主题。（但是，不要“只是习惯性地”这样做，见下文。）

“下面”的意思是

规则：仅在明确定义的点合并到下游

除非有充分的理由，否则不要合并到下游：上游 API 更改会影响您的分支；您的分支不再干净地合并到上游；等等

否则，合并到的主题突然包含多个（分离良好的）更改。许多由此产生的小合并将极大地混淆历史。以后调查文件历史的任何人都必须查明该合并是否影响了开发中的主题。上游甚至可能无意中被合并到一个“更稳定”的分支中。等等。

总而言之，这意味着“如果有必要就合并到base，但永远不要合并到（因为它可能包含与 无关的其他功能）”stuff developstuffstuff

于 2013-05-28T13:20:17.063 回答