Question

从概念上讲：我有一个 master 分支，称为'core'。

此分支将永远存在。

核心每周需要获取对 master 所做的所有更改。

每月在核心中进行的更改需要重新推送到 master 。

核心有时有时会具有一个或两个月的分支，例如 feature1 或 feature2 ，然后将它们合并为核心，功能分支将被删除，然后核心将在月末将这些更改推送到主。

我可以使用rebase或merge进行此操作，也可以在每个月合并到 master 后创建一个新的 core 分支。

我认为做到这一点的最佳方法是每周和每月只使用“合并”，但是我对github并不了解，所以这是正确的方法吗？或者您预见到将来会出现任何问题？

          week1    week2     month end
--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o master
  \        \         \         / \
   o--o--o--o--o--o--o--o--o--o---o--o--o--o core
          \              \             /
           o--o--o--o--o--o--o--o--o--o      feature

master由一个大团队工作，核心团队很小，一个功能通常是一个人（尽管仍然被推送到github进行测试或演示功能），核心团队和主人团队通常不会碰到相同的文件。

Answer 1

您建议的工作流程有点类似于Git flow（另请参阅this cheatsheet）。

关于您的合并与重新基准问题，应该注意，git rebase是一种破坏性操作（不仅会更改重新基准提交的SHA1，而且每个代码的代码库都有可能源分支中的commit确实可以编译，而其中的一些或全部这些提交在重新设置基准后就不再编译了！）。相反，git merge将保留两个处于危险中的分支的所有提交，并创建合并提交，如果需要，可以合并冲突解决方案更改。

git rebase的这种“缺点”可能是在实践中始终使用git merge来实现Git流的原因（实际上是git merge --no-ff，请参见相应的doc ）。

但是，有些团队可能会选择不同的工作流来将贡献集成到master中，因此，只要要素分支与master之间存在某些冲突，就需要使用git rebase origin/master（为了获得更“美丽”的线性历史记录）。尽管如此，在这种情况下，还是建议检查每个重新基于基础的提交仍在编译中（以免阻碍bisecting）。

为持久分支合并，变基还是分支？

1 个答案: