git可以提示我rebase上的每个文件吗？答案

【问题标题】：Can git prompt me for each file on rebase?git可以提示我rebase上的每个文件吗？
【发布时间】：2016-03-29 16:50:13
【问题描述】：

我最近在一个网络项目中遇到了这个问题：

git branch new-feature
git checkout new-feature

hack hack hack...

“老板：嘿，master 有一个 bug 需要修复，马上！”

git commit -a -m "Partially completed migration changes"
git checkout master
git branch bugfix
git checkout bugfix

hack hack hack... 测试测试测试...

“好的，解决了！”

git checkout master
git merge bugfix

继续完成功能，但我们不要重新引入错误...

git checkout new-feature
git rebase master

First, rewinding head to replay your work on top of it...
Applying: some commit info
Using index info to reconstruct a base tree...
...
Auto-merging /some/buggy/file
CONFLICT (content): /some/buggy/file
Auto-merging /some/buggy/file
CONFLICT (content): /some/buggy/file2
Auto-merging /some/buggy/file
CONFLICT (content): /some/buggy/file3
...

如果我碰巧知道特定文件与新功能无关，我如何以交互方式强制文件从变基源复制？

有没有办法告诉git 提示我：

copy /some/buggy/file master? y/n
copy /some/buggy/file2 master? y/n
...

【问题讨论】：

标签： git merge projects

【解决方案1】：

Rebase 由重复的 git cherry-pick 操作组成（或者在某些情况下是一个单一的整体选择，但这相当于同一件事）：它采用你的 rebase 规范（基本上是 <upstream>..HEAD）选择的所有提交并复制那些在 --onto 参数（默认为 <upstream> 参数的尖端）上增长的新链的新提交。

挑选樱桃需要稍微改变视角：rebase 首先在 --onto 点检查一个匿名（分离的 HEAD）分支，然后遍历它之前从 @987654328 保存的提交 ID @ 在它分离 HEAD 之前。正是这些精选步骤导致了合并冲突（这就是为什么您经常必须反复解决合并冲突，每次精选提交一次）。

这意味着要回答您的问题，除了git rebase 文档之外，我们可能还需要查看the git cherry-pick documentation。在那里，我们发现：

当不明确如何应用更改时，会发生以下情况：

当前分支和HEAD 指针停留在最后一次成功提交。

CHERRY_PICK_HEAD 引用设置为指向引入了难以应用的更改的提交。

这意味着在这种状态下，我们可以使用git checkout HEAD -- path/to/file（这里实际上不需要--，而是a good habit）或git checkout CHERRY_PICK_HEAD -- path/to/file。

因为我们现在是在挑选，而不是变基（变基仍在继续，此时我们只是在樱桃挑选阶段） , HEAD 指的是最近一次成功的提交。如果冲突发生在第一次提交，HEAD 在您的特定示例中指的是与master 相同的提交，而CHERRY_PICK_HEAD 指的是从原始new-feature 分支复制的提交。如果冲突更进一步，HEAD 指的是从（再次使用您的示例）master 通往未来的匿名分支上增长的新提交之一。无论哪种情况，这都是您真正想要的，在这里。

（旁注：如果你知道你没有接触过文件，那么在这种情况下，CHERRY_PICK_HEAD 提交和 master 提交都是一样的, 所以你可以改用git checkout master -- path/to/file，这样更容易输入。但是，这假设你是基于master的尖端，而使用名称CHERRY_PICK_HEAD使它独立于目标提交。）

一旦完成挑选阶段，git rebase 将再次接管并通过更改 rebase 分支名称（在本例中为 new-feature）来完成 rebase，以指向新匿名分支上最尖端的提交.旧的（预变基）分支提示，在所有这些樱桃采摘之前，仍保留在 new-feature 的引用日志中（如 new-feature@{1} 或任何其他命名方式）。此时它也可以在ORIG_HEAD 中使用，直到您运行覆盖ORIG_HEAD 的内容（各种git 命令，包括git am、git merge 和git reset，也写入ORIG_HEAD）。如果您不小心搞砸了 rebase，这将特别方便。

【讨论】：