使用 git 将一项更改与另一项更改隔离

Question

我一直在本地主分支上开发一项新功能，该功能尚未准备好投入生产。然而，我刚刚在我的实时应用程序中发现了一个单独的错误，所以我很快在本地修复了它。但是，我想将此错误修复推送到我的远程主分支，而不推送我一直在开发的这个新功能。我该怎么做？

Answer 1

不太严肃的答案：

通过回到过去并为您的开发使用适当的分支模型。停止在生产分支上工作并开始使用功能分支。您所描述的情况正是您应该使用分支的原因：能够将您的开发工作放在一边，检查主版本，执行错误修复并返回到您的开发分支。如果忽略分支，你就忽略了 Git 的许多优点。

更严肃的答案：

更实际的是，您可以重新排序提交，将本地主控指向您想要推送的提交，推送，然后将您的开发提交作为新分支进行检查。

如果您的提交历史记录如下所示：

A <-- (master) bug fix, you want to push this
B <-- you don't want to push this
C <-- (origin/master)

您可以使用 git rebase -i HEAD~2 重新排序最后两次提交，如下所示（只需切换编辑器中的行顺序即可） up）：

B <-- (master) you don't want to push this
A <-- bug fix
C <-- (origin/master)

记下 B 的 SHA1，您将暂时将其从 master 分支中删除。记录 SHA1 后，您可以使用 git update-ref refs/heads/master [SHA1 of A]，这会导致

A <-- (master) bug fix
C <-- (origin/master)

您现在可以 git push 进行合并A 到 origin/master 并将结果发送到 origin。

最后，要恢复您的开发工作（提交 B），请创建一个新的开发分支（您应该首先完成），指向您的 B 提交：< code>git 分支开发 [SHA1 of B]

您的存储库现在将如下所示：

B <-- (development) you don't want to push this
A <-- (master,origin/master) bug fix
C <-- where origin/master *was* before pushing

当您准备好将该开发工作合并到 master 中时，您可以：

git checkout master
git merge development

Answer 2

您得到了一些很好的答案，但有点复杂。我希望能稍微简化一下。以下假设您仅在一次提交中提交了修复，即本地 master 分支上的最后一次提交。

git branch new-feature master~1
git checkout -b bugfix
git branch -f master origin/master
git rebase --onto master new-feature

这会将新功能的工作放在名为 new-feature 的自己的分支上，将错误修复放在名为 bugfix 的自己的单独分支上，重置 master 分支以匹配您上次推送的内容，然后重新调整以从您的分支中删除新功能工作。错误修复分支。

这就是您通常希望您的分支在这一点上的看法。我是如何得到它的还不是很重要，因为将来你只需在开始开发另一个新功能之前使用 git checkout -b another-new-feature master 创建一个新分支即可或错误修复。

现在，要仅推送错误修复，只需执行以下操作：

git checkout master
git merge bugfix
git push

然后，要继续开发新功能，请执行：

git checkout new-feature

如果您想将错误修复包含在新功能分支中，请执行：

git rebase master

否则，它将在您执行新功能之前合并到其中下一次推送。当您准备好推送新功能时，只需执行与 bugfix 分支相同的合并操作，但与 new-feature 分支合并即可。

Answer 3

那么，您可以仅将想要提交的文件添加到暂存区域并将它们提交到您的分支上。然后创建另一个分支并将您不想提交的文件提交到其中。然后你只需推送修复后的分支即可。

当您提交时，它只会将文件添加到暂存区域中，以便您可以在一个分支上提交一部分工作，在另一个分支上提交另一部分工作。

如果您想在有未提交文件的情况下切换分支，可以将它们添加到暂存区域，签出其他分支，然后将暂存区域提交到该其他分支。

如果您对同一个文件进行了一些想要推送的更改和一些不想推送的更改，那么情况会变得更加复杂。

Answer 4

这里是一个完整的答案命令。我写了一个类似的问题。

它的基本原理是，将错误修复移动到单独的分支并将该分支与您的主分支和主题合并。不要修复步骤 4 中的更改，而是使用 gitcherry-pick bugFixSHA 从功能分支中删除提交。

Answer 5

1. 交互式变基并将错误修复提交移动到变更集的第一个提交
2. 创建一个指向错误修复提交的新分支
3. 将新的错误修复分支推送到远程主控

我今天没有正常的测试机器，所以语法来自记忆。如果可以的话，有人可以叫我出去。

不确定 ascii 艺术是否会起作用：

  [origin/master]  hash_0 blah
  [new_feature  ]  hash_1 feature progress: more widgets!
                   hash_2 feature progress: less widgets, what was I thinking?
                   hash_3 bug fix: fixed memory management

命令可能看起来像这样：

我假设我们正在使用分支新功能。

git rebase -i origin/master

此时，您将获得提交列表：

hash_1 feature progress: more widgets!
hash_2 feature progress: less widgets, what was I thinking?
hash_3 bug fix: fixed memory management

