将先前的提交分解为多个提交
如果不创建分支并在新分支上做一堆时髦的工作，是否可以在将单个提交提交到本地存储库后将其分解为几个不同的提交？
git autorebase split COMMIT_ID 拆分提交
git reset HEAD~、git stash，然后是 git cherry-pick 壁球中的第一个提交，然后是 git stash pop。我的精选案例在这里非常具体，但 git stash 和 git stash pop 对其他人来说非常方便。
git rebase -i 会这样做。
首先，从一个干净的工作目录开始：git status 应该没有待处理的修改、删除或添加。
现在，您必须决定要拆分哪些提交。
A）拆分最近的提交
要拆分您最近的提交，首先：
$ git reset HEAD~
现在以通常的方式单独提交各个部分，根据需要生成尽可能多的提交。
B) 将提交拆分得更远
这就需要rebase，也就是重写历史。要指定正确的提交，您有多种选择：
如果返回三个提交，则 $ git rebase -i HEAD~3 其中 3 是返回的提交数。
如果它在树中比您想计算的更远，那么 $ git rebase -i 123abcd~ 其中 123abcd 是您要拆分的提交的 SHA1。
如果您在要合并到 master 的不同分支（例如，功能分支）上：$ git rebase -i master
当你得到 rebase 编辑屏幕时，找到你想要拆分的提交。在该行的开头，将 pick 替换为 edit（简称 e）。保存缓冲区并退出。 Rebase 现在将在您要编辑的提交之后停止。然后：
$ git reset HEAD~
以通常的方式单独提交各个部分，根据需要生成尽可能多的提交。
最后
$ git rebase --continue
来自 git-rebase 手册（SPLITTING COMMITS 部分）
在交互模式下，您可以使用“编辑”操作标记提交。但是，这并不一定意味着 git rebase 期望此编辑的结果恰好是一次提交。实际上，您可以撤消提交，也可以添加其他提交。这可用于将提交拆分为两部分：使用 git rebase -i
~ 而不是 ^。
reset提交 - 包括消息。谨慎的做法是，如果您知道要拆分提交但想要保留其部分/全部消息，请获取该消息的副本。因此，在 rebase 之前git show 提交，或者如果您忘记或喜欢这个：稍后通过 reflog 回到它。在 2 周内或其他任何时间将垃圾收集起来之前，它们实际上都不会“丢失”。
~ 和 ^ 是不同的东西，即使在 Windows 上也是如此。您仍然需要插入符号 ^，因此您只需将其转义为适合您的 shell。在 PowerShell 中，它是 HEAD`^。使用 cmd.exe，您可以将其翻倍以像 HEAD^^ 一样转义。在大多数（全部？）shell 中，您可以用 "HEAD^" 之类的引号括起来。
git commit --reuse-message=abcd123。它的简短选项是 -C。
以前的答案涵盖了使用 git rebase -i 来编辑您要拆分的提交，并分批提交。
这在将文件拆分为不同的提交时效果很好，但是如果您想拆分对单个文件的更改，您需要了解更多信息。
到达您想要拆分的提交，使用 rebase -i 并将其标记为 edit，您有两个选择。
使用 git reset HEAD~ 后，使用 git add -p 逐个浏览补丁，在每次提交中选择你想要的 编辑工作副本以删除你不想要的更改；提交该临时状态；然后拉回下一轮的完整提交。
如果您要拆分大型提交，选项 2 很有用，因为它可以让您检查临时版本是否作为合并的一部分正确构建和运行。这进行如下。
使用 rebase -i 和 edit 提交后，使用
git reset --soft HEAD~
撤消提交，但将提交的文件保留在索引中。您还可以通过省略 --soft 来进行混合重置，具体取决于您的初始提交与最终结果的接近程度。唯一的区别是您是从所有更改开始，还是全部不进行更改。
现在进入并编辑代码。您可以删除更改、删除添加的文件，并执行任何您想要构建您正在寻找的系列的第一次提交的事情。您还可以构建、运行它并确认您拥有一组一致的源代码。
满意后，根据需要暂存/取消暂存文件（我喜欢为此使用 git gui），然后通过 UI 或命令行提交更改
git commit
这是第一次提交。现在，您希望将工作副本恢复到您要拆分的提交后的状态，以便您可以为下一次提交进行更多更改。要查找您正在编辑的提交的 sha1，请使用 git status。在状态的前几行中，您将看到当前正在执行的 rebase 命令，您可以在其中找到原始提交的 sha1：
$ git status
interactive rebase in progress; onto be83b41
Last commands done (3 commands done):
pick 4847406 US135756: add debugging to the file download code
e 65dfb6a US135756: write data and download from remote
(see more in file .git/rebase-merge/done)
...
在这种情况下，我正在编辑的提交具有 sha1 65dfb6a。知道这一点后，我可以使用 git checkout 的形式在我的工作目录中检查该提交的内容，该形式同时接受提交和文件位置。这里我使用 . 作为文件位置来替换整个工作副本：
git checkout 65dfb6a .
不要错过最后的点！
这将在您正在编辑的提交之后检查并暂存文件，但相对于您之前所做的提交，因此您已经提交的任何更改都不会成为提交的一部分。
您可以现在继续并按原样提交以完成拆分，或者再次进行，删除提交的某些部分，然后再进行另一个临时提交。
如果你想为一个或多个提交重用原始提交消息，你可以直接从 rebase 的工作文件中使用它：
git commit --file .git/rebase-merge/message
最后，一旦您提交了所有更改，
git rebase --continue
将继续并完成变基操作。
git checkout *Sha I'm Editing* . 时，它总是说 Updated 0 paths from *Some Sha That's Not In Git Log* 并且没有进行任何更改。
使用 git rebase --interactive 编辑较早的提交，运行 git reset HEAD~，然后运行 git add -p 添加一些，然后进行提交，然后再添加一些并进行另一次提交，次数不限。完成后，运行 git rebase --continue，您将在堆栈中较早地获得所有拆分提交。
重要提示：请注意，您可以随意尝试并进行所有您想要的更改，而不必担心丢失旧更改，因为您始终可以运行 git reflog 来查找项目中包含的点您想要的更改（我们称之为 a8c4ab），然后是 git reset a8c4ab。
这里有一系列命令来展示它是如何工作的：
mkdir git-test; cd git-test; git init
现在添加一个文件 A
vi A
添加这一行：
one
git commit -am one
然后将此行添加到A：
two
git commit -am two
然后将此行添加到A：
three
git commit -am three
现在文件 A 看起来像这样：
one
two
three
我们的 git log 如下所示（好吧，我使用 git log --pretty=oneline --pretty="%h %cn %cr ---- %s"
bfb8e46 Rose Perrone 4 seconds ago ---- three
2b613bc Rose Perrone 14 seconds ago ---- two
9aac58f Rose Perrone 24 seconds ago ---- one
假设我们要拆分第二个提交 two。
git rebase --interactive HEAD~2
这会显示如下所示的消息：
pick 2b613bc two
pick bfb8e46 three
将第一个 pick 更改为 e 以编辑该提交。
git reset HEAD~
git diff 向我们展示了我们刚刚取消了为第二次提交所做的提交：
diff --git a/A b/A
index 5626abf..814f4a4 100644
--- a/A
+++ b/A
@@ -1 +1,2 @@
one
+two
让我们暂存该更改，并在文件 A 中的该行中添加“and a third”。
git add .
这通常是交互式 rebase 期间我们将运行 git rebase --continue 的点，因为我们通常只想返回我们的提交堆栈以编辑较早的提交。但是这一次，我们想要创建一个新的提交。所以我们将运行 git commit -am 'two and a third'。现在我们编辑文件 A 并添加行 two and two thirds。
git add . git commit -am 'two and two thirds' git rebase --continue
我们与我们的提交 three 有冲突，所以让我们解决它：
我们会改变
one
<<<<<<< HEAD
two and a third
two and two thirds
=======
two
three
>>>>>>> bfb8e46... three
至
one
two and a third
two and two thirds
three
git add .; git rebase --continue
现在我们的 git log -p 如下所示：
commit e59ca35bae8360439823d66d459238779e5b4892
Author: Rose Perrone <roseperrone@fake.com>
Date: Sun Jul 7 13:57:00 2013 -0700
three
diff --git a/A b/A
index 5aef867..dd8fb63 100644
--- a/A
+++ b/A
@@ -1,3 +1,4 @@
one
two and a third
two and two thirds
+three
commit 4a283ba9bf83ef664541b467acdd0bb4d770ab8e
Author: Rose Perrone <roseperrone@fake.com>
Date: Sun Jul 7 14:07:07 2013 -0700
two and two thirds
diff --git a/A b/A
index 575010a..5aef867 100644
--- a/A
+++ b/A
@@ -1,2 +1,3 @@
one
two and a third
+two and two thirds
commit 704d323ca1bc7c45ed8b1714d924adcdc83dfa44
Author: Rose Perrone <roseperrone@fake.com>
Date: Sun Jul 7 14:06:40 2013 -0700
two and a third
diff --git a/A b/A
index 5626abf..575010a 100644
--- a/A
+++ b/A
@@ -1 +1,2 @@
one
+two and a third
commit 9aac58f3893488ec643fecab3c85f5a2f481586f
Author: Rose Perrone <roseperrone@fake.com>
Date: Sun Jul 7 13:56:40 2013 -0700
one
diff --git a/A b/A
new file mode 100644
index 0000000..5626abf
--- /dev/null
+++ b/A
@@ -0,0 +1 @@
+one
git rebase --interactive 可用于将提交拆分为较小的提交。 Git docs on rebase have a concise walkthrough of the process - Splitting Commits：
在交互模式下，您可以使用“编辑”操作标记提交。但是，这并不一定意味着 git rebase 期望此编辑的结果恰好是一次提交。实际上，您可以撤消提交，也可以添加其他提交。这可用于将提交拆分为两部分：使用 git rebase -i
^ 是命令行的转义字符：它应该加倍。例如，发出 git reset HEAD^^ 而不是 git reset HEAD^。
^ 两次重置当前 HEAD 之上的两个提交。
"HEAD^"、cmd.exe 中的 HEAD^^、PowerShell 中的 HEAD`^。了解 shell（以及您的特定 shell）如何工作（即命令如何变成传递给程序的各个部分）很有用，这样您就可以在线将命令调整为特定 shell 的正确字符。 （不特定于 Windows。）
现在在 Windows 上最新的 TortoiseGit 中，你可以很容易地做到这一点。
打开变基对话框 configure it，然后执行以下步骤。
右键单击要拆分的提交并选择“编辑”（在选择、挤压、删除...中）。
单击“开始”开始变基。
一旦到达要拆分的提交，检查“编辑/拆分”按钮并直接单击“修改”。提交对话框打开。
取消选择要单独提交的文件。
编辑提交消息，然后单击“提交”。
在有文件要提交之前，提交对话框将一次又一次地打开。当没有更多要提交的文件时，它仍然会询问您是否要再添加一个提交。
非常有帮助，谢谢 TortoiseGit ！
您可以进行交互式变基 git rebase -i。手册页正是您想要的：
http://git-scm.com/docs/git-rebase#_splitting_commits
必要命令的快速参考，因为我基本上知道该做什么但总是忘记正确的语法：
git rebase -i <sha1_before_split>
# mark the targeted commit with 'edit'
git reset HEAD^
git add ...
git commit -m "First part"
git add ...
git commit -m "Second part"
git rebase --continue
归功于 Emmanuel Bernard's blog post。
请注意，还有 git reset --soft HEAD^。它类似于 git reset（默认为 --mixed），但它保留了索引内容。因此，如果您添加/删除了文件，则它们已经在索引中。
事实证明在巨大提交的情况下非常有用。
如果没有交互式变基，最简单的事情是（可能）在要拆分的分支之前的提交开始创建一个新分支，cherry-pick -n 提交，重置，存储，提交文件移动，重新应用存储和提交更改，然后与前一个分支合并或挑选随后的提交。 （然后将以前的分支名称切换到当前的头。）（最好听从 MBO 的建议并进行交互式变基。）
rebase -i 建议要容易得多。不过，我认为由于缺乏任何格式，这并没有引起太多关注。也许你可能会复习它，因为你有 126k 点并且可能知道如何 SO。 ;)
这是如何在 IntelliJ IDEA、PyCharm、PhpStorm 等中拆分一个提交
在版本控制日志窗口中，选择您要拆分的提交，右键单击并选择 Interactively Rebase from Here 将您要拆分的那个标记为编辑，单击 Start Rebase 您应该会看到一个黄色标签，这意味着 HEAD 是设置为该提交。右键单击该提交，选择 Undo Commit 现在这些提交返回到暂存区域，然后您可以单独提交它们。提交所有更改后，旧提交将变为非活动状态。
已经 8 年多了，但也许有人会觉得它有帮助。我能够在没有 rebase -i 的情况下做到这一点。这个想法是让 git 回到你做 git commit 之前的状态：
# first rewind back (mind the dot,
# though it can be any valid path,
# for instance if you want to apply only a subset of the commit)
git reset --hard <previous-commit> .
# apply the changes
git checkout <commit-you-want-to-split>
# we're almost there, but the changes are in the index at the moment,
# hence one more step (exactly as git gently suggests):
# (use "git reset HEAD <file>..." to unstage)
git reset
在此之后，您将看到这个闪亮的 Unstaged changes after reset:，并且您的存储库处于您即将提交所有这些文件的状态。从现在开始，您可以像往常一样轻松地再次提交它。希望能帮助到你。
如果您只想从现有提交中提取某些内容并保留原始提交，则可以使用
git reset --patch HEAD^
而不是 git reset HEAD^。这个命令允许你只重置你需要的块。
选择要重置的块后，您将拥有暂存的块，这些块将在您完成后重置先前提交中的更改
git commit --amend --no-edit
和未暂存的块，您可以通过
git add .
git commit -m "new commit"
题外话事实：
在 mercurial 中，他们有 hg split - 我想在 git 中看到 hg absorb 之后的第二个功能。
如果你有这个：
A - B <- mybranch
您在提交 B 中提交了一些内容的地方：
/modules/a/file1
/modules/a/file2
/modules/b/file3
/modules/b/file4
但是您想将 B 拆分为 C - D，并得到以下结果：
A - C - D <-mybranch
例如，您可以像这样划分内容（来自不同提交中不同目录的内容）......
将分支重置为要拆分之前的提交：
git checkout mybranch
git reset --hard A
创建第一个提交 (C)：
git checkout B /modules/a
git add -u
git commit -m "content of /modules/a"
创建第二次提交 (D)：
git checkout B /modules/b
git add -u
git commit -m "content of /modules/b"
大多数现有答案都建议使用交互式变基 - git rebase -i 或类似的。对于像我这样对“互动”方法有恐惧症并喜欢在下楼梯时抓住扶手的人，这里有一个替代方案。
假设您的历史记录看起来像 … —> P –> Q –> R –> … –> Z = mybranch，并且您想将 P –> Q 拆分为两个提交，最终得到 P –> Q1 –> Q' –> R' –> … Z' = mybranch，其中 Q'、R' 等处的代码状态与 Q 相同， R 等。
在开始之前，如果您偏执，请备份 mybranch，以免丢失历史记录：
git checkout mybranch
git checkout -b mybranch-backup
首先，检查 P（您要拆分的位置之前的提交），然后创建一个新分支以使用
git checkout P
git checkout -b mybranch-splitting
现在，从 Q 签出您想要的任何文件，并根据需要进行编辑以创建新的中间提交：
git checkout Q file1.txt file2.txt
[…edit, stage commit with “git add”, etc…]
git commit -m "Refactored the widgets"
请注意此提交的哈希值，如 Q1。现在检查 Q 的完整状态，在 Q1 的分离 HEAD 上，提交它（创建 Q'），并将工作分支拉到它：
git checkout Q
git reset --soft Q1
git commit -m "Added unit tests for widgets"
git branch -f mybranch-splitting
您现在在 Q' 的 mybranch-splitting 上，它应该具有与 Q 完全相同的代码状态。现在将原始分支（从 Q 到 Z）重新设置为：
git rebase --onto HEAD Q mybranch
现在 mybranch 应该看起来像 … P -> Q1 –> Q' –> R' –> … Z'，如您所愿。因此，在检查一切正常后，您可以删除工作和备份分支，并（如果合适）将重写的 mybranch 推送到上游。如果它已经被推送，您需要强制推送，并且所有关于强制推送的常见警告都适用。
git push --force mybranch
git branch -d mybranch-splitting mybranch-backup
git diff mybranch-backup 以确保您不会意外忘记某些内容。如果它显示差异 - 您只需 git reset --hard mybranch-backup 重新开始。此外，git checkout Q file1.txt file2.txt 是 IMO 比 reset HEAD^ 和 commit -p 更脆弱的方法。
我用变基做到了这一点。编辑提交对我不起作用，因为它已经选择了提交文件并允许您对其进行修改，但我想将所有文件添加为未跟踪的文件，以便我可以选择其中的一些。步骤是：
git rebase -i HEAD~5 （我想拆分我历史上的第 5 个最后提交）复制目标提交 ID（稍后您将需要它）用 d 标记提交以删除它；在提交后立即添加 ab 行以停止变基过程并稍后继续。即使这是最后一次提交，这也为您提供了一些空间来 git rebase --abort 并在出现问题时重置所有内容。当变基到达断点时，使用 git cherry-pick -n
作为交互式变基的忠实拥护者，这是我能想到的最简单、最直接的一组步骤。我希望这可以帮助任何面临这个问题的人！
如果您的更改主要是添加新内容，则此方法最有用。
有时您不想丢失与正在拆分的提交相关的提交消息。如果您提交了一些想要拆分的更改，您可以：
编辑要从文件中删除的更改（即删除行或适当更改文件以适应第一次提交）。您可以结合使用您选择的编辑器和 git checkout -p HEAD^ -- path/to/file 将一些更改还原到当前树。将此编辑作为新提交提交，使用 git add 之类的内容。 ; git commit -m 'removal of things that should be changed later'，因此您将在历史记录中拥有原始提交，并且您还将拥有另一个包含您所做更改的提交，因此当前 HEAD 上的文件看起来就像您首先想要它们一样拆分后提交。
000aaa Original commit
000bbb removal of things that should be changed later
使用 git revert HEAD 恢复编辑，这将创建恢复提交。文件看起来就像它们在原始提交时所做的那样，您的历史现在看起来像
000aaa Original commit
000bbb removal of things that should be changed later
000ccc Revert "removal of things that should be changed later" (assuming you didn't edit commit message immediately)
现在，您可以使用 git rebase -i 将前两个提交压缩/修复为一个，如果您之前没有向它提供有意义的提交消息，则可以选择修改恢复提交。你应该留下
000ddd Original commit, but without some content that is changed later
000eee Things that should be changed later
git rebase --continue之前，我实际上必须先git add (files to be added)、git commit，然后是git stash（对于剩余的文件）。在git rebase --continue之后，我使用git checkout stash .来获取剩余的文件git add -p仅添加文件的部分部分，可能使用e选项来编辑差异以仅提交一些大块。如果您想推进一些工作但将其从当前提交中删除，git stash也很有用。git rebase -i HEAD^3命令单独重新排序。这样，如果拆分不好，您不必撤消太多工作。git reset HEAD~之后留在磁盘上。他们没有迷路。