问题描述
这是场景。当我的团队成员开始处理某个功能时,我们会从 master
分支创建一个 feature
分支。然后我们经常(至少每隔几天)将 master
合并到 feature
以使其保持最新状态。功能完成后,我们会进行代码审查并进行必要的更改,然后将 feature
合并到 master
。代码审查过程是:将 master
合并到 feature
以确保它是最新的,然后 diff master feature
查看可以很好地审查的整套功能代码更改。
上述方法运行良好,但需要在将 feature
合并到 master
之前完成整个代码审查过程。不幸的是,项目时间表有时要求我们在实施后立即将 feature
合并到 master
,以便测试团队可以开始测试它,并且我们必须在其之后进行代码审查被合并到master。这种与 master
的预审合并有时会在功能的各个部分完成时发生多次。
以下是事件时间表示例:
- 从
feature
分行master
。 - 对
feature
进行更改。 - 将
master
合并到feature
以使其保持最新状态。 - 对
feature
进行更多更改。 - 将
feature
合并到master
以便进行测试。 - 对
feature
进行更多更改。 - 将
master
合并到功能中以使其保持最新状态。 - 将
feature
合并到master
以便进行测试。 -
feature
现已准备好进行代码审查。
我的问题是:如何审核feature
?具体来说,我如何隔离在 feature
上引入的所有代码更改的逐行“差异”(但现在也存在于 master
中)而不会看到更改在别处引入的(但现在也存在于 feature
中)?在 master
和 feature
之间双向发生了多次合并。
这可能吗?
解决方法
不幸的是,项目时间表有时要求我们在功能实施后立即将其合并到母版,以便测试团队可以开始对其进行测试,
您git checkout -b test-feature-as-of-x master; git merge feature
和您的测试团队能否在不使用将被拒绝的代码污染 test-feature-as-of-x
历史记录的情况下使用 master
吗?
Anyhoo,要从上游找到最旧的合并基础,
oldest-base() {
( git rev-list --first-parent $1; git rev-list --first-parent $2 ) \
| awk 'seen[$1]++ { print;exit }'
}
然后 oldest-base feature master
查找原始主提交功能的分支。要查看 feature
中的所有更改,而没有 master
的东西妨碍您
git checkout -b review `oldest-base feature master`
git cherry-pick -n --first-parent --no-merges ..feature
这将只引入功能第一父提交,从 master 中剥离所有合并。
,在您将功能合并到 master 的那一刻,您无法将更改与一个或另一个分支分开。如果你不将特征合并到master,这样做的方法是:
git diff master...feature # notice 3 dots
我说:如果你不将特征合并到主文件中。将 master 合并到 feature 没问题,diff 有效。