我们的团队采用了共同的公关策略，即在合并到主分支之前审核每个功能分支代码。我们还采用了在主分支中频繁合并的策略，以避免在分支完成后发生巨大冲突。
这一点运作良好，但我们面临的问题是需要更长时间才能构建的分支机构。我正在查看代码审查一个花了几周时间构建的分支。 PR中有超过100个文件超过100个提交。现在，实际的功能可能只有大约15％，其余的只是与主分支合并。
有没有什么方法可以缩小它，只关注这个分支中的新代码，而不是必须筛选100个实际上已被代码审查并合并到主分支的代码行？
答案 0 :(得分：0)
我对此案的建议是rebase。您经常会在开源存储库中看到这一点，您的功能分支可能已经与主分支过时了。
这意味着您需要回滚分支历史记录，将其设置为您重新登录的当前分支的提示，然后再次重新应用您的唯一更改，以便所有内容都是最新的。
警告：修复合并冲突可能会导致长时间运行的分支混乱，因为您需要通过功能分支的成熟度来修复各个阶段的冲突 - 通常您会忘记自己所做的事情！
您还可以将主分支合并到功能分支中，该功能分支将应用更改的更改。我不喜欢这种方法，因为它会将您的更改隐藏在与您的功能无关的代码之下，但更容易以这种方式修复冲突，因为您执行此操作时代码处于“已完成”状态。
答案 1 :(得分：0)
您不与featurebranch base进行比较，而是与未来merge的mergebase进行比较，这是合并的最后一次master提交。这样，您只能看到功能分支中的内容。
你可以在不查找提交的情况下通过调用git diff master...feature（注意那里有3个点）来做到这一点
请参阅man git-diff