【发布时间】:2017-03-14 20:39:23
【问题描述】:
我知道有很多类似的问题,但我找不到一个好的答案来帮助我在我工作的公司提出一个好的解决方案。我们的开发人员不多,但我想提出一个可扩展的工作流程。
(并非如此)假设情况
这种情况是最常见的:有一个master 分支从不接收直接提交。如果我需要做某事,我会创建一个feature/personal 分支(通常使用长寿命的个人分支比使用胖特性分支更频繁)。
一旦我对我创建的代码感到满意,我想把它带回master(与此同时,它已经收到了另一个提交)。
重要的是要指出master 和branchX 总是被推送到远程。
所以,为了以图形方式澄清它,我们处于这种情况(我将使用 C 进行提交,M 用于合并):
branch1 C2---C3---C6---C9---
/
master C0---C1---C4---C5---C7---C8
当前工作流程
可以定义当前使用的工作流程merge-up/merge-down:由于我不想修复master中的合并冲突,首先我merge-up master 在 branch1 中,然后我 合并 branch1 在 master 中。
branch1 C2---C3---C6---C9---M1
/ /\
master C0---C1---C4---C5---C7---C8 M2
这样做,我解决了分支内部的冲突,然后我可以将我的分支合并到 master。
我个人不喜欢这个解决方案,主要原因有两个:
- 它会导致一棵非常混乱的历史树
- 将父分支合并到子分支听起来对我来说毫无意义
另一方面,我的同事认为:
- 这很容易理解,即使对于非专业实习同事也是如此
- 由于您未触及历史记录,因此导致错误更少(与变基不同)
建议的解决方案
我提出的是通用且更直接的 rebase-before-merge-down 工作流程。
一旦我想将branch1 合并到master 中,首先我rebase 前者基于后者,所以我处理了我分支中的所有冲突;比我 合并 branch1 到 master (如果功能分支有意义则使用 NO-FF,否则使用 FF)
branch1 C2---C3---C6
rebase / \
master C5---C7---C8 M1
然而,这个解决方案有一个主要缺点:
由于两者都与遥控器同步,因此需要
git push --force。因此,如果某人做错了事(因为他匆忙、分心或愚蠢),数周的工作可能会在一秒钟内浪费掉。
另一方面,优点应该是:
- 保持历史树非常干净和有意义
- 展平并移除无用的分支,只保留相关的分支
那么,这个问题?
在您的大型团队中,您采用哪种可扩展的工作流程来保持 git 历史记录的整洁和有意义,另一方面,防止像错误的 git push --force 那样的潜在灾难?
【问题讨论】:
-
你得到了帮助你解决问题的答案吗?如果是,请标记它。它将帮助其他有类似问题的人。
-
你说得对,我上周真的很忙,没有找到合适的时间来回答和标记解决方案:)
标签: git version-control merge workflow rebase