Question

我们为每张门票创建新分支。票证完成后，分支将合并为主节点。每个故障单分支通常都有几个提交。

为了便于阅读和测试，我尝试创建以下提交：

是原子
只关注一个主题
不破解决议

有时我事先知道我打算在分支中做什么提交。例如：

为访客注册创建后端api
重构访客分类功能
为访客注册创建前端
创建简单的访客注册确认页面

但是我经常发现一个机会来改进主题应该属于之前的提交。继续上面的例子，我可能发现在提交2中，当我认为“访问者”是一个更好的名字时，我将变量重命名为“v”。

现在我选择两个选项中的一个，我认为这两个选项都很糟糕： - 我创建了一个提交5，它改变了我在提交2中已经改变的东西，但是做得更好一点。我认为这个选项很糟糕，因为混淆了测试和项目历史可读性。 - 我重置提交2-4并重做它们，现在将我在后见之明中实现的改进插入到它所属的提交2中。我认为这个提交很糟糕，因为这需要时间。

我认为第二种选择会产生更好的提交历史，但需要时间。

这导致了我的问题：是否有更快的方法将此更改移至提交2？

我正在梦想一个类似于Webstorm中的diff接口的界面（我可以点击更改来包含它们或还原它们），但这也让我选择我想要设置更改的提交。

有什么解决方案？

Answer 1

您可以使用这些算法（使用rebase激活）：

从第二次提交开始创建其他分支并切换到新分支
将第五个提交添加到此分支
应用来自初始分支（第三和第四次提交）的更改
压制第二次和第五次提交

更详细地说明下面描述的算法

我们假设我们有这样的git log输出：

git log --pretty=format:"%h %s" --graph
* 43e94d8 fourth commit
* 8bfc119 third commit
* d5c9a25 second commit
* e17b227 first commit

然后我们从第二次提交创建新的分支：

git branch feature-to-change d5c9a25
git checkout feature-to-change

然后创建第五个提交到功能更改分支并在其上应用第三个和第四个提交：

# create and commit fifth commit
git log --pretty=format:"%h %s" --grap
* 86660c9 fifth commit
* d5c9a25 second commit
* e17b227 first commit

git rebase feature-to-change feature

git log --pretty=format:"%h %s" --graph
* ee0a502 fourth commit
* 2e0e2c6 third commit
* 86660c9 fifth commit
* d5c9a25 second commit
* e17b227 first commit

现在我们按照适当的顺序进行提交，但我们需要压缩第二次和第五次提交

git rebase -i HEAD~4

  pick d5c9a25 second commit
  squash 86660c9 fifth commit
  pick 2e0e2c6 third commit
  pick ee0a502 fourth commit

挤压后你会得到这段历史

git log --pretty=format:"%h %s" --graph
* 758d85c fourth commit
* 3761310 third commit
* ee739dd second commit
* e17b227 first commit

这些步骤不会花费很多时间，最后你会得到具有漂亮提交历史的分支feature-to-change

在提交之间移动更改，以获得干净的分支？

1 个答案: