背景:
GitHub属于客户端。我们团队中有一些新手,有时会错过基本的命名规范和其他编码协议。因此,如果任何资深人员想要进行内部审核,除了创建PR之外没有其他办法。但是,这个PR会对客户可见。
问题:是否有可能使用工具(最好是GitHub提供的功能)进行内部审核,然后创建一个干净漂亮的PR呢?
我理解PR本身就是为了进行审核,但至少经过内部审核后,它将具有真正需要关注的问题,而不是一些微不足道/明显的问题。
背景:
GitHub属于客户端。我们团队中有一些新手,有时会错过基本的命名规范和其他编码协议。因此,如果任何资深人员想要进行内部审核,除了创建PR之外没有其他办法。但是,这个PR会对客户可见。
问题:是否有可能使用工具(最好是GitHub提供的功能)进行内部审核,然后创建一个干净漂亮的PR呢?
我理解PR本身就是为了进行审核,但至少经过内部审核后,它将具有真正需要关注的问题,而不是一些微不足道/明显的问题。
dev1
),该分支从未推送到远程(GitHub),还可以创建一个开发分支(我们称其为dev2
),该分支被推送以创建PR。dev1
。dev1
到dev2
之前,会比较dev1
和dev2
,而不是使用PR进行审核。dev1
和dev2
(或类似的名称)会创建一个两步流程,并且不会让任何人觉得自己像孩子。dev1
显示在最终合并到dev2
(并推送到GitHub)的历史记录中,则可以在满意dev1
的外观后,使用“git reset squashing”:Git书中这一页的“Squashing”段落给出了一个很好的例子。dev1
和dev2
之间的最后一个公共提交):git reset --soft <hash>
然后你运行:
git commit
dev1
和dev2
的最后一个公共提交点直接跳转回到你对dev1
满意的最终状态,"压缩"所有中间混乱的提交。
在这个工作流程中,您可以在审查dev1
时进行并排比较(通过将其与dev2
进行差异比较),隐藏其开发过程中发生的所有问题(只有在使用git reset
创建了干净的历史记录之后,才将dev1
合并到dev2
),然后将dev2
推送到GitHub以创建PR。