Git
英文原文：
Refactoring Git Branches
TL/DR （太长，请勿阅读）
本文中描述了允许一个人从一个较大的git分支中提取commit到独立的版本。“git版本重构（git branch refactoring）”提供了许多好处：
特性分支包含许多不同的变更
当代码类或方法中的操作太多时，我们可以通过提取部分的功能到单独的类或方法来重构。这同样适用于Git的特性分支。理想情况是一个Git特性分支应该并且只执行一个特定的变更，可以是一个bug的修复，一个重构或添加一个新功能。
然而，我们都知道，即便添加后续很酷的功能到代码库，在前进的道路上仍有许多有待提高的代码。因此，本着持续改进和持续改善的精神，或仅仅是因为我们需要 改善境况，这样我们才可能继续开发新特性，我们
作为该处理的结果，许多特性分支最终看起来像下面描述的（时间从下向上流动，即新的提交都被添加在上面）：
我们的特性分支称为kg_feature_1，它是从development分支中剪出来的（在这里我们按照NVIE模型的术语），在这是它是我们的主分支并与所有开发者共享。到目前为止这个development分支中只包含框架。我们的特性分支包含了特性本身的一些提交（feature 1 – feature 4），一个外部代码模块的bug修复（“bug fix 1”），以及一个在两个不同步骤间的更通用的重构（“refactoring 1a“和”refactoring 1b“）。
其它翻译版本 (1)
加载中
代码更改应该进行独立的评审
我们不想仅仅发送这样一个多头怪般的特性作为一个单一代码的评价。它包含太多不同的东西了！这会使得审查者难以获知我们究竟在干什么。同样的，在同一时刻的不同事情，我们也无法进行有意义的交流。这不仅仅是一个代码混乱，认知压力和遗漏重要细节，也会减少读代码的乐趣和动力。
我们也希望审查和整合的bug修复以及代码重构到开发分支走向正途，以便当我们做出修改后其他开发人员可以适时的将其纳入到自己的工作中。如果我们等待直到整个功能完成，那就为时晚矣，我们不得不忙于处理代码合并时的冲突，其工作量将远远超出其必须的。
不同部分的代码中这些不同类型的变化很可能是由不同的人审核的。那些很重要的模块中的bug修复是由开发人员或者维护人员审核的，通过开发人员或者技术人员引导重构，而特性是由另外的小组成员负责。
让我们来重构我们的Git 分支！
提取提交进专用的分支
把那些很紧急的变更整合到开发在这里就是重构，因为那些正在工作的人可能碰到那些代码。让我们把它提取进单独的分枝。
# Cut a new branch for the refactoring off the development branch.
$ git checkout -b kg_refactoring development
# Move the refactoring commits into the "kg_refactoring" branch.
$ git cherry-pick [SHA1 of the "refactoring 1a" commit]
$ git cherry-pick [SHA1 of the "refactoring 1b" commit]
我们的 kg_refactoring 分支现在就如同这样：
它仅仅包括了所有的重构提交。完美极了！现在我们可以把这个分支放进Git报告,通过开发人员或者
技术人员引导审查，并把它整合到开发分支。
一旦这一步完成了，我们重新定位特性分支的起点，来带上在 development 分支里最近发生的改变，例如我们提取的重构。反正我们也要经常这样做，因为这是一个好习惯，可以保持特性分支与正在进行的开发同步，并且一旦发生 merge 冲突就能及时解决，而不是等分支完成再解决。
$ git checkout kg_feature_1
$ git rebase development
如果你对 Git 有所了解，你就会知道我们的分支情况现在是这个样子：
看起来已经好多了。现在，重构是 development 分支的一部分，而我们的特性分支仍然能访问并利用重构的成果！
特性分支里，唯一被遗落在外的部分就是bug修复了。我们用同样的方法提取它，完成之后分支情况成为下面这样：
bug 修复和重构的部分都分别被重审过，并且 merge 到 development 分支中了，与正在进行的特性开发分开。重构后的特性分支只包含特性方面的提交，并且现在就可以重审，或者再开发一段以后进行。如果做了更多的 bug 修复和重构，可以根据需要重复这个过程。
什么时候要这样做
把独立自主的更改提取到它们自己的特性分支里，可以显著改善分支的结果，增强代码重审的效果，提高工作流的效率。然而，要想顺利进行，还需保证以下几点：
每次提交都有良好的描述，并且只包含了单个改动（无论是特性，bug 修复，重构等等）
你可以重新定特性分支的起点。但前提是这个特性分支只有你一个人在用！如果还不确定为何如此，读一读 Linus Torvalds的解释。在本例中，我们把分支标为私有了，方法是用自己的缩写作为分支命名的前缀：根据我们团队的规则，这就说明是私有的。
你拥有足够的规范，尤其是特性规范（也就是集成测试）来验证在分支重构后，是否一切都正常工作。
反正，这些都是好的日常工程习惯。所以有机会试一试吧，有想法可以在此评论！
本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。
2KB翻译工作遵照
CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。
2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务
