GitHub ProTips-来自Sarah Vehicles的提示、技巧、黑客和秘密

这篇帖子是GitHubbers关于提高生产力、效率等的ProTips系列的一部分。继续阅读，了解莎拉·弗弗斯的建议。

我每天的大部分工作时间都花在编写代码和拉请求上。我喜欢构建东西，我喜欢你们都使用它们，所以我非常有动力将我的更改带到那里！我想和你们分享一个对我很有效的过程。

有时，我的拉取请求太大，无法轻松查看，因为我的分支相对于基本分支包含了太多更改。我更喜欢打开较小的请求，而不是强迫我的团队费力地通过一千行代码，同时试图让他们记住所有事情并发现任何问题。较小的Pull请求往往合并得更快，因为它们更容易推理，因此审查者可以轻而易举地通过并充满信心地批准，而且因为它们与基本分支冲突的机会较小。

然而，我的大脑不会考虑小的拉动请求！我有了一个想法，我想在它溜走之前将我的想法转换成代码-在我的编辑器中以黑绿色显示出来。能够将我的特性或错误修复记录在单个分支中，这有助于我确认它是否如我预期的那样工作，并允许我测试整个系统。我可以根据使用该数据模型的UI和端点是如何组合在一起的，来验证我选择的数据模型是否是一个好的数据模型。不幸的是，这种“一个分支中的一切”的方法与我希望向我的队友提供小的、容易审查的拉请求的愿望不一致，特别是在这些分支往往会变大的情况下。

如果我试图从一开始就将我的代码拆分成单独的分支，我常常很难知道哪些代码在哪个分支中是有意义的。我发现自己花了太多的时间考虑我是否将承诺放在了正确的分支上，而不是考虑我正在构建的功能。我感觉它也阻碍了编码的创造性过程，不得不担心将代码整齐地划分为连贯的、易于审查的分支，而不是仅仅跟随功能开发的方向。

我通过同时做这两种方法来协调这两种方法，但要按顺序进行：在单个分支中完成我最初的工作，而不是担心它会变得多大，然后再开设新的分支来梳理出可以单独完成的更小的原子工作。我可以使用Git Cherry-Pick将我的大分支中的一些部分拉到一个非常集中的小分支中，然后从那个小分支打开一个拉回我的存储库的默认分支的请求。随着每个较小的分支被合并，当我使用基分支中的最新代码更新我原来的大分支时，diff会变得越来越小，因为它的更多更改现在已经在基分支中了。我可以根据需要重复这个过程多次，直到原来的大分支不再那么大，以至于复查起来很痛苦。

假设我想在博客中实现分类。这可能需要：用于添加新表和字段的数据库更改、用于在数据库适配器级别验证数据的逻辑、用于支持读/写/删除类别的新端点、允许您访问这些新端点的用户界面更改，最后是用于改善用户体验的JavaScript。我实现这样一个特性的方法是创建一个类似Add-Categories的分支，并在该分支中获取所有内容。我会添加足够的测试来确认我的方法正在做我期望它们做的事情，并通过在浏览器中签出来手动验证其他所有内容。分支的目的是作为一种尖峰，一个测试平台，用来验证我的实现是否正确。我可以为这个分支打开一个拉式请求，不是请求审查，也不是要合并，而是让我的团队自己尝试，看看我正在考虑的整体方法。

一旦我对Add-Categories分支感到满意，我将返回到存储库的默认分支并启动一个新分支。我试着考虑在我的功能分支的任何部分落地之前必须发生的最低级别、最早的更改。在本例中，是数据库更改。没有这些，端点、UI和JavaScript就无关紧要了！

我会打开一个类似CATEGORY-db的分支，并将所有相关工作从Add-Categories拉到其中。理想情况下，当我一直在处理添加类别时，我会进行原子提交，这样我就可以运行git挑剔命令来停止数据库更改。然而，情况并不总是如此，对于那些时候，我倾向于在gihub上打开我的添加类别拉取请求，然后转到“Files Changed”选项卡，在那里我可以很容易地将文本和文件块复制到ategory-db中的新提交中。

