我有一个功能分支，它不断发展壮大，随着功能的发展经历了很多曲折。我想将一些可单独发布的块分解为它们自己的分支。
提交不够干净，无法通过提交选择来构建这样的分支(即一些提交涉及多个文件，只有其中一些我想选择)。我是交互式 rebase 、大块编辑等方面的灵巧手，但我想知道是否有更好的方法来做到这一点？
我最初的想法是创建一个分支，它是原始功能分支的副本，将它的所有提交压缩为 1，重置为之前的提交(在我的工作树中留下完整的未提交、未暂存的功能分支)，然后有选择地添加并提交我想要的碎片。
$ git co -b partial-feature
$ git rebase -i HEAD~170
在编辑器中:
pick 234e78fa Begin writing feature
f 7844c437 Add more stuff
f 3523437 And even more
...
然后，
$ git reset HEAD~
$ git add first_good_change.rb
$ git commit -m 'Add a good change'
$ git add second_good_change.rb
$ git commit -m 'Add another good change'
...
有没有更聪明的方法？
最佳答案
这基本上很好，但它可以更简单一些。
这相当于软复位到分支的开始。这是一个单一的命令，而不是一个rebase，然后是一个reset。
git checkout -b partial-feature
git reset start
其中
start 是您希望分支开始的 SHA1。这决定与
HEAD~170 不同，因为您不需要计算 170，只需查看 git log 并找到合适的 SHA1。在此之后，继续像你一样:
git add first_good_change.rb
git commit -m 'Add a good change'
git add second_good_change.rb
git commit -m 'Add another good change'
等等。在任何时候，如果你愿意，你可以在另一个功能分支上继续，一点一点地向审阅者释放变化，使他们的工作更容易，例如:
git checkout -b partial-feature-round-2
git add more_good_change.rb
git commit -m 'Add a good change'
git add even_more_good_change.rb
git commit -m 'Add another good change'
等等。在
partial-feature-round-2 merge 之前，请确保不要发布 partial-feature 以供审核。提交原始分支的所有内容后，
项目的内容将与原始分支相同，
只是历史会有所不同。
像这样对历史进行切片和切块是完全正常的。
以这种方式将分支拆分为较小的分支并不总是可行的，
例如，当更改过于相互关联以至于很难将其分离为仍然有效的块时。
也就是说，当你发布
partial-feature 进行代码审查时，它最好编译并完全工作，
如果更改太复杂，这可能很难实现。
最后提示:在为多阶段代码审查构建部分分支时，
验证部分功能是否仍然有效并处于代码可审查状态的一种简单方法是 stash 剩余的更改，并编译和运行测试。如果一切顺利，分支已准备好进行代码审查，您可以创建 pull 请求，然后继续下一阶段， pop 存储并添加更多提交。
关于Git:将一个大+凌乱的功能分支分解成更小的分支，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/40873354/