From da178478d09f40bcc2733dbc7007989d95494089 Mon Sep 17 00:00:00 2001 From: Xingyu Wang Date: Mon, 1 Jun 2020 17:40:19 +0800 Subject: [PATCH 1/2] PRF @wxy --- ...Learn to change history with git rebase.md | 115 ++++++++++-------- 1 file changed, 61 insertions(+), 54 deletions(-) diff --git a/translated/tech/20190510 Learn to change history with git rebase.md b/translated/tech/20190510 Learn to change history with git rebase.md index 300afe1f7c..5854bbbeda 100644 --- a/translated/tech/20190510 Learn to change history with git rebase.md +++ b/translated/tech/20190510 Learn to change history with git rebase.md @@ -1,24 +1,24 @@ [#]: collector: (lujun9972) [#]: translator: (wxy) -[#]: reviewer: ( ) +[#]: reviewer: (wxy) [#]: publisher: ( ) [#]: url: ( ) [#]: subject: (Learn to change history with git rebase!) [#]: via: (https://git-rebase.io/) [#]: author: (git-rebase https://git-rebase.io/) -学习用 git 变基来改变历史！ +学习用 Git 变基来改变历史！ ====== -[Git][1] 的核心的附加价值之一就是编辑历史记录的能力。不同于将历史记录视为神圣的记录的版本控制系统，在 Git 中，我们可以根据自己的需要修改历史记录。这为我们提供了很多强大的工具，让我们可以像使用重构来维护良好的软件设计实践一样，编织良好的提交历史。这些工具对于新手甚至是有经验的 Git 用户来说可能会有些生畏，但本指南将帮助我们揭秘强大的 git-rebase。 +[Git][1] 核心的附加价值之一就是编辑历史记录的能力。与将历史记录视为神圣的记录的版本控制系统不同，在 Git 中，我们可以修改历史记录以适应我们的需要。这为我们提供了很多强大的工具，让我们可以像使用重构来维护良好的软件设计实践一样，编织良好的提交历史。这些工具对于新手甚至是有经验的 Git 用户来说可能会有些令人生畏，但本指南将帮助我们揭开强大的 git-rebase 的神秘面纱。 -> 值得注意的是：一般建议不要修改公共分支、共享分支或稳定分支的历史记录。编辑特性分支和个人分支的历史记录是可以的，编辑还没有推送的提交也是可以的。在编辑完提交后，使用 `git push -f` 来强制推送你的修改到个人分支或特性分支。 +> 值得注意的是：一般建议不要修改公共分支、共享分支或稳定分支的历史记录。编辑特性分支和个人分支的历史记录是可以的，编辑还没有推送的提交也是可以的。在编辑完提交后，可以使用 `git push -f` 来强制推送你的修改到个人分支或特性分支。 -尽管有这么可怕的警告，但值得一提的是，本指南中提到的一切都是非破坏性操作。实际上，在 Git 中永久丢失数据是相当困难的。当你犯错时的修复方法在本指南的最后会涉及到。 +尽管有这么可怕的警告，但值得一提的是，本指南中提到的一切都是非破坏性操作。实际上，在 Git 中永久丢失数据是相当困难的。本指南结尾介绍了在犯错误时进行纠正的方法。 ### 设置沙盒 -我们不想破坏你的实际版本库，所以在整个指南中，我们将使用一个沙盒版本库。运行这些命令来开始工作。[^1] +我们不想破坏你的任何实际的版本库，所以在整个指南中，我们将使用一个沙盒版本库。运行这些命令来开始工作。[^1] ``` git init /tmp/rebase-sandbox @@ -26,11 +26,11 @@ cd /tmp/rebase-sandbox git commit --allow-empty -m"Initial commit" ``` -如果你遇到麻烦，只需运行 `rm -rf /tmp/rebase-sandbox`，然后重新运行这些步骤重新开始。本指南的每一步都可以在一个新的沙箱上运行，所以没有必要重做每个任务。 +如果你遇到麻烦，只需运行 `rm -rf /tmp/rebase-sandbox`，并重新运行这些步骤即可重新开始。本指南的每一步都可以在新的沙箱上运行，所以没有必要重做每个任务。 ### 修正最近的提交 -让我们从简单的事情开始：修复你最近的提交。让我们将一个文件添加到我们的沙盒中，并犯个错误。 +让我们从简单的事情开始：修复你最近的提交。让我们向沙盒中添加一个文件，并犯个错误。 ``` echo "Hello wrold!" >greeting.txt @@ -45,7 +45,7 @@ echo "Hello world!" >greeting.txt git commit -a --amend ``` -指定 `-a` 会自动将所有 Git 已经知道的文件进行暂存（即 `--amend`），而 `--amend` 会将更改的内容压制到最近的提交中。保存并退出你的编辑器（如果你愿意的话，现在你有机会修改提交信息）。你可以通过运行 `--git show` 看到修复的提交。 +指定 `-a` 会自动将所有 Git 已经知道的文件进行暂存（例如 Git 添加的），而 `--amend` 会将更改的内容压扁到最近的提交中。保存并退出你的编辑器（如果需要，你现在可以修改提交信息）。你可以通过运行 `git show` 看到修复的提交。 ``` commit f5f19fbf6d35b2db37dcac3a55289ff9602e4d00 (HEAD -> master) @@ -63,9 +63,9 @@ index 0000000..cd08755 +Hello world! ``` -### 修复更旧的提交 +### 修复较旧的提交 -`--amend` 只对最近的提交有效。如果你需要修正一个较旧的提交，会发生什么？让我们相应地从设置沙盒开始： +`--amend` 仅适用于最近的提交。如果你需要修正一个较旧的提交会怎么样？让我们从相应地设置沙盒开始： ``` echo "Hello!" >greeting.txt @@ -84,7 +84,7 @@ echo "Hello world!" >greeting.txt git commit -a -m"fixup greeting.txt" ``` -现在文件看起来正确，但是我们的历史记录可以会更好一点 —— 让我们使用新的提交来“修复”（`fixup`）最后一个提交。为此，我们需要引入一个新工具：交互式变基。我们将以这种方式编辑最后三个提交，因此我们将运行`git rebase -i HEAD~3`（`-i` 代表交互式）。这样会打开文本编辑器，如下所示： +现在文件看起来正确，但是我们的历史记录可以更好一点 —— 让我们使用新的提交来“修复”（`fixup`）最后一个提交。为此，我们需要引入一个新工具：交互式变基。我们将以这种方式编辑最后三个提交，因此我们将运行 `git rebase -i HEAD~3`（`-i` 代表交互式）。这样会打开文本编辑器，如下所示： ``` pick 8d3fc77 Add greeting.txt @@ -98,9 +98,9 @@ pick 0b9d0bb fixup greeting.txt # f, fixup = like "squash", but discard this commit's log message ``` -这是变基计划，通过编辑此文件，你可以指导 Git 如何编辑历史记录。我已经将该摘要删节为仅与变基计划这一部分相关的细节，但是你可以在文本编辑器中浏览完整的摘要。 +这是变基计划，通过编辑此文件，你可以指导 Git 如何编辑历史记录。我已经将该摘要削减为仅与变基计划这一部分相关的细节，但是你可以在文本编辑器中浏览完整的摘要。 -当我们保存并关闭编辑器时，Git 将从其历史记录中删除所有这些提交，然后一次执行每一行。默认情况下，它将选取（`pick`）每个提交，将其从堆中召唤出来并将其添加到分支中。如果我们对此文件根本没有做任何编辑，则将直接回到起点，按原样选取每个提交。现在，我们将使用我最喜欢的功能之一：修复（`fixup`）。编辑第三行，将操作从 `pick` 更改为 `fixup`，并将其立即移至我们要“修复”的提交之后： +当我们保存并关闭编辑器时，Git 将从其历史记录中删除所有这些提交，然后一次执行一行。默认情况下，它将选取（`pick`）每个提交，将其从堆中召唤出来并添加到分支中。如果我们对此文件根本没有做任何编辑，则将直接回到起点，按原样选取每个提交。现在，我们将使用我最喜欢的功能之一：修复（`fixup`）。编辑第三行，将操作从 `pick` 更改为 `fixup`，并将其立即移至我们要“修复”的提交之后： ``` pick 8d3fc77 Add greeting.txt @@ -108,7 +108,7 @@ fixup 0b9d0bb fixup greeting.txt pick 2a73a77 Add farewell.txt ``` -**技巧**：我们也可以只用 `f` 来缩写它，以加快下次的速度。 +> **技巧**：我们也可以只用 `f` 来缩写它，以加快下次的速度。 保存并退出编辑器，Git 将运行这些命令。我们可以检查日志以验证结果： @@ -120,7 +120,7 @@ a479e94 Add greeting.txt ### 将多个提交压扁为一个 -在工作时，当你达到较小的里程碑或修复以前的提交中的错误时，你可能会发现写很多提交很有用。但是，在将你的工作合并到 `master` 分支之前，将这些提交“压扁”（`squash`）在一起以使历史记录更清晰可能很有用。为此，我们将使用“压扁”（`squash `）操作。让我们从编写一堆提交开始，如果要加快速度，只需复制并粘贴这些： +在工作时，当你达到较小的里程碑或修复以前的提交中的错误时，你可能会发现写很多提交很有用。但是，在将你的工作合并到 `master` 分支之前，将这些提交“压扁”（`squash`）到一起以使历史记录更清晰可能很有用。为此，我们将使用“压扁”（`squash `）操作。让我们从编写一堆提交开始，如果要加快速度，只需复制并粘贴这些： ``` git checkout -b squash @@ -131,7 +131,7 @@ for c in H e l l o , ' ' w o r l d; do done ``` -要做出一个写着 “Hello，world”的文件，要做很多事情！让我们开始另一个交互式变基，将它们压扁在一起。请注意，我们首先签出了一个分支来进行尝试。因此，因为我们使用 `git rebase -i master` 进行的分支，我们可以快速变基所有提交。结果： +要制作出一个写着 “Hello，world” 的文件，要做很多事情！让我们开始另一个交互式变基，将它们压扁在一起。请注意，我们首先签出了一个分支来进行尝试。因此，因为我们使用 `git rebase -i master` 进行的分支，我们可以快速变基所有提交。结果： ``` pick 1e85199 Add 'H' to squash.txt @@ -154,9 +154,9 @@ pick 6b608ae Add 'd' to squash.txt # s, squash = use commit, but meld into previous commit ``` -**技巧**：你的本地 `master` 分支独立于远程 `master` 分支而发展，并且 Git 将远程分支存储为 `origin/master`。结合这种技巧，`git rebase -i origin/master` 通常是一种非常方便的方法，可以变基所有尚未合并到上游的提交！ +> **技巧**：你的本地 `master` 分支独立于远程 `master` 分支而发展，并且 Git 将远程分支存储为 `origin/master`。结合这种技巧，`git rebase -i origin/master` 通常是一种非常方便的方法，可以变基所有尚未合并到上游的提交！ -我们将把所有这些更改压扁到第一个提交中。为此，将第一行除外的每个“选取”（`pick`）操作都更改为“压扁”（`squash `），如下所示： +我们将把所有这些更改压扁到第一个提交中。为此，将第一行除外的每个“选取”（`pick`）操作都更改为“压扁”（`squash`），如下所示： ``` pick 1e85199 Add 'H' to squash.txt @@ -244,7 +244,7 @@ Add 'd' to squash.txt 默认情况下，这是所有要压扁的提交的消息的组合，但是像这样将其保留肯定不是你想要的。不过，旧的提交消息在编写新的提交消息时可能很有用，所以放在这里以供参考。 -**提示**：你在上一节中了解的“修复”（`fixup`）命令也可以用于此目的，但它会丢弃压缩的提交消息。 +> **提示**：你在上一节中了解的“修复”（`fixup`）命令也可以用于此目的，但它会丢弃压扁的提交的消息。 让我们删除所有内容，并用更好的提交消息替换它，如下所示： @@ -286,7 +286,7 @@ git rebase squash git branch -D squash ``` -除非我们实际上正在合并无关的历史记录，否则我们通常希望避免使用 `git merge`。如果你有两个不同的分支，则 `git merge` 对于记录合并它们的时间非常有用。在正常工作过程中，变基通常更为合适。 +除非我们实际上正在合并无关的历史记录，否则我们通常希望避免使用 `git merge`。如果你有两个不同的分支，则 `git merge` 对于记录它们合并的时间非常有用。在正常工作过程中，变基通常更为合适。 ### 将一个提交拆分为多个 @@ -334,7 +334,7 @@ EOF git commit -a -m"Flesh out C program" ``` -第一步是启动交互式变基。让我们用 `git rebase -i HEAD~2` 来变基这两个提交，变基计划如下： +第一步是启动交互式变基。让我们用 `git rebase -i HEAD~2` 来变基这两个提交，给出的变基计划如下： ``` pick 237b246 Add C program skeleton @@ -360,7 +360,7 @@ Once you are satisfied with your changes, run git rebase --continue ``` -我们可以按照以下说明为提交添加新的更改，但我们可以通过运行 `git reset HEAD^` 来进行“软重置” [^3]。如果在此之后运行 `git status`，你将看到它取消提交最新的提交，并将其更改添加到工作树中： +我们可以按照以下说明为提交*添加*新的更改，但我们可以通过运行 `git reset HEAD^` 来进行“软重置” [^3]。如果在此之后运行 `git status`，你将看到它取消了提交最新的提交，并将其更改添加到工作树中： ``` Last commands done (2 commands done): @@ -379,7 +379,7 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ``` -为了对此进行拆分，我们将进行交互式提交。这使我们能够选择性地仅提交工作树中的特定更改。运行 `git commit -p` 开始这个过程，将出现以下提示： +为了对此进行拆分，我们将进行*交互式提交*。这使我们能够选择性地仅提交工作树中的特定更改。运行 `git commit -p` 开始此过程，你将看到以下提示： ``` diff --git a/main.c b/main.c @@ -421,7 +421,7 @@ Split into 2 hunks. Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? ``` -**提示**：如果你对其他选项感到好奇，请按 `?` 汇总显示。 +> **提示**：如果你对其他选项感到好奇，请按 `?` 汇总显示。 这个大块看起来更好：单一、独立的更改。让我们按 `y` 来回答问题（并暂存那个“大块”），然后按 `q` 以“退出”交互式会话并继续进行提交。会弹出编辑器，要求输入合适的提交消息。 @@ -446,14 +446,14 @@ Add get_name function to C program # ``` -保存并关闭编辑器，然后我们进行第二次提交。我们可以执行另一个交互式提交，但是由于我们只想在此提交中包括其余更改，因此我们将执行以下操作： +保存并关闭编辑器，然后我们进行第二次提交。我们可以执行另一次交互式提交，但是由于我们只想在此提交中包括其余更改，因此我们将执行以下操作： ``` git commit -a -m"Prompt user for their name" git rebase --continue ``` -最后一条命令告诉 Git 我们已经完成了此提交的编辑，并继续执行下一个变基命令。就是这样！运行 `git log` 来查看你的劳动成果： +最后一条命令告诉 Git 我们已经完成了此提交的编辑，并继续执行下一个变基命令。这样就行了！运行 `git log` 来查看你的劳动成果： ``` $ git log -3 --oneline @@ -464,7 +464,7 @@ fe19cc3 (HEAD -> master) Prompt user for their name ### 重新排序提交 -这很简单。 让我们从设置沙箱开始： +这很简单。让我们从设置沙箱开始： ``` echo "Goodbye now!" >farewell.txt @@ -480,7 +480,7 @@ git add inquiry.txt git commit -m"Add inquiry.txt" ``` -Git 日志现在应如下所示： +现在 `git log` 看起来应如下所示： ``` f03baa5 (HEAD -> master) Add inquiry.txt @@ -515,18 +515,26 @@ pick 90bb015 Add farewell.txt ### git pull --rebase -如果你一直在上游更新的分支上编写一些提交，通常 `git pull` 将创建一个合并提交。在这方面，`git pull` 的默认行为等同于： +如果你一直在由上游更新的分支 ``（比如说原始远程）上做一些提交，通常 `git pull` 会创建一个合并提交。在这方面，`git pull` 的默认行为等同于： + +``` +git fetch origin +git merge origin/ +``` + +假设本地分支 `` 配置为从原始远程跟踪 `` 分支，即： + +``` +$ git config branch..remote +origin +$ git config branch..merge +refs/heads/ +``` +还有另一种选择，它通常更有用，并且会让历史记录更清晰：`git pull --rebase`。与合并方式不同，这基本上 [^4] 等效于以下内容： ``` git fetch origin -git merge origin/master -``` - -还有另一种选择，它通常更有用，并且导致更清晰的历史记录：`git pull --rebase`。与合并方式不同，这基本上 [^4] 等效于以下内容： - -``` -git fetch origin -git rebase origin/master +git rebase origin/ ``` 合并方式更简单易懂，但是如果你了解如何使用 `git rebase`，那么变基方式几乎可以做到你想要做的任何事情。如果愿意，可以将其设置为默认行为，如下所示： @@ -535,31 +543,30 @@ git rebase origin/master git config --global pull.rebase true ``` -当你执行此操作时，从技术上讲，你将应用我们在下一节中讨论的过程...因此，让我们也解释一下故意执行此操作的含义。 +当你执行此操作时，从技术上讲，你在应用我们在下一节中讨论的过程……因此，让我们也解释一下故意执行此操作的含义。 ### 使用 git rebase 来变基 具有讽刺意味的是，我最少使用的 Git 变基功能是它以之命名的功能：变基分支。假设你有以下分支： ``` -o--o--o--o--> master - \--o--o--> feature-1 - \--o--> feature-2 +A--B--C--D--> master + \--E--F--> feature-1 + \--G--> feature-2 ``` -事实证明，`feature-2` 不依赖于 `feature-` 的任何更改，因此你可以将其作为基础。因此，解决方法是： +事实证明，`feature-2` 不依赖于 `feature-1` 的任何更改，它依赖于提交 E，因此你可以将其作为基础脱离 `master`。因此，解决方法是： ``` -git checkout feature-2 -git rebase master +git rebase --onto master feature-1 feature-2 ``` -非交互式变基对所有牵连的提交（`pick`）[^5] 都执行默认操作，它简单地将你的历史回滚到最后一个共同的祖先，并从两个分支中重放提交。你的历史记录现在看起来像这样： +非交互式变基对所有牵连的提交都执行默认操作（`pick`）[^5] ，它只是简单地将不在 `feature-1` 中的 `feature-2` 中提交重放到 `master` 上。你的历史记录现在看起来像这样： ``` -o--o--o--o--> master - | \--o--> feature-2 - \--o--o--> feature-1 +A--B--C--D--> master + | \--G--> feature-2 + \--E--F--> feature-1 ``` ### 解决冲突 @@ -568,17 +575,17 @@ o--o--o--o--> master 有时，在进行变基时会遇到合并冲突，你可以像处理其他任何合并冲突一样处理该冲突。Git 将在受影响的文件中设置冲突标记，`git status` 将显示你需要解决的问题，并且你可以使用 `git add` 或 `git rm` 将文件标记为已解决。但是，在 `git rebase` 的上下文中，你应该注意两个选项。 -首先是如何完成冲突解决。解决由于 `git merge` 引起的冲突时，你将不会像使用 `git commit` 那样，适当的变基命令是 `git rebase --continue`。但是，还有一个可用的选项：`git rebase --skip`。 这将跳过你正在处理的提交，它不会包含在变基中。这在执行非交互性变基时最常见，这时 Git 不意识到它从“其他”分支中提取的提交是与“我们”分支上冲突的提交的更新版本。 +首先是如何完成冲突解决。解决由于 `git merge` 引起的冲突时，与其使用 `git commit` 那样的命令，更适当的变基命令是 `git rebase --continue`。但是，还有一个可用的选项：`git rebase --skip`。 这将跳过你正在处理的提交，它不会包含在变基中。这在执行非交互性变基时最常见，这时 Git 不会意识到它从“其他”分支中提取的提交是与“我们”分支上冲突的提交的更新版本。 ### 帮帮我！ 我把它弄坏了！ -毫无疑问，变基有时会很难。如果你犯了一个错误，并因此而丢失了所需的提交，那么可以使用 `git reflog` 来节省下一天的时间。运行此命令将向你显示更改一个引用（即分支和标记）的每个操作。每行显示你旧的引用所指的内容，你可对你认为丢失的 Git 提交执行 `git cherry-pick`、`git checkout`、`git show` 或任何其他操作。 +毫无疑问，变基有时会很难。如果你犯了一个错误，并因此而丢失了所需的提交，那么可以使用 `git reflog` 来节省下一天的时间。运行此命令将向你显示更改一个引用（即分支和标记）的每个操作。每行显示你的旧引用所指向的内容，你可对你认为丢失的 Git 提交执行 `git cherry-pick`、`git checkout`、`git show` 或任何其他操作。 [^1]: 我们添加了一个空的初始提交以简化本教程的其余部分，因为要对版本库的初始提交进行变基需要特殊的命令（即` git rebase --root`）。 [^2]: 如果要编译此程序，请运行 `cc -o main main.c`，然后运行 `./main` 查看结果。 [^3]: 实际上，这是“混合重置”。“软重置”（使用 `git reset --soft` 完成）将暂存更改，因此你无需再次 `git add` 添加它们，并且可以一次性提交所有更改。这不是我们想要的。我们希望选择性地暂存部分更改，以拆分提交。 -[^4]: 实际上，这取决于上游分支本身是否已变基或删除/压扁了某些提交。`git pull --rebase` 尝试通过在 `git rebase` 和 `git merge-base` 中使用 “fork-point” 机制来从这种情况中恢复，以避免变基非本地提交。 -[^5]: 实际上，这取决于 Git 的版本。从 2.26.0 版开始，默认的非交互行为以前与交互行为稍有不同，这种方式通常并不重要。 +[^4]: 实际上，这取决于上游分支本身是否已变基或删除/压扁了某些提交。`git pull --rebase` 尝试通过在 `git rebase` 和 `git merge-base` 中使用 “复刻点fork-point” 机制来从这种情况中恢复，以避免变基非本地提交。 +[^5]: 实际上，这取决于 Git 的版本。直到 2.26.0 版，默认的非交互行为以前与交互行为稍有不同，这种方式通常并不重要。 -------------------------------------------------------------------------------- @@ -587,7 +594,7 @@ via: https://git-rebase.io/ 作者：[git-rebase][a] 选题：[lujun9972][b] 译者：[wxy](https://github.com/wxy) -校对：[校对者ID](https://github.com/校对者ID) +校对：[wxy](https://github.com/wxy) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 From c98a9549791f5948bbbff897bf2b04780b1001ba Mon Sep 17 00:00:00 2001 From: Xingyu Wang Date: Mon, 1 Jun 2020 17:40:49 +0800 Subject: [PATCH 2/2] PUB @wxy https://linux.cn/article-12271-1.html --- .../20190510 Learn to change history with git rebase.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename {translated/tech => published}/20190510 Learn to change history with git rebase.md (99%) diff --git a/translated/tech/20190510 Learn to change history with git rebase.md b/published/20190510 Learn to change history with git rebase.md similarity index 99% rename from translated/tech/20190510 Learn to change history with git rebase.md rename to published/20190510 Learn to change history with git rebase.md index 5854bbbeda..339e4ef696 100644 --- a/translated/tech/20190510 Learn to change history with git rebase.md +++ b/published/20190510 Learn to change history with git rebase.md @@ -1,8 +1,8 @@ [#]: collector: (lujun9972) [#]: translator: (wxy) [#]: reviewer: (wxy) -[#]: publisher: ( ) -[#]: url: ( ) +[#]: publisher: (wxy) +[#]: url: (https://linux.cn/article-12271-1.html) [#]: subject: (Learn to change history with git rebase!) [#]: via: (https://git-rebase.io/) [#]: author: (git-rebase https://git-rebase.io/)