您将重新排序您的提交：

hash_3 bug fix: fixed memory management
hash_1 feature progress: more widgets!
hash_2 feature progress: less widgets, what was I thinking?

如果您在此处遇到错误，那么您的错误修复取决于您的新功能更改。很难就此给出建议。通常在这种情况下我只是在 origin/master 中重新创建错误修复。

  [origin/master]  hash_0 blah
  [new_feature  ]  hash_3 bug fix: fixed memory management
                   hash_1 feature progress: more widgets!
                   hash_2 feature progress: less widgets, what was I thinking?

我们应该按正确的顺序，我通常打开 gitk 并目视验证它看起来是否符合我的预期。您希望在 origin/master 之后的下一次提交中看到错误修复。

git checkout hash_3
git branch some_bug_fix
git push origin some_bug_fix:master
git checkout new_feature
git rebase origin/master

最后的变基可能是多余的。

  [origin/master]  hash_0 blah
                   hash_3 bug fix: fixed memory management
  [new_feature  ]  hash_1 feature progress: more widgets!
                   hash_2 feature progress: less widgets, what was I thinking?

或者，

1. 检查远程
2. Cherry pick 的错误修复提交。

但这会复制本地分支中的代码，因此您需要将其从本地分支中删除并在 master 上重新建立基础。

我总是使用 gitk 来挑选，无法帮助你使用命令。

Answer 6

使用 Git 的“交互式添加”功能仅将错误修复添加到“暂存区域”。然后，您可以隐藏其余的更改，测试错误修复以确保其有效，然后自行提交。

下面是一个示例演练。乍一看，它可能看起来又长又复杂，但实际上很简单。一旦你这样做了几次，它就会成为你的第二天性，你可能会发现自己经常使用这种技术。

---

在此示例中，bar.c 和 foo.c 均发生了更改，但只有 foo.c 发生了与错误修复相关的更改。首先，我使用 git add -i 以交互方式仅添加错误修复：

test(master *)$ git add -i
           staged     unstaged path
  1:    unchanged        +1/-0 bar.c
  2:    unchanged        +1/-1 foo.c

*** Commands ***
  1: status       2: update       3: revert       4: add untracked
  5: patch        6: diff         7: quit         8: help

我选择“p”选项来告诉 Git 我希望选择要添加到“暂存区域”的单个“补丁” ：

What now> p
           staged     unstaged path
  1:    unchanged        +1/-0 bar.c
  2:    unchanged        +1/-1 foo.c

接下来我输入 2 告诉它我想从 foo.c 中选择单个补丁：

Patch update>> 2
           staged     unstaged path
  1:    unchanged        +1/-0 bar.c
* 2:    unchanged        +1/-1 foo.c

因为 foo.c 是唯一一个文件现在有我想添加到“暂存区域”的补丁我已完成文件选择，因此只需在提示符下按 Enter 键即可：

Patch update>>

Next Git 会向我显示“foo.c”中的各个补丁，并询问我是否要将它们添加到索引中。在此示例中，只有一项更改，因此我将其暂存：

diff --git a/foo.c b/foo.c
index 7bc741e..ec7ddfc 100644
--- a/foo.c
+++ b/foo.c
@@ -1 +1 @@
-Here is foo.c; it has a bug.
+Here is foo.c.
Stage this hunk [y,n,q,a,d,/,e,?]? y

我现在已暂存属于错误修复一部分的所有内容。所以我退出了“交互式添加”模式：

*** Commands ***
  1: status       2: update       3: revert       4: add untracked
  5: patch        6: diff         7: quit         8: help
What now> q
Bye.

记下状态。 foo.c 已将更改添加到“暂存区域”，但“bar.c”没有：

test(master *+)$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   foo.c
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   bar.c
#

接下来我告诉 Git 存储我的工作，但保留我添加到“暂存区域”的内容区域”（又名
“索引”）：

test(master *+)$ git stash --keep-index
Saved working directory and index state WIP on master: ba84dec Adding bar.c with new "bar feature"
HEAD is now at ba84dec Adding bar.c with new "bar feature"
test(master +$)$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   foo.c
#

现在请注意，我的工作树中唯一的内容是错误修复，并且已准备好在下一次提交中提交。现在我可以在提交之前对错误修复进行任何我想做的测试。

当我对更改感到满意时，我现在可以提交错误修复：

test(master +$)$ git commit
[master 79acd00] Commit bugfix for foo.c
 1 files changed, 1 insertions(+), 1 deletions(-)

现在我弹出存储以将我在 bar.c 中所做的其他工作放回到我的工作树中：

test(master $)$ git stash pop
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   bar.c
#
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (d306d098a272335ed31c14f07cf57e62ffc13151)

然后我'我完成了。我现在可以推送到远程存储库，它将获得错误修复，而我的其余工作仍在我的工作树中并且不会被推送。