将更改拉到完全专用于该更改的分支中有一个很好的副作用，那就是它会带来更好的测试覆盖率。如果我试图登陆我原来的Add-Categories分支，我需要确保它对数据库验证、端点、用户界面和JavaScript功能进行了良好的测试。我经常得到的测试代码大小至少是测试代码的两倍，所以测试真的会增加拉请求的大小！我不想要那种“这个测试真的值得增加吗，它会让差异变得更大”的精神压力，当我知道整个分支非常专注，不包含完全不同的想法时，那种内部斗争就会消失。

我把我较小的分支机构视为将由我的团队彻底审查的分支机构，因此它们得到了很多润色。全面的拉取请求描述、测试覆盖范围以及对性能和用户体验的考虑非常重要。在本例中，我最初的Add-Categories分支将作为一个草案拉入请求开始，并保持这种状态，直到我完成了从中筛选出的所有较小分支的登陆。一旦Add-Categories足够小，因为它的足够部分已经落在不同的分支中，我将完成它的测试，更新Pull请求描述以反映分支的剩余内容，最后删除它的Draft状态，这样我的团队就会被ping以供审查。

有时，以菊花链形式连接我的拉取请求会很有帮助。在创建CATEGORY-db分支之后，我想看看还没有在CATEGORY-db中的Add-Categories中还有哪些更改。查看原来的大分支中剩下的内容将让我决定它是否足够小，可以提交给代码审查，或者是否需要从它中取出另一个小分支。要查看剩余的更改，我将编辑GitHub上的添加类别拉取请求，将其基本分支从存储库的默认分支更改为CATEGORY-db。然后，在将结果推送到gihub之前，我可以检查add-ategories分支和git合并类别-db。这将更新我的Pull请求上显示的diff，以便现在在Category-db中的所有代码不再显示在add-Categories Pull请求中。

也许添加类别对我来说仍然太大，不能让我的团队进行审查。新的数据验证可能是我拉到他们自己的分支机构的下一个部分。在CATEGORY-DB上，我可以创建一个新分支，比如CATEGORY-VALIDATIONS。我会重复前面的过程，在可能的情况下挑选相关的提交，否则从Add-Categories的Pull Request视图中批量复制代码。一旦将类别验证推送到GitHub，我就可以打开一个拉取请求，将CATEGORY-db作为基础，将CATEGORY-VALIDATIONS作为头分支。然后，我可以再次更新我的添加类别拉入请求，以便它的基本分支现在是类别验证，而不是类别数据库。这导致了菊花链效应，其中我的分支是：Main←CATEGORY-db←CATEGORY-Valiations←Add-Categories。

%git branchadd-Categories//添加整个类别功能Category-db//添加数据库表*CATEGORY-VALIDATIONS//添加验证逻辑+testsmaster。

像这样链接拉取请求的另一个好处是它解除了我的阻碍。也许Category-db还不能合并，因为它描述的数据库更改还没有发生，所以我的其他分支也不能合并。通过为单独的小分支机构打开许多拉式请求，我仍然可以专注于让我的团队对每个分支机构进行全面的测试和审查。通过确保测试通过并得到批准，我可以准备好要合并的每组更改，然后当Category-db准备好合并时，我将能够在短时间内获得几个分支，因为依赖于Category-db的分支已经通过了审查过程。

一旦我的一个较小的分支被合并，我就可以更新基于它的拉取请求，而不是基于我的存储库的默认分支。因此，当我的CATEGORY-DB分支被合并时，我更新了CATEGORY-VALIDATIONS PULL请求，使其基本分支成为主要分支。最终，所有较小的分支都合并了，我剩下的只有一个拉取请求，也就是基于默认分支的原始Add-Categories请求。只是这一次，Add-Categories是一个合理的大小，我可以要求我的团队进行审查。至此，Add-Categories可能已经更改

通过让我自己专注于用代码表达我的想法，而不是关注如何整洁地组织我的分支的具体细节，我能够更快地开发特性。通过稍后将一个大的特性分支拆分成许多较小的分支，我帮助我的团队确保我们正在合并经过良好审查的代码，并且我能够单独关注每个部分，以确保它经过了充分的测试。通过使用Git的分支和GitHub的Pull请求，我能够将这两种技术结合起来，有望改进为我和我的团队构建特性的过程。

你在GitHub上有没有让你的日常生活更轻松的小贴士、小窍门或小窍门？请使用#GitHubProTips在社交媒体上与我们分享。