Git 是一种流行的版本控制系统，数百万开发人员使用它来管理自己的代码库。Git最强大的功能之一是通过远程仓库协同工作的能力。

在一个项目中与多人合作时，你必须能够从远程仓库中获取变更并将其与本地仓库合并。本文将教你如何在 Git 中获取远程分支。

什么是远程分支？

在了解如何获取远程分支之前，让我们先定义一下远程分支。

远程分支是指存在于 GitHub、GitLab 或 Bitbucket 等远程仓库中的分支。

克隆一个仓库时，Git 会自动创建一个指向原始仓库的 “remote”分支。然后，你就可以用这个远程分支来获取项目中其他协作者所做的修改。

如何在 Git 中获取远程分支

当你克隆一个仓库时，你可以访问它的所有远程分支。你可以使用git branch命令和-r选项来验证这一点：

git branch -r

你可以使用git checkout命令签出到这些分支中的任何一个。

当你与一群人一起工作时，其中一个贡献者会远程创建一个新的分支。你可能需要将这个远程分支拉取到你的项目中。你可以使用git fetch命令来完成这项工作。

git fetch命令会转向你的远程项目，并从该远程项目中拉取你还没有的所有数据。接着，你就可以获得该远程分支的所有引用，随时可以合并或检查这些引用。

git fetch

你可以写上远程仓库库名称，默认为origin：

git fetch origin

需要注意的是，当你使用git fetch命令时，它只会将远程仓库中的更改下载到本地仓库，而不会自动与你的工作合并，也不会修改你当前的工作。你需要在准备就绪后手动合并更改。

要访问获取的内容，需要使用git checkout命令。这样就能确保在将提交整合到本地仓库之前，对提交进行审核。

如果想获取远程分支并将其与自己的工作合并或修改当前工作，可以使用git pull命令。为此，请使用以下命令：

git pull --all

然后就可以运行git branch -r来验证远程仓库是否已被添加。

总结

在 Git 中获取远程分支是开发环境中协作的一个重要方面。

按照本文概述的步骤，你就能获取其他协作者在远程分支上所做的改动，并将它们与本地仓库合并。这样，你就能在 Git 仓库的不同分支上工作，并与其他开发人员有效协作。

开启学习之旅，浏览 200 多篇关于 web 开发的专业文章。查看我的博客，获取更多精彩内容。

祝你编码愉快！

开发人员的工具箱中最强大的工具之一是git rebase。但它因复杂和被误解而臭名昭著。

事实上，如果你了解它的实际作用，git rebase是一个非常优雅和直接的工具，可以实现 Git 中许多不同的事情。

在之前的文章中，你了解了 什么是 Git diff、什么是 merge以及 Git 如何解决合并冲突(merge conflicts)。在这篇文章中，你将了解什么是 Git rebase，为什么它与 merge 不同，以及如何放心地进行 rebase 💪🏻

开始前的说明

1. 我还制作了一个涵盖本文内容的视频。如果你想在阅读的同时观看视频，可以在这里查看。
2. 如果你想玩玩我用的软件库，自己试试这些命令，这里是软件库。
3. 我正在写一本关于 Git 的书！你有兴趣阅读初始版本并提供反馈吗？请给我发邮件

好了，你准备好了吗？

简要回顾 Git Merge🤔

从底层来讲，git rebase和git merge是非常、非常不同的事情。那为什么人们一直在比较它们呢？

原因是它们的用法。使用 Git 时，我们通常在不同的分支工作，并对这些分支进行修改。

在以前的教程中，我举了一个例子，John 和 paul（披头士乐队）正在共同创作一首新歌。他们从main分支开始，然后各自发散，修改歌词并提交他们的修改。

然后，两人想整合他们的改动，这是使用 Git 工作时经常发生的事情。

分歧（diverged）的历史 - paul_branch 和 john_branch 与 main分歧（来源：Brief）

在 Git 中，有两种主要的方式来整合不同分支的变化，或者说，不同的提交和提交历史。它们是 merge 和 rebase。

在之前的教程中，我们对 git merge 有了相当的了解。我们看到，在执行合并时，我们会创建一个 合并提交（merge Commit）,这个提交的内容是两个分支的组合，它也有两个父分支，每个分支一个。

所以，假设你在分支john_branch上（假设是上图中描述的历史），你运行git merge paul_branch。你会得到这样的状态--在john_branch上，有一个新的提交，有两个父分支。第一个是合并前HEAD指向的john_branch分支上的提交，本例中是 Commit 6。第二个是 paul_branch 所指向的提交 Commit 9。

运行git merge paul_branch的结果：一个新的合并提交（Merge Commit），有两个父分支（Source：Brief）

再看一下历史图：你创建了一个 分歧的（diverged） 历史。你实际上可以看到它在哪里分叉（branched），在哪里又合并了（merged）。

所以当使用git merge时，你并没有重写历史--而是在现有的历史中增加一个提交。具体来说，是在现有的历史中增加一个提交，创造一个分歧（diverged）的历史。

git rebase 和 git merge 有什么区别🤔

当使用git rebase时，会发生不同的情况。🥁

让我们从大的方面开始：如果你在paul_branch上，并使用git rebase john_branch，Git 会去找 John 的分支和 Paul 的分支的共同祖先。然后把 Paul 分支的提交中引入的补丁，应用到 John 分支。

所以在这里，你用rebase把在一个分支，Paul 的分支上提交的修改，在另一个分支john_branch上重演（replay）。

运行git rebase john_branch的结果：paul_branch上的提交被 重演（replay） 到 john_branch之上（来源：Brief）

等等，那是什么意思？🤔

我们现在将一点一点地进行分析，以确保你完全理解在底层发生的事情 😎

以 cherry-pick 作为 Rebase 的基础

使用 git rebase 可以理解为执行 git cherry-pick，git cherry-pick 是一个命令，它接受一个提交，计算出该提交引入的补丁（patch），即计算出父提交和该提交之间的差异，并且通过 cherry-pick 将这个差异重演（replay）出来。

让我们手动来做这个。

如果我们通过执行git diff main <SHA_OF_Commit_5>来看看 Commit 5 引入的差异:

运行 git diff 来观察 Commit 5 引入的补丁（Source：Brief）

如果你想玩玩我用的版本库，自己试试这些命令，这里是版本库。

你可以看到，在这个提交中，John 开始创作一首名为 Lucy in the Sky with Diamonds 的歌曲：

git diff的输出结果,Commit 5 引入的补丁(patch) (来源: Brief)

提醒一下，你也可以使用git show命令来获得同样的输出：

git show <SHA_OF_Commit_5>

现在，如果你cherry-pick这个提交，你将在活动分支(active branch)上专门引入这个改动。先切换到 "main":

git checkout main (or git switch main)

并创建另一个分支，只是为了明确:

git checkout -b my_branch (or git switch -c my_branch)

从 main 分支创建出 my_branch 分支 (源自: Brief)

cherry-pick这个提交(Commit):

git cherry-pick <SHA_OF_Commit_5>

使用 cherry-pick 将 Commit 5 中引入的修改应用到 main上（来源：Brief）
考虑一下日志（git lol的输出）：

git lol的输出（源自：Brief）

(git lol是我加在 Git 上的一个别名，用来以图形的方式直观地查看历史。你可以找到它这里)。

你似乎是复制了 Commit 5。请记住，尽管它有相同的提交信息，并引入了相同的修改，甚至在这种情况下指向与原始 Commit 5相同的树对象,它仍然是一个不同的提交对象，因为它是以不同的时间戳创建的。

看一下这些变化，使用git show HEAD:

git show HEAD的输出结果（Source：Brief）

它们与 Commit 5 的相同。

当然，如果你看一下这个文件（比如，用nano lucy_in_the_sky_with_diamonds.md），它的状态和最初的 Commit 5 之后的状态是一样的。

酷! 😎

好了，现在你可以删除新的分支，这样它就不会每次都出现在你的历史记录上:

git checkout main
git branch -D my_branch

在 cherry-pick 之外– 如何使用 git rebase

你可以把 git rebase 看成是一个接一个地执行多个 cherry-pick 的方法，也就是 重放(replay)多个提交。这不是rebase唯一能做的事情，但它是我们解释的一个很好的起点。
是时候玩玩git rebase了！ 👏🏻👏🏻

之前，你把 paul_branch 合并到了 john_branch。如果把paul_branch rebased john_branch，会发生什么呢？你会得到一个非常不同的历史(history)。

从本质上说，就好像我们把在paul_branch上的提交中引入的变更，在john_branch上重放(replay)一样。结果就是一个 线性 历史。[译者注：git log --graph 输出历史的是直线的，没有分叉]

为了理解这个过程，我将提供一个高层视图，然后深入到每一步。将一个分支重定向(rebasing)到另一个分支之上的过程如下:

1. 找到共同的祖先(ancestor)。
2. 确定要 重放(replayed)的提交。
3. 对于每个提交X，计算diff(parent(X), X)，并存储为patch(X)。
4. 移动 HEAD 到新的基(base).
5. 在目标分支上按顺序应用生成的补丁。每次都用新的状态创建一个新的提交对象。

在新提交中使用与现有提交相同的变更集的过程也被称为 重放(replaying)，我们已经使用过这个术语。

是时候亲手操作 Rebase 了🙌🏻

从 Paul 的分支开始：

git checkout paul_branch

这是提交历史：

执行git rebase前的提交历史（Source: Brief）

现在，进入激动人心的部分：

git rebase john_branch

查看历史:

rebase 后的历史（Source: Brief）

( gg 是我的 视频 中介绍的一个外部工具的别名). [译者注: git-graph]

因此，使用 git merge 你增加了历史(history)，而使用 git rebase, 你改写了历史。你创建了新的提交对象。此外，结果是一个线性的历史图,而不是一个发散图。

rebase 后的历史（来源：Brief）

本质上，我们 复制 了 paul_branch 上 Commit 4 之后的提交，并将它们 粘贴到了 john_branch 上。

这个命令被称为 rebase，因为它改变了运行它的分支的基点提交(base Commit)。也就是说，在运行git rebase之前，paul_branch的基点提交是 Commit 4,因为这是分支 诞生(born) 的地方（从main开始）。使用 rebase 时，你要求 Git 给它另一个基点，也就是假装它是从 Commit 6 诞生的。

为此，Git 将原来的 Commit 7 的改动 重放(replayed)到 Commit 6 上，然后创建了一个新的提交对象。这个对象与原来的 Commit 7 有三点不同:

1. 时间戳不同。
2. 它有不同的父提交, Commit 6 而不是 Commit 4。
3. 它指向的tree object 是不同的,因为修改被引入到了 Commit 6 指向的树，而不是 Commit 4 指向的树。

注意这里的最后一个提交，Commit 9。它所代表的快照 (也就是它所指向的 tree) 与合并两个分支后得到的树完全相同。Git 仓库中文件的状态与使用 git merge 时一样。不同的只是历史，当然还有提交对象。

现在，您可以简单地使用:

git checkout main
git merge paul_branch

Hm…… 如果运行最后这条命令，会发生什么？🤔 在查看了 main 之后，再次查看提交历史:

rebase 后，再切换到 main 分支的历史 (Source: Brief)

合并 paul_branch 到 main 会发生什么?

事实上，Git 可以简单地执行快进合并(fast-forward merge)，因为历史是完全线性的（如果你需要关于快进合并的提醒，请查看 this post ）。因此，main 和 paul_branch 现在指向同一个提交:

快进合并(fast-forward merge)的结果 (Source: Brief)

Advanced Rebasing in Git💪🏻

既然你已经了解了 rebase 的基础知识，现在就该考虑更高级的情况了，在这些情况下，rebase 命令的附加选项和参数就会派上用场。

在前面的例子中，当你只说了 rebase（没有附加选项），Git 就会重放(replayed) 从共同祖先到当前分支顶端的所有提交。

但是，rebase 是一个超级强大的命令，它能够...，改写历史。如果你想修改历史，把它变成你自己的，它就会派上用场。

让 main 再次指向 Commit 4，撤销上次的合并:

git reset -–hard <ORIGINAL_Commit 4>

撤销(undoing) 上次合并操作 (Source: Brief)

通过 rebase 进行撤销:

git checkout paul_branch
git reset -–hard <ORIGINAL_Commit 9>

撤销 rebase 操作 (Source: Brief)

请注意，您的历史记录与以前完全相同:

在 撤销 rebase 操作后可视化历史记录 (Source: Brief)

需要再次说明的是，Commit 9 并不是在当前 HEAD 无法访问时就消失了。相反，它仍然保存在对象数据库中。当你使用 git reset 将 HEAD 改为指向该提交(Commit 9)时，你就能检索到它以及它的父提交，因为它们也存储在数据库中。很酷吧？😎

好了，快速查看 Paul 介绍的更改:

git show HEAD

git show HEAD 显示了 Commit 9 引入的补丁 (Source: Brief)

在提交图(Commit graph) 中继续向后退:

git show HEAD~

git show HEAD~（与 git show HEAD~1相同）显示 Commit 8 引入的补丁 (Source: Brief)

更进一步:

git show HEAD~2

git show HEAD~2 显示 Commit 7 引入的补丁 (Source: Brief)

所以，这些改动很好，但也许 Paul 并不想要这样的历史记录。相反，他想让 Commit 7 和 Commit 8 中的改动看起来像是一次提交。

为此，你可以使用 interactive(交互式) rebase。为此，我们在 rebase 命令中添加 -i（或 --interactive）选项:

git rebase -i <SHA_OF_Commit_4>

或者，由于 main 指向 Commit 4，我们只需运行:

git rebase -i main

通过运行这条命令，你会告诉 Git 使用一个新的基(base) Commit 4。这样，Git 就会回溯到所有在 Commit 4之后提交的、从当前的 HEAD 可以到达的提交，并重放(replay) 这些提交。

对于每一个被重放的提交，Git 都会询问我们想对它做什么:

git rebase -i main 会提示您选择对每次提交的处理方式 (Source: Brief)

在这种情况下，将提交视为补丁是很有用的。也就是说，Commit 7 就是 Commit 7 在其父版本之上引入的补丁"。

一种选项是使用 pick。这是默认行为，它告诉 Git 重放该提交中引入的改动。在这种情况下，如果保持原样, pick 所有提交,就会得到相同的历史记录，Git 甚至不会创建新的提交对象。

另一个选项是 squash。一个 squashed 提交的内容会被 折叠(folded) 到它之前的提交内容中。因此，在我们的例子中，Paul 想把 Commit 8 压缩成 Commit 7:

Commit 8 压缩成 Commit 7 (Source: Brief)

如你所见，git rebase -i 提供了更多选项，但我们不会在这篇文章中一一介绍。如果允许 rebase 运行，系统会提示你为新创建的提交（即引入了 Commit 7和 Commit 8改动的提交）选择提交信息：

提供提交信息: Commits 7+8 (Source: Brief)

再看历史:

运行 interactive rebase 后的历史 (Source: Brief)

正如我们想要的那样!我们在paul_branch分支上有 Commit 9 (当然,它是一个不同的对象,与原来的 Commit 9 不同)。它指向 Commit 7+8,这是一个单独的提交,引入了原来 Commit 7和 Commit 8 的所有变更。这个提交的父提交是 Commit 4,也就是main分支当前所指向的提交。你现在在john_branch分支上。

interactive rebase 后可视化的历史 (Source: Brief)

哇哦，是不是很酷？ 😎

git rebase 允许你无限制地控制任何分支的形态。你可以用它来重新排序提交，或删除错误的改动，或回溯修改改动。或者，你也可以把分支的基础移到另一个提交上，任何你想要的提交。

How to Use the --onto Switch of git rebase

让我们再看一个例子。再次进入 main:

git checkout main

然后删除 paul_branch 和 john_branch 分支 ，这样在提交图中就看不到它们了:

git branch -D paul_branch
git branch -D john_branch

现在从 main 分支基础上开一个新的分支:

git checkout -b new_branch

从 main 分支上创建一个新分支(new_branch) (Source: Brief)

一个干净的历史记录, 从 main 分支上创建的 new_branch 分支。 (Source: Brief)

现在，在此处添加一些更改并提交:

nano code.py

new_branch 分支上添加 code.py 文件（Source: Brief）

git add code.py
git Commit -m "Commit 10"

切回 main 分支:

git checkout main

并引入另一个变化:

在文件开头添加了文档字符串 (Source: Brief)

是时候提交这些更改:

git add code.py
git Commit -m "Commit 11"

另一个变化:

添加 @Author 的描述 (Source: Brief)

提交变化:

git add code.py
git Commit -m "Commit 12"

哦，等等，现在我意识到，我是想让你把 Commit 11 中引入的更改作为 new_branch 的一部分。唉。你能怎么办呢？ 🤔

回顾 git 提交历史:

Commit 12 后的历史 (Source: Brief)

我希望 Commit 10 不只出现在 main 分支上，而是同时出现在 main 分支和 new_branch 上。从视觉上看，我希望把它移到图的下面:

如图所示, 我想让你 push "Commit 10" (Source: Brief)

你能看清楚我意图? 😇

我们清楚, rebase 允许我们重新使用 new_branch 分支引入变更,也就是 Commit 10 引入的变更,就像这些变更最初是在 Commit 11上进行的,而不是在 Commit 4 上进行的。

要实现这个目标,你可以使用 git rebase 的其他参数。你可以告诉 Git,你想要取 main 分支和 new_branch 分支的共同祖先 Commit 4 之后引入的所有历史变更,并将这部分历史变更的新的基础设置为 Commit 11。要实现这个目的,可以使用:

git rebase -–onto <SHA_OF_Commit_11> main new_branch

重置前后的历史记录, Commit 10 已经被推送(pushed) (Source: Brief)

看看我们美丽的历史! 😍

重置前后的历史记录, `Commit 10 已经被推送(pushed) (Source: Brief)

让我们再看一个例子。

假设我开始在一个分支上工作，却犯了错误，从 feature_branch_1 而不是从 main 开始。
因此，要模拟这种情况，请创建 feature_branch_1:

git checkout main
git checkout -b feature_branch_1

删除 new_branch 后，图表中就看不到它了:

git branch -D new_branch

创建一个简单的 Python 文件 1.py:

新文件 1.py,里面有 print('Hello world!') (Source: Brief)

提交此文件:

git add 1.py
git Commit -m  "Commit 13"

现在(错误地)从 feature_branch_1开出新分支:

git checkout -b feature_branch_2

创建新文件 2.py:

创建的 2.py (Source: Brief)

提交该文件:

git add 2.py
git Commit -m  "Commit 14"

再添加一些代码到文件 2.py:

修改 2.py (Source: Brief)

提交该变化:

git add 2.py
git Commit -m  "Commit 15"

到目前为止，您应该有这样的历史记录:

引入 Commit 15 的历史 (Source: Brief)

切回 feature_branch_1 分支，编辑文件 1.py:

git checkout feature_branch_1

修改 1.py (Source: Brief)

提交修改:

git add 1.py
git Commit -m  "Commit 16"

你的历史记录应该是这样的:

引入 Commit 16 后的历史 (Source: Brief)

说现在你意识到了，你犯了一个错误。你实际上想让 feature_branch_2 从 main 分支中分出，而不是从 feature_branch_1 中分出。

怎样才能做到这一点呢？🤔

试着根据历史图和你所学到的关于 rebase 命令的 --onto 参数来思考一下。

你想把 feature_branch_2 上第一个提交的父分支，也就是 commit 14，替换到 main 分支的顶部，这里是 commit 12，而不是 feature_branch_1 的起点，这里是 commit 13。因此，你将再次创建一个 新的基点，这次是在feature_branch_2上的第一个 Commit。

你想要在 Commit 14 和 Commit 15 之间进行移动（来源：Brief）

你打算怎么做呢？

第一，切到 feature_branch_2 分支：

git checkout feature_branch_2

然后你可以执行:

git rebase -–onto main <SHA_OF_Commit_13>

因此，您的 feature_branch_2 是基于 main 分支而不是 feature_branch_1 分支：

执行变基(rebase)后的提交历史（来源：Brief）

该命令的语法是:

git rebase --onto <new_parent> <old_parent>

如何在一个单独的分支上执行变基

在查看单个分支的历史时，您也可以使用 git rebase。

让我们看看你是否能在这里帮助我。

假设我是从 feature_branch_2 开始工作的，具体来说是编辑了文件 code.py。我首先将所有字符串的引号从单引号改为双引号：

在 code.py 中将 ' 改为 "（来源：Brief）

然后，我将其进行了暂存（staged）并提交（Committed）：

git add code.py
git Commit -m "Commit 17"

然后我决定在文件开头添加一个新函数:

添加函数 another_feature (Source: Brief)

然后，我将其进行了暂存（staged）并提交（Committed）:

git add code.py
git Commit -m "Commit 18"

现在我意识到我实际上忘记了将 main 用双引号包裹起来（你可能已经注意到了），所以我也做了这个改动:

将 '__main__' 改成 "__main__" (Source: Brief)

当然, 我将其进行了暂存（staged）并提交（Committed）:

git add code.py
git Commit -m "Commit 19"

现在，让我们来看看历史:

引入 Commit 19 之后的提交记录 (Source: Brief)

这样看起来不太好，对吧？我的意思是，Commit 17 和 Commit 19（将'改为"）是相关的，但它们被无关的 Commit 18（我在那里添加了一个新函数）分隔开了。我们能做些什么？🤔 你能帮我吗？

直觉上，我想在这里修改历史:

这些是我想要修改的提交 (Source: Brief)

那么，你会怎么做呢？

你说得对！👏🏻

我可以在 commit 15的基础上，将历史记录从 commit 17 变基(rebase)为 commit 19。要做到这一点:

git rebase --interactive --onto <SHA_OF_Commit_15> <SHA_OF_Commit_15>

请注意，我指定了 Commit 15 作为提交范围的起点，不包括本次提交。而且我不需要明确指定 HEAD 作为最后一个参数。

在单个分支上使用 rebase --onto (Source: Brief)

按照您的建议运行 rebase 命令后（谢谢！😇），我看到了下面的显示：

交互式变基 (Source: Brief)

那我该怎么办呢？我想把 Commit 19 放在 Commit 18 之前，这样它就紧跟在 Commit 17之后。我还可以进一步将它们合并在一起，就像这样：

交互式 rebase - 调整提交顺序并合并 (Source: Brief)

现在当我被提示输入提交信息时，我可以提供信息 Commit 17+19:

输入 Commit 信息 (Source: Brief)

现在，让我们来看看我们美丽的提交历史吧:

由此产生的提交历史 (Source: Brief)

再次感谢！ 🙌🏻

更多变基用户案例 + 更多实践

现在，我希望你已经对 变基(rebase) 的语法感到得心应手了。要真正理解它，最好的办法是理解各种案例，并自己想办法解决它们。

对于接下来的用例，我强烈建议你在我介绍完每个用例后就停止阅读，然后尝试自己解决。

如何排除 Commits

假设您在另一个软件仓库中有这样的历史记录:

别的 Commit 提交历史 (Source: Brief)

在使用之前，先将 tag 存储为 original_Commit_f，以便稍后再查看:

git tag original_Commit_f

现在，你实际上并不希望包含 Commit C和 Commit D 中的更改。你可以像之前一样使用交互式 rebase，删除它们的改动。或者，也可以再次使用 git rebase--onto。如何使用 --onto来 移除(remove) 这两个提交(commit)呢？

你可以在 commit B的基础上重建 HEAD，原来的父提交是 commit D，现在应该是 commit B,看提交历史记录：

再次回顾提交历史 (Source: Brief)

rebase 使 Commit B 成为 Commit E 的 基(base)，意味着 移动(moving) Commit E和 Commit F，并赋予它们另一个 基(base) -- Commit B。你能自己想出这个命令吗？

git rebase --onto <SHA_OF_Commit_B> <SHA_OF_Commit_D> HEAD

请注意，使用上述语法不会移动 main 指向新的 Commit，因此结果是一个 分离的(detached) HEAD。如果你使用 gg 或其他显示分支历史的工具，这可能会让你感到困惑：

用 --onto 变基(rebase) 会导致一个分离(detached)的 HEAD （来源：Brief)

但如果使用 git log（或我的别名 git lol），就能看到想要的历史记录：

由此形成的提交历史 (Source: Brief)

我不知道你怎么想，但这些事情让我非常开心。 😊😇

顺便说一下，你可以省略前面命令中的 HEAD，因为这是第三个参数的默认值。因此，只需使用:

git rebase --onto <SHA_OF_Commit_B> <SHA_OF_Commit_D>

会有同样的效果。最后一个参数实际上是告诉 Git 当前提交序列的终点在哪里。所以有三个参数的 git rebase --onto 的语法是

git rebase --onto <new_parent> <old_parent> <until>

如何在不同分支间移动提交

因此，让我们回到之前的提交历史:

git checkout original_Commit_f

现在我只想让 commit E位于基于 commit B 的分支上。也就是说，我想建立一个新的分支，从 commit B分支出去，其中只有 commit E。

考虑到 commit E 的当前历史 (Source: Brief)

那么，这意味着什么呢？请看上图。我应该变基(rebase)哪个提交（或哪些提交），哪个提交是新的基础(base)？

我知道在这里我可以让你来 😉

我想要的是取出 commit E，只有这个提交，并将其基础更改为 commit B。换句话说，将commit E引入的更改 重放(replay) 到 commit B上。

你能将这个逻辑应用到 git rebase 的语法中吗？

这里是语法（这次我用 <Commit_B> 代替 <SHA_OF_Commit_B>，为了简洁起见）：

git rebase –-onto <Commit_B> <Commit_D> <Commit_E>

现在的提交历史是这样的:

变基后的提交历史 (Source: Brief)

棒极了！

关于冲突的说明

请注意，进行变基时可能会遇到与合并时一样的冲突。可能会出现冲突，因为在变基时，您试图将补丁(patches)应用在不同的基础上，也许这些补丁(patches)并不适用。

例如，再次考虑之前的代码库，特别是考虑由 main 指向的 commit 12 引入的更改：

git show main

在 Commit 12 中引入的补丁 (Source: Brief)

我在上一篇文章中已经详细介绍了 git diff 的格式，但为了快速提醒大家，这个 Commit 会指示 Git 在两行上下文之后添加一行：

```shell
This is a sample file

而在这三行上下文之前:

```
def new_feature():
  print('new feature')

假设您正试图将 commit 12 重定向到另一个提交上。如果由于某种原因，这些上下文行并不存在于您要重置的 Commit 上的补丁中，那么就会产生冲突。要进一步了解冲突以及如何解决冲突，请参阅 本指南。

放眼全局

比较变基(rebase)和合并(merge)（来源：Brief）

在本指南的开始，我提到了 git merge 和 git rebase 之间的相似性：它们都用于整合不同历史中引入的更改。

但是，正如你现在所知，它们在操作方式上有很大的不同。合并导致了一个分叉的历史，而变基导致了一个线性的历史。在两种情况下都可能出现冲突。表格中还有一列需要特别关注。

现在你知道了什么是 Git 变基（rebase），以及如何使用交互式变基或 rebase --onto，希望你理解，git rebase 是一个超级强大的工具。然而，与合并相比，它有一个巨大的缺点。

Git 变基改变了提交历史。

这意味着你不应该对存在于你本地代码库之外的并且其他人可能以此为基础进行提交的提交进行变基。

换句话说，如果问题涉及的只有你在本地创建的提交，那就继续使用变基，尽情操作。

但是，如果这些提交已经被推送，这可能会导致一个巨大的问题，因为其他人可能依赖这些提交，而后来你覆盖了它们，然后你和他们将拥有存储库的不同版本。

这与我们所见的不修改历史的 merge 不同。

例如，考虑最后一个情况，我们进行了变基，导致了这样的提交历史:

变基后的提交历史（来源：Brief）

现在，假设我已经将这个分支推送到远程仓库。在我推送了这个分支之后，另一个开发人员拉取了它，并从 commit C创建了一个新分支。另一个开发人员不知道与此同时，我正在本地对我的分支进行变基，并且稍后会再次推送它。

这导致了一个不一致：另一个开发人员从一个在我的代码库副本上不再可用的提交中进行工作。

我不会在本指南中详细阐述这到底会导致什么，因为我的主要观点是你绝对应该避免这种情况。如果你对实际会发生什么感兴趣，我会在下面留下一个有用资源的链接。现在，让我们总结一下我们所讨论的内容。

回顾

在本教程中，你将学习到 git rebase 这个在 Git 中重写历史的超级强大工具。你考虑了一些git rebase可能有用的用例，以及如何使用一个、两个或三个参数，使用或不使用--onto开关。

我希望我能让你相信，git rebase 不仅功能强大，而且一旦掌握了要领，使用起来也很简单。它是一个 复制粘贴（copy-paste） 提交（或者更准确地说，是补丁）的工具。它是一个非常有用的工具。

其他参考资料

• Git Internals YouTube 播放列表 - Brief（我的 YouTube 频道）
• Omer 上一篇关于 Git 内部结构的文章
• Omer 的 Git UNDO 教程--用 Git 重写历史
• 关于变基的 Git 文档
• 分支和 rebase 的强大功能
• 交互式变基
• Git rebase--onto

关于作者

Omer Rosenbaum 是 Swimm 的首席技术官。他是Brief YouTube 频道 的作者。他也是一位网络安全培训专家，创立了 Checkpoint Security Academy。他是 《计算机网络》（希伯来语版） 的作者。你可以在 Twitter 上找到他。

当与团队一起做一个项目或你自己做一个项目时，通过版本控制来跟踪代码库的变化是很重要的。

Git 为你提供了不同的命令来跟踪文件变化。这些命令将使你能够与其他开发人员协作、访问文件历史、管理代码，等等。

在这篇文章中，你将学习如何恢复和重置一个文件或提交到之前的提交。

我们将使用一些简单的 HTML 代码来演示如何使用 Git 恢复和重置到之前的提交。

让我们开始吧！

如何重置一个文件或提交

在本节中，你将学习如何使用以下命令来恢复/重置一个文件或提交：

• git revert
• git reset

如何使用 git revert 命令恢复文件或提交

下面是 git revert 命令的语法：

git revert [commit ID]

下面是我们将使用的代码：

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Document</title>
  </head>
  <body>
    <h1>Hello World!</h1>
  </body>
</html>

让我们假设上面的文件是每个在项目上工作的开发人员的代码库的当前状态。

我们将对该文件做一些修改，然后添加、提交和推送这些修改，即：

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Document</title>
  </head>
  <body>
    <h1>Hello World!</h1>

    <ul>
        <li>Red</li>
        <li>Yellow</li>
        <li>Orange</li>
    </ul>
    
  </body>
</html>

我们已经在代码中添加了一个颜色列表。让我们用下面的命令推送这些变化：

git add .
git commit -m "added colors to the HTML file"
git push -u origin main

现在，新的变化已经为在特定代码分支上工作的所有人更新了。

但如果添加的颜色是应该在未来为用户发布的功能的一部分呢？你提前发布了这个功能，就犯了一个错误。

要恢复到之前的提交，你需要那个特定提交的 ID。要得到提交 ID，请执行下面的命令：

git log

该命令会显示每个提交的 ID、作者和日期。它应该是这样的：

在我们的例子中，提交 ID 是 785dd5a6dd0f1ebd9e06045df787d8d28fd38285。

所以，要重置文件，就用 git revert [commit ID]，即：

git revert 785dd5a6dd0f1ebd9e06045df787d8d28fd38285

上面的命令将重置某个特定提交之前对文件所做的所有修改。下面是现在的 HTML 文件：

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Document</title>
  </head>
  <body>
    <h1>Hello World!</h1>
  </body>
</html>

现在你可以推送这个新状态了。

请注意，git revert 命令并不从远程仓库中删除被恢复的提交。相反，它为被恢复的改动创建一个新的提交。

这意味着你将拥有被恢复的提交的历史和包含被恢复的修改的文件的新提交。

如何使用 git reset 命令重置文件或提交

git reset 命令也可以用来恢复修改。请看下面的提交历史：

上面的图片显示了所有的提交历史——从第一次提交到最后一节的还原提交。

如果我们用 git reset [commit ID] 来还原某个特定的提交，之后的其他提交都会从提交历史中被删除。

下面是一个例子：

git reset c1e4962a9b355f023c250609cfa9303a67b3063e

使用第一次提交的提交 ID，我们回到了第一次提交的状态。

运行 git log 命令，你会有一个这样的提交历史：

虽然你已经成功地恢复到了第一次提交，但代码中其他提交的历史却被抹去了。这在与其他开发者合作时，会产生非常负面的影响。

摘要

在这篇文章中，我们谈到了两个重要的 Git 命令，即 git revert 和 git reset，用于撤销 Git 仓库中的修改。

这两个命令都能让你回到代码库中之前的指定状态，但后果不同。

git revert 命令会恢复到指定的提交，但会保留代码库中其他所有提交的历史，并为恢复的改动创建一个新的提交。这是一种在与他人合作时撤销修改的更有效的方式。

另外，git reset 命令会恢复到指定的提交，然后删除指定提交之后的所有提交。

为了安全起见，在撤销有其他开发者工作的 repo 中的修改时，请使用 git revert。

你可以在撤销修改后想完全删除提交的情况下使用 git reset。

Happy coding!

Git 是一个免费的开源工具。具体来说，它是当今软件开发中最流行的版本控制系统。

Git 允许你跟踪和维护一个编程项目的不同版本。

有了 Git，开发者和技术团队可以在一个项目上进行协作和工作。

多个开发者可以同时在项目的相同或不同部分工作，而不互相干扰，提高生产力和效率。

借助 Git 提供的内置功能和工具，开发者可以同时进行协作，并在他们的环境中工作。其中一个功能就是分支（branch）。

什么是 Git 中的分支

Git 中的分支是一个独立的、安全的、与主项目相分离的开发区域。

分支允许开发人员开发和测试新的功能，修复错误，实验新的想法，并减少破坏代码库中稳定代码的风险。

本地分支与远程分支--有什么区别

在 Git 中，有两种类型的分支：本地分支（local branch）和远程分支（remote branch）。

一个本地分支只存在于你的本地机器上。

所有你引入并提交到本地仓库的修改都只存储在你的本地系统上。它们提供了一种实验、修复错误和开发新功能而不影响主代码库的方式。

要创建一个本地分支，可以使用 git branch <branch-name> 命令，其中 branch-name 是新分支的名称。

例如，如果你想创建一个名为 "test "的新分支，你可以使用以下命令：

git branch test

你可以使用git checkout命令切换到新的分支，并创建你想要的修改：

git checkout test

要查看本地分支的列表，请使用git branch命令。

说了这么多，你不能在本地分支上与其他开发者协作。这时，远程分支就派上用场了。

远程分支是开发者在同一个项目上同时协作的方式。

远程分支存在于一个远程仓库中（通常称为 origin），托管在 GitHub 等平台上。

当你向本地分支提交了修改，你可以使用git push <remote> <local>语法将本地分支推送到远程仓库（origin）。然后，其他人就可以看到你的代码了。

git push -u origin test

Git 会在远程仓库中创建一个本地分支的副本。这个副本被称为远程分支。

要查看项目中所有远程分支的列表，请使用git branch -r命令。

如何在 Git 中签出一个远程分支

你可能需要访问另一个开发者创建的分支，以进行审查或协作。

这个分支不在你的本地系统上,它是存储在远程仓库上的一个远程分支。

问题是，Git 并不自动允许你在别人的分支上工作。

相反，你需要创建一个本地副本，映射你要处理的远程分支，然后在本地进行修改。

让我们看看下面几节中你需要采取的步骤。

如何获取所有远程分支

首先，你需要使用git fetch命令获取必要的分支数据，以及远程存储库的名称：

git fetch origin

这个命令将从远程仓库下载最新的修改（包括远程分支）到你的本地机器。

如果你有一个不同的远程名称，用它替换origin。

如何查看可检出的分支

接下来，要查看可供签出的分支列表，请使用以下命令：

git branch -r

-r（是 remote 的缩写）选项告诉 Git 列出远程分支。

该命令的输出将是一个所有可供签出的远程分支的列表。你会看到分支名称前有remotes/origin的前缀。

如何检出远程分支的情况

你不能直接对你感兴趣的远程分支进行修改，你需要一个本地副本。

你需要检出(checkout)你感兴趣的分支，这样你就可以开始在本地进行你想做的修改。

要做到这一点，使用git checkout命令，加上-b（代表分支）选项。语法是这样的：

git checkout -b <new-local-branch-name> origin/<remote-branch-name>

因此，如果你想获得远程分支new-feature的副本，你应该做以下事情：

git checkout -b new-feature origin/new-feature

上面的命令在你的机器上创建了一个新的本地副本，它基于并连接到远程分支。

它创建了一个名为 "new-feature "的新分支，检出（checkout）该分支，并将 origin/new-feature 中的修改拉到新分支中。

现在你可以向origin/new-feature推送新的提交。

谢谢你阅读本文

现在你知道如何在 Git 中检出和使用远程分支了。Happy coding!

Git 是一个流行的版本控制系统。开发人员通过它可以在项目上进行协作。

Git 允许你跟踪你在一段时间内对项目所做的修改。除此之外，如果你想撤销某个改动，它还可以让你恢复到以前的版本。

Git 的工作方式是，你用 git add 命令在项目中添加文件，然后用 git commit 命令提交文件。

当你作为团队的一员在一个项目上工作时，有时你不想与他人分享项目的某些文件或部分。

换句话说，你不想把这些特定的文件包含或提交到项目的主版本中。这就是为什么你可能不想在 git add 命令中使用句号 .，因为这样做会提交当前 Git 目录中的每一个文件。

当你使用 git commit 命令时，每一个文件都会被添加——这也包括那些不需要或不应该提交的文件。

你可能想让 Git 忽略特定的文件，但没有 git ignore 命令来实现这一目的。

那么，如何告诉 Git 忽略和不追踪特定的文件呢？用一个 .gitignore 文件。

在这篇文章中，你将了解什么是 .gitignore 文件，如何创建它，以及如何使用它来忽略文件和文件夹。你还会看到如何忽略一个先前提交的文件。

以下是我们要介绍的内容：

1. 什么是 .gitignore 文件
2. 如何创建一个 .gitignore 文件
3. 在 .gitignore 文件中包含什么
4. 如何在 Git 中忽略一个文件和文件夹
5. 如何忽略一个先前提交的文件

什么是 .gitignore 文件？.gitignore 文件是用来做什么的？

在任何当前工作的 Git 仓库中，每个文件都是这样的：

• 追踪的（tracked）- 这些是 Git 所知道的所有文件或目录。这些是新添加（用 git add 添加）和提交（用 git commit 提交）到主仓库的文件和目录。
• 未被追踪的（untracked） - 这些是在工作目录中创建的，但还没有被暂存（或用 git add 命令添加）的任何新文件或目录。
• 被忽略的（ignored） - 这些是 Git 知道的要全部排除、忽略或在 Git 仓库中不需要注意的所有文件或目录。本质上，这是一种告诉 Git 哪些未被追踪的文件应该保持不被追踪并且永远不会被提交的方法。

所有被忽略的文件都会被保存在一个 .gitignore 文件中。

.gitignore 文件是一个纯文本文件，包含了项目中所有指定的文件和文件夹的列表，这些文件和文件夹是 Git 应该忽略和不追踪的。

在 .gitignore 中，你可以通过提及特定文件或文件夹的名称或模式来告诉 Git 只忽略一个文件或一个文件夹。你也可以用同样的方法告诉 Git 忽略多个文件或文件夹。

如何创建一个 .gitignore 文件？

通常，一个 .gitignore 文件会被放在仓库的根目录下。根目录也被称为父目录和当前工作目录。根目录包含了组成项目的所有文件和其他文件夹。

也就是说，你可以把它放在版本库的任何文件夹中。你甚至可以有多个 .gitignore 文件。

要在基于 Unix 的系统（如 macOS 或 Linux）上用命令行创建一个 .gitignore 文件，打开终端程序（如 macOS 上的 Terminal.app）。然后，用 cd 命令导航到包含项目的根文件夹，并输入以下命令，为你的目录创建一个 .gitignore 文件：

touch .gitignore

名字前面有点（.）的文件默认是隐藏的。

当单独使用 ls 命令时，隐藏的文件是不可见的。要从命令行查看所有的文件--包括隐藏的文件--请在 ls 命令中使用 -a 标志，如图所示：

ls -a

在 .gitignore 文件中应包括什么？

你应该考虑添加到 .gitignore 文件中的文件类型是任何不需要被提交的文件。

你可能出于安全原因不想提交它们，或者因为它们是你的本地文件，因此对与你在同一项目上工作的其他开发者来说是不必要的。

其中一些可能包括：

• 操作系统文件。每个操作系统（如 macOS、Windows 和 Linux）都会生成系统特定的隐藏文件，其他开发者不需要使用这些文件，因为他们的系统也会生成这些文件。例如，在 macOS 上，Finder 会生成一个 .DS_Store 文件，其中包括用户对文件夹的外观和显示的偏好，如图标的大小和位置。
• 由代码编辑器和 IDE（IDE 代表集成开发环境）等应用程序生成的配置文件。这些文件是为你、你的配置和你的偏好设置定制的。
• 从你的项目中使用的编程语言或框架自动生成的文件，以及编译后的代码特定文件，如 .o 文件。
• 由软件包管理器生成的文件夹，如 npm 的 node_modules 文件夹。这是一个用于保存和跟踪你在本地安装的每个软件包的依赖关系的文件夹。
• 包含敏感数据和个人信息的文件。这类文件的一些例子是含有你的凭证（用户名和密码）的文件和含有环境变量的文件，如 .env 文件（.env 文件含有需要保持安全和隐私的 API 密钥）。
• 运行时文件，如 .log 文件。它们提供关于操作系统的使用活动和错误的信息，以及在操作系统中发生的事件的历史。

如何在 Git 中忽略一个文件和文件夹

如果你想只忽略一个特定的文件，你需要提供该文件在项目根目录下的完整路径。

例如，如果你想忽略位于根目录下的 text.txt 文件，你可以做如下操作：

/text.txt

而如果你想忽略一个位于根目录下的 test 目录中的 text.txt 文件，你要做的是：

/test/text.txt

你也可以这样写上述内容：

test/text.txt

如果你想忽略所有具有特定名称的文件，你需要写出该文件的字面名称。

例如，如果你想忽略任何 text.txt 文件，你可以在 .gitignore 中添加以下内容：

text.txt

在这种情况下，你不需要提供特定文件的完整路径。这种模式将忽略位于项目中任何地方的具有该特定名称的所有文件。

要忽略整个目录及其所有内容，你需要包括目录的名称，并在最后加上斜线 /：

test/

这个命令将忽略位于你的项目中任何地方的名为 test 的目录（包括目录中的其他文件和其他子目录）。

需要注意的是，如果你只写一个文件的名字或者只写目录的名字而不写斜线 /，那么这个模式将同时匹配任何带有这个名字的文件或目录：

# 匹配任何名字带有 test 的文件和目录
test

如果你想忽略任何以特定单词开头的文件或目录怎么办？

例如，你想忽略所有名称以 img 开头的文件和目录。要做到这一点，你需要指定你想忽略的名称，后面跟着 * 通配符选择器，像这样：

img*

这个命令将忽略所有名字以 img 开头的文件和目录。

但是，如果你想忽略任何以特定单词结尾的文件或目录呢？

如果你想忽略所有以特定文件扩展名结尾的文件，你需要使用 * 通配符选择器，后面跟你想忽略的文件扩展名。

例如，如果你想忽略所有以 .md 文件扩展名结尾的 markdown 文件，你可以在你的 .gitignore 文件中添加以下内容：

*.md

这个模式将匹配位于项目中任何地方的以 .md 为扩展名的任何文件。

前面，你看到了如何忽略所有以特定后缀结尾的文件。当你想做一个例外，而有一个后缀的文件你不想忽略的时候，会发生什么？

假设你在你的 .gitignore 文件中添加了以下内容：

.md

这个模式会忽略所有以 .md 结尾的文件，但你不希望 Git 忽略一个 README.md 文件。

要做到这一点，你需要使用带有感叹号的否定模式，即 !，来排除一个本来会被忽略的文件：

# 忽略所有 .md 文件
.md

# 不忽略 README.md 文件
!README.md

在 .gitignore 文件中使用这两种模式，所有以 .md 结尾的文件都会被忽略，除了 README.md 文件。

需要记住的是，如果你忽略了整个目录，这个模式就不起作用。

例如，你忽略了所有的 test 目录：

test/

假设在一个 test 文件夹内，你有一个文件，example.md，你不想忽略它。

你不能像这样在一个被忽略的目录内排除一个文件：

# 忽略所有名字带有 test 的目录
test/

# 试图在一个被忽略的目录内排除一个文件是行不通的
!test/example.md

如何忽略以前提交的文件

当你创建一个新的仓库时，最好的做法是创建一个 .gitignore 文件，包含所有你想忽略的文件和不同的文件模式--在提交之前。

Git 只能忽略尚未提交到仓库的未被追踪的文件。

如果你过去已经提交了一个文件，但希望没有提交，会发生什么？

比如你不小心提交了一个存储环境变量的 .env 文件。

你首先需要更新 .gitignore 文件以包括 .env 文件：

# 给 .gitignore 添加 .env 文件
echo ".env" >> .gitignore

现在，你需要告诉 Git 不要追踪这个文件，把它从索引中删除：

git rm --cached .env

git rm 命令，连同 --cached 选项，从版本库中删除文件，但不删除实际的文件。这意味着该文件仍然在你的本地系统和工作目录中作为一个被忽略的文件。

git status 会显示该文件已不在版本库中，而输入 ls 命令会显示该文件存在于你的本地文件系统中。

如果你想从版本库和你的本地系统中删除该文件，省略 --cached 选项。

接下来，用 git add 命令将 .gitignore 添加到暂存区：

git add .gitignore

最后，用 git commit 命令提交 .gitignore 文件：

git commit -m "update ignored files"

总结

你现在知道了在 Git 中忽略文件和文件夹的基本知识。

希望这篇文章对你有所帮助。

想了解更多关于 Git 的信息，请查看以下免费资源：

• Git 和 GitHub 入门课程
• 面向专业人士的 Git 教程 - 掌握 Git 版本控制的工具和概念
• 高级 Git 教程 - 交互式 Rebase、Cherry-Picking、Reflog、Submodules 以及更多

感谢阅读，happy coding:)

在使用 Git 时，你可能会遇到 “src refspace master does not match any” 的错误。

下面是这个错误的含义，以及如何解决它。

Git 中的 src refspec master does not match any 是什么意思

当你试图从本地仓库触发推送到主仓库时，你可能会遇到这样的错误：

git push origin master

这个错误可能是由不同原因引起的。

最有可能出现这种错误的原因是，master 分支不存在。

也许你克隆了一个新的仓库，默认的分支是 main，所以当你试图推送时，没有 master 分支。

你可以用 git branch -b 命令来显示连接到本地仓库的远程分支，像这样：

git branch -b

# results
#  origin/main
#  origin/feat/authentication
#  origin/other branches ...

在上面的结果中，你可以看到没有 master 仓库（origin/master）。所以当你试图推送到该仓库时，你会得到 “respec error”。

这个结果也适用于任何其他不存在的分支。比方说，我做了一些修改，并推送到一个不存在的远程 hello 分支：

git add .
git commit -m "new changes"
git push origin hello

该命令将产生以下错误：

error: src refspec hello does not match any

如何修复 “src refspec master does not match any” 错误

现在你已经知道 master 分支并不存在。解决这个错误的办法是，要么建立一个本地和远程的 master 分支，以便推送提交，要么将提交推送到一个现有的分支——也许是 main。

你可以在 Git 驱动的网站（比如 GitHub）上创建一个远程 master 分支，也可以像这样直接在终端上创建：

git checkout -b master

# add commit

git push origin master

这些命令将在本地创建一个 master 分支。而通过推送到 origin master，也会在远程创建 master 分支。

但如果你不想创建一个 master 分支，你可以使用现有的默认分支（可能是 main）来代替。

总结

所以，如果你在推送到主干时遇到 Error: src refspec master does not match any，最可能的原因是 master 分支不存在。

Git 是一个很好的版本控制工具。它还能使你与他人的协作更有效率。

在这篇文章中，你将学习如何在用 Git 跟踪项目时恢复到之前的 commit（提交）。

本文要讨论的两个命令是 git reset 和 git revert。这些命令可以帮助你撤销你的 commit，回到之前的 commit。

不过它们并不完全相同，所以我们将通过演示每个命令在项目中如何运行的来使本文更实用一些。

任何人都可以理解这个教程，因为它不是关于特定的语言——我们将利用一个文本（txt）文件。

如何使用 git reset 命令恢复到之前的 commit

在本节中，我们将创建一个新文件，并进行三次 commit。然后你会看到如何使用 commit ID 恢复到上一次 commit 或任何其他 commit。

首先，我创建了一个名为 tasks.txt 的文件。该文件中有如下内容：

1. code.
2. Practice.
3. Build. 

接下来，我们要初始化、添加和提交这个文件：

git init
git add tasks.txt
git commit -m "first commit"

我们已经进行了第一次 commit。

我们再重复上面的过程两次，但在每次 commit 之前，我们会在文件中多加一行文字，如下：

1. code.
2. Practice.
3. Build. 
4. Research. 

git add tasks.txt
git commit -m "second commit"

最后，对于第三次 commit：

1. code.
2. Practice.
3. Build. 
4. Research. 
5. Write.

git add tasks.txt
git commit -m "third commit"

现在我们有三个 commit。要恢复到之前的 commit，你必须先得到 commit ID。要做到这一点，请执行下面的命令：

git log --oneline

我们的终端中显示如下：

正如你在上面看到的，这个命令列出了你所有的 commit 以及它们的 ID。

要回到第二个 commit，你可以运行 git reset 命令，后面跟上 commit 的 ID，即：

git reset 5914db0

如果你一直跟到这一步，你不会注意到文件有什么不同（你会在后面看到如何撤销提交和对文件的任何修改）。

文件仍然是这个样子的：

1. code.
2. Practice.
3. Build. 
4. Research. 
5. Write.

但当我们运行 git log --oneline 命令时，第三次提交不会出现在提交日志中：

我们已经成功回到了之前的 commit。

如果你想撤销一个 commit，并撤销该提交之后的所有修改，你可以在 git reset 命令中加上 --hard 标志：

让我们测试一下这个方法，回到第一个 commit：

git reset 89f6c3d --hard

这就是文本文件现在的样子：

1. code.
2. Practice.
3. Build. 

我们又回到了指定提交时的文件初始状态。所有在那次 commit 之后对文件所做的修改都被删除。当我们检查提交日志时，我们将只看到第一次 commit。

虽然这看起来是件很酷的事情，但在使用这条命令时，你应该小心。特别是当你和一个团队一起工作时。

如果你撤销了一个 commit，并删除了它之后的每一个文件改动，你可能会失去你和其他队友对代码所做的重要改动。这也会改变你项目的提交历史。

幸运的是，我们有办法恢复被删除的 commit 的状态。你可以在这里了解更多信息。

如何使用 git revert 命令恢复到之前的 commit 内容

我已经初始化了项目，并像上一节中那样做了三次 commit。下面是提交日志的样子：

要恢复到之前的 commit，请运行 git revert 命令，同时输入当前提交的 ID。

在我们的例子中，我们将使用第三个提交的 ID：

git revert 882ad02

上面的命令会撤销当前的 commit，将文件恢复到上一次 commit 的状态。当你检查 commit 日志时，你会看到这样的内容：

与 git reset 命令不同的是，git revert 命令为被还原的改动创建一个新的 commit。我们还原的那个 commit 不会被删除。

所以你可以看到，git reset 和 git revert 是不一样的。

git reset 会撤消直到指定的 commit ID 的状态的改动。例如，恢复到第二个 commit ID 的状态将撤消改动，并将文件的状态保持为第二个 commit 的状态。

git revert 将撤消到指定的 commit ID 之前的状态。例如，还原到第二个 commit ID 将撤销更改，并将文件的状态保留为第二个 commit 之前的 commit 的状态——第一个 commit。

上面的解释可能看起来很混乱。理解它的最好方法是自己去尝试。

何时使用 git reset 和 git revert

当你在本地仓库上工作时，如果变化尚未被远程推送，你应该使用 git reset。这是因为在从远程仓库拉取修改后运行该命令会改变项目的 commit 历史，导致在该项目上工作的每个人发生合并冲突。

当你意识到对某一本地分支所做的修改应该在其他地方时，git reset 是一个不错的选择。你可以重置并移动到想要的分支，而不会丢失你的文件修改。

对于恢复推送到远程仓库的改动，git revert 是一个很好的选项。因为这个命令会创建一个新的提交，而不会改变其他人的提交历史。

总结

在这篇文章中，我们谈到了在 Git 中恢复以前的提交。

我们谈到了两个主要的命令，即 git reset 和 git revert 命令，它们显示了如何撤销 Git 修改。

我们还通过实际例子看到了这两个命令是如何工作的。

Happy coding!

git push 命令允许你将本地 Git 仓库中的本地分支的提交发送到（或推送）远程仓库。

为了能够推送到远程仓库，你必须确保你对本地仓库的所有修改都已提交。

这个命令的语法如下：

git push <repo name> <branch name>

你可以在命令中传递一些不同的选项，你可以在 Git 文档中了解更多信息，或者运行 git push --help。

推送到一个特定的远程仓库和分支

为了推送代码，你必须先克隆一个仓库到你的本地机器。

# 一旦克隆了一个 repo，你就会在默认的分支中工作（默认是`master'）。
git clone https://github.com/<git-user>/<repo-name> && cd <repo-name>
# 执行更改并暂存你的文件（对每个文件重复 `git add` 命令，或者使用 `git add .` 来暂存所有文件）
git add <filename>
# 现在提交你的代码
git commit -m "added some changes to my repo!"
# 将 `master` 分支中的更改推送到 GitHub
git push origin master

要了解更多关于分支的信息，请查看以下链接：

• git checkout
• Git 分支

推送到一个特定的远程仓库和其中的所有分支

如果你想把所有的修改推送到远程仓库及其中的所有分支，你可以使用：

git push --all <REMOTE-NAME>

其中：

• --all 是表示你想推送所有分支到远程仓库的标志。
• REMOTE-NAME 是你想推送到的远程仓库的名称。

使用 force 参数推送到特定的分支

如果你想忽略 GitHub 上对 Git 仓库所做的本地修改（大多数开发者都是为了对开发服务器进行热修复），那么你可以使用 -force 命令来推送，忽略这些修改。

git push --force <REMOTE-NAME> <BRANCH-NAME>

其中：

• REMOTE-NAME 是远程仓库的名称，你想把修改推送到这个仓库。
• BRANCH-NAME 是你要推送的远程分支的名称。

推送忽略 Git 的预推送钩子

默认情况下，git push 推送会触发 --verify 开关。这意味着 Git 会执行任何可能已经配置好的客户端预推送脚本。如果预推送脚本失败，Git 推送也会失败。(预推送钩子很适合做一些事情，比如，检查提交信息是否符合公司标准、运行单元测试等等）。偶尔你可能希望忽略这个默认行为，例如，你希望将你的修改推送到一个特性分支，让其他贡献者拉取，但你正在进行的修改会破坏单元测试。要忽略这个钩子，只需在推送命令中加入标志 --no-verify。

git push --no-verify

更多信息

• Git 文档 - push
• Git hooks

嘿，朋友们，你是否曾经在 Git 中工作时，发现自己不知道是否要暂存（stage）正确的修改？

或者你想看看你要提交的改动与上次提交的改动相比有何不同。也许你想看看两个分支、提交或文件之间的差异。

这些都是使用版本控制系统时常见的问题和任务。幸运的是，你可以用 Git diff 命令来验证这一切。

我知道你的时间宝贵，所以我们直接开始吧。

别担心，我会用一个有趣的例子来教你每个命令。放宽心，开始阅读这篇文章吧。

git diff——通用的 diff 命令

git diff 列出了你的当前工作目录和暂存区域之间的变化。

让我们举个例子。我创建了一个 Git 仓库，它是 cat_vs_dog。这不是一个正式的仓库，但它是相当严肃的。😉 然后我创建了 cat.txt 和 dog.txt。

它们的名字就是它们的介绍了——像这样：

然后我们用 git add cat.txt dog.txt 把这个改动移到暂存区。想确认一下吗？那就用 git status 吧，它可以显示哪些修改已经准备好提交了，如下图：

然后，假设我想对狗的名字做一些改动——比如我希望叫它 “pup” 而不是 “puppy”。

在此之前，如果我运行 git diff 命令，它没有显示什么。你能猜到为什么吗？如果你不能，那也完全没问题。在这上面停顿几秒钟，我们继续看下面的内容吧。

现在，我把 “puppy” 改为 “pup”。叫它 pup 很酷。

在暂存它们之前，我希望看到我在当前工作目录（也就是当前工作文件夹）中的改动与暂存的改动相比较。

为了做到这一点，我运行了 git diff 命令。现在你可以看到它们的区别如下。

这有点说得通，但也有点奇怪，对吗？别怕，我将教你了解每一行 diff 的结果。

之前，我们运行了 git diff 命令，它没有显示什么。因为 git diff 显示的是你的工作目录和暂存区的变化之间的差异。但是，我们在暂存修改之后，并没有在工作目录中修改任何东西。所以，与暂存区域相比，没有什么不同。我希望这么说，你能理解。

一行一行地理解 git diff 的结果

第 1 行——这是同一个文件的两个版本。Git 把第一个版本命名为 A，把第二个版本命名为 B。

• A - 文件的旧版本
• B - 文件的新版本

第 2 行——关于文件的元数据，这对你的生活并不超级有用。前两个哈希值涉及到被比较的两个文件。100644 是一个内部文件模式标识符。

第 3 行——Git 给文件的 A 版分配了一个减号（-），给文件的 B 版分配了一个加号（+）。

第 4 行——Git 通常显示被修改的一大块的行，而不是整个文件。

• 以（-）符号开头的行来自 A 版本
• 以（+）符号开始的行来自 B 版本

除了被修改的行，还包括该块前后的一些代码行，以显示上下文。

第 5 行——每个块都以一个块头（Chunk header）开始。块头将由 @@（在开始和结束时）来标识。然后，有两组数字。你能看到 -1 和 +1 吗？

• -1 意味着从 A 版文件中，从第 1 行开始提取一行。
• +1 表示从 B 版文件中，从第 1 行开始提取一行。

如果这些集合是 -3,4 +3,2，那么：

• -3,4 表示从 A 版文件中提取了从第 3 行开始的 4 行。
• +3,2 表示从 B 版文件中提取了从第 3 行开始的 2 行。

文件末尾没有换行——文本中说，在这些修改过的行之后没有行。这意味着，在上面的例子中，我只增加了一行，而且还修改了同一行。所以，在这之后就没有更多的行了。

这就是为什么在 diff 的结果中显示 “No newline at end of file”。希望你能明白我的意思。

庆祝时间

花一小会儿时间来庆祝你的努力，因为你已经有了 diff 的结果。现在，你有了一个坚实的基础，所以你可以开始微笑着学习更多的命令......

如何在 Git 中比较已暂存的更改

在你提交修改之前，可以将暂存的修改与上次提交的修改进行比较。你可以通过添加一个标志 --staged 或 --cached 来做到这一点。我喜欢 --staged，因为它很有意义。如果你喜欢 --cached，那也很好。

让我通过一个例子来解释。首先，我们在 cat_vs_dog 仓库中提交我们暂存的修改。如果你不记得我们暂存了什么，它们是 kitty 和 puppy。

在那里，我们想做一个改变——也就是说，我们希望把 “puppy” 改成 “pup”，这不是暂存的。

好吧，首先我们用 git commit -m "introduction to cat and dog 来提交已暂存的修改：

现在，暂存从 “puppy” 到 “pup” 的变化。然后，运行 git diff --staged 命令，它列出了暂存区域和你最后一次提交之间的变化。

• A 版本——在 dog.txt 中包含行 my name is puppy 的最后一次提交
• B 版本——与上次提交不同的暂存区，比如 dog.txt 中的 “puppy” 改为 “pup”。

从 diff 的结果来看，我们清除了我们修改和暂存的内容——A 版本中的 “my name is puppy” 和 B 版本中的 “my name is pup”。

我希望你现在能够通过看 diff 的结果来比较这些变化，并认识到我们改变了什么。diff 是一个超级强大的命令，它可以让你以很多方式来比较变化。

你需要知道的 4 个 Diff 比较

你可以运行 git diff HEAD 命令，将已暂存和未暂存的修改与你的最后一次提交进行比较。

你也可以运行 git diff <branch_name1> <branch_name2> 命令来比较第一个分支的改动和第二个分支的改动。在比较分支的时候，顺序确实很重要。所以 diff 的结果会因顺序不同而改变。

最重要的提示：分支比较只考虑提交的内容，它并不考虑暂存的和未暂存的修改。

你可以运行 git diff <commit_hash> <commit_hash> 命令来比较两个提交之间的变化。和分支比较一样，顺序在比较提交时也很重要。

你可以运行下面的命令来比较特定文件的变化：

• git diff HEAD <file_name>
• git diff <file_name>
• git diff --staged <file_name> or  git diff --cached <file_name>,
• git diff <branch_name1> <branch_name2> <file_name>
• git diff <commit_hash> <commit_hash> <file_name>

总结

我希望这篇文章能帮助你使你的下一次提交或暂存更加准确。在使用 Git 命令时，你的心态很重要。充满信心地处理它，你就能从任何错误中学习。

如果你发现本教程中有什么需要更新的地方，请随时与我联系😜.

在这篇文章中，我们将讨论如何在 Git 中推送一个不做任何修改的提交。

Git 让推送空提交的过程变得非常简单。这就像推送普通的提交一样，只不过你要加上 --allow-empty 标志。

git commit --allow-empty -m "Empty-Commit"

你现在需要将其推送到主目录。要做到这一点，你可以使用这个命令：

git push origin main

你可以看到，运行上述命令后，提交的内容已经被推送到你的分支，没有任何改动。

为什么需要推送一个空的提交？

有可能你需要在不对项目做任何修改的情况下启动构建。或者你可能无法手动启动构建，启动构建的唯一方法是使用 Git。你可以在不对项目做任何修改的情况下，通过推送一个空的提交来启动构建。

以上就是一个简单的介绍 🥳

如果你使用 Git 进行版本控制，很可能你出于各种原因创建了分支。

如果你发现拼写错误或者更改代码，你可能需要重命名分支。

在本文中，我将向你展示如何在不切换到另一个分支的情况下重命名你正在操作的分支。

如何在 Git 中重命名分支

要重命名当前不在操作的分支，通常运行命令 git branch -m old-name new-name。

例如，我目前在 main 分支上，我能够将 kolade-works 重命名为 kolade-codes。

继续阅读本文的下一部分，了解如何在 Git 中重命名当前分支。

如何在 Git 中重命名当前分支

你需要做的第一件事是运行 git branch，这样你就可以看到已有的分支：

接下来，确保你位于要更改名称的分支中。你可以通过运行 git checkout branch-name 来做到这一点。

在我的例子中，我想将 fix-bug 分支更改为 bug-fixes，所以我将运行 git checkout fix-bug：

你可以看到 git bash 向我显示了我现在所在的分支，即 fix bug。

要重命名分支，你需要运行命令 git branch -m new-name。

前面说我想将 fix bug 分支重命名为 bug-fixes，因此我将运行 git branch -m bug-fixes。

-m 是 move 的缩写。

你可以看到分支的名称已成功更改为 bug fixes。

要确认这一点，你可以再次运行 git branch：

小结

本文向你展示了如何重命名本地 Git 分支，尤其是当它是当前分支时。即使它不是当前分支，你也已经了解了使用什么命令来更改它。

如果你也想了解如何重命名远程分支，我也写了一篇关于这个主题的文章。

感谢你阅读本文。

分支是 Git 不可或缺的一部分，因为它可以让你在不修改已经投入生产的代码的情况下工作。

当你在 main 以外的分支完成工作后，你需要将它与 main 合并，以便反映你刚刚集成的功能或错误修复。

但是，如果你在合并之后发现还有一件事情忘了做怎么办？或者，如果你在没有准备好时意外合并了怎么办？

你可以在 Git 中撤消几乎所有内容。因此，在本文中，我将向你展示如何在 Git 中撤销合并，以便你可以恢复到上次提交的内容。

如何在 Git 中撤消合并提交

你可以使用 Git 重置命令撤消合并。

首先，你需要检查提交哈希（或 id），以便你可以使用它返回上一个提交。

要检查哈希，请运行 git log 或 git reflog。git reflog 是一个更好的选择，因为它更具可读性。

当你获得要返回的提交的哈希时，运行 git reset --hard commit-before-the-merge：

运行命令时，你应该会看到代码编辑器中删除了一些内容。

如果你不确定上一次提交的哈希值，你可以运行 git reset --hard HEAD~1 以返回到合并之前的提交：

请注意，当你使用 --hard 标记撤消合并时，任何未提交的更改都将被还原。

在 Git 中撤消合并的更好方法

由于上面讨论的方法将恢复未提交的更改，Git 提供了一个更安全的标记 --merge。

要使用 --merge 标记撤消合并，请运行 git reflog 以查看提交的哈希值，然后运行 git reset --merge previous-commit：

你还可以通过运行 git reset --merge HEAD~1 将 HEAD 关键字与 --merge 标记一起使用：

注意：如果你在使用 --merge 标记时没有得到此命令的响应，请不要担心，它可以运行。

小结

在本文中，你学习了如何在 Git 中撤消合并，因此你可以撤消错误或不需要的合并，并更有效地使用 Git。

以下是使用 --hard 和 --merge 标记撤消合并时的要点：--hard 标记删除未提交的更改，而 --merge 标记保留未提交的更改。

感谢你阅读本文！

Git 分支允许你添加新功能而不会修改项目的实时版本。如果你在一个团队中工作，不同的开发人员可能在不同的分支上工作。

从长远来看，你必须将这些独立的分支推送到远程服务器。例如，GitHub、GitLab 等。

在本文中，我将向你展示如何将本地 Git 分支推送到远程服务器。你是否还没有推送并不重要。你甚至可能已经推送了你的 main 分支并想要推送另一个分支。我将从头开始向你展示一切。

如何将 Main 分支推送到远程

如果你想将 main 分支推送到远程，你可能是第一次推送。在尝试推送到远程之前，请确保你已执行以下命令：

• git init 用于初始化本地仓库
• git add . 添加本地仓库的所有文件
• git commit -m ‘commit message’ 保存你对这些文件所做的更改

要推送 main 仓库，你首先必须通过运行 git remote add <url> 将远程服务器添加到 Git。

要确认已添加远程，请运行 git remote -v：

要最终推送 repo，请运行 git push -u origin <branch-name>。
对我来说 main 是那个分支的名称，所以我运行 git branch -M main。

如果你尚未将 Git 配置为使用凭证助手，系统将要求你提供 GitHub 用户名和 PAT（个人访问令牌）：

这就是你第一次推送 main 分支的方式。

如何将新分支推送到远程

如果你有另一个工作过的分支想要推送到远程，你仍将使用 git push 命令，但方式略有不同。

提醒一下，要创建一个新分支，请运行 git branch branch-name。要切换到该分支以便在那里工作，你必须运行 git switch branch name 或 git checkout branch-name。

要将分支推送到远程服务器，请运行 git push –u origin。就我而言，该分支的名称是 bug-fixes，所以，我需要运行 git push -u origin bug-fixes：

要确认分支已被推送，请前往 GitHub 并单击分支下拉菜单，你应该在那里看到分支：

小结

本文向你展示了如何将新分支推送到远程。除此之外，我们还研究了如何第一次推送到远程服务器。

如果你想了解有关 Git 的更多信息，请查看 freeCodeCamp 专栏关于 Git 和 GitHub 的文章。

也许你刚买了一台新的笔记本电脑，或者你是第一次使用 MacBook 进入科技行业，你需要第一次在 MacBook 上设置 Git，不必担心，我将为你介绍怎么做。

这篇简短的文章将帮助你了解如何在 macOS 上设置 Git，以便你可以立即恢复工作。

我假设你在阅读本文之前已经知道 Git 是什么以及它的作用。但是，如果你不知道，并且需要了解 Git 和版本控制，你可以查看这篇文章：Git 版本控制入门指南。

让我们开始吧。

如何在 Mac 上安装 Git

在 Mac 计算机上安装 Git 的方法有很多，但最简单的方法是使用 Homebrew。你可以在本文档或此处找到其他方法以及如何使它们起作用。

如何使用 Homebrew 安装 Git

Homebrew 是一个免费的开源软件包管理系统，可简化 Apple 操作系统（macOS）上的软件安装。你可以使用它来安装将来需要的所有类型的包，而不仅仅是 Git。这使它非常有用。

你不需要安装应用程序或任何东西来安装 Homebrew。你只需要打开终端并通过运行以下命令安装 Homebrew：

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

注意：输入命令后，它将要求你输入密码。

成功后，你可以在终端中通过以下命令继续安装 Git：

$ brew install git

至此，你已经在 Mac 上安装了 Git。你现在可以通过在终端中运行以下命令来验证：

$ Git --version

如何在 macOS 中配置 Git

到目前为止，你已经学会了如何安装 Git——但是单独安装 Git 并不仅仅让你可以从 Git 版本控制中推送、拉取和提交代码以及执行其他 Git 操作。

要使用 Git，你必须使用 git config 命令设置你的 Git 环境。这将使你能够访问控制 Git 如何在你的系统上工作的配置变量。

你需要的两个重要的 git config 变量是身份变量。这些可让你设置用户名和电子邮件。这是你在使用 GitHub、GitLab 等设置版本控制系统时使用的用户名和电子邮件。

$ git config --global user.name "olawanlejoel"
$ git config --global user.email "mymail@gmail.com"

注意：用你的姓名和电子邮件替换。你还应该知道 --global 选项可确保在整个系统中使用这些值。

完成此操作后，你还可以进行其他一些配置，即为 Git 控制台设置默认文本编辑器和颜色：

$ git config --global core.editor emacs
$ git config --global color.ui true

你可以选择你经常使用的任何编辑器。我选择了EMACS。

现在 Git 已准备好供你使用。你可以使用以下命令检查你的 Git 配置以确保它们正确：

$ git config --list

这将显示以下内容（使用你自己的信息）：

user.name=olawanlejoel
user.email=mymail@gmail.com
color.ui=true

假设有一个错误，并且你希望更改任何配置，你可以重新运行特定于错误的配置命令。

例如，如果我的电子邮件有错误，我可以重新运行电子邮件配置来更正它：

$ git config --global user.email "mynewmail@gmail.com"

现在，当你重新运行 --list 命令时，你将获得更新后的值：

user.name=olawanlejoel
user.email=mynewmail@gmail.com
color.ui=true

总结

在本文中，你学习了如何在 Mac 计算机上首次设置 Git。

如果你还想了解如何在 Windows 和 Linux 等其他系统上执行此操作，请查看这篇全面的指南。

另外，如果你也有兴趣学习一些基本的 Git 命令，这里有一份详细的备忘单。

祝你编程愉快！

当你使用 Git 时，你可能出于各种原因想要删除推送到 GitHub 等平台的远程分支。

在本文中，我将向你展示如何在 Git 中删除远程分支。但首先，让我们看看如何删除本地分支。

我将在本文中使用 Git bash，因为它比任何其他终端都更容易使用 Git。但是如果你使用另一个终端也没关系，命令还是一样的。

如何在 Git 中删除本地分支

运行 git branch 或 git branch -a 以查看你为项目创建的分支。

如果你运行 git branch -a ，它将使远程分支不同。这是我只在 Git bash 中看到的功能。

在这种情况下，test-branch2 是一个我还没有推送的分支，所以它是一个本地分支。

要删除本地分支，请运行 git branch -d branch-name。

如果你正确键入命令，你将收到分支已被删除的响应。

如何在 Git 中删除远程分支

如果你尝试使用与删除本地分支相同的命令来删除远程分支，你将收到一条消息，指出该分支已被删除。但是如果你运行 git branch -a，这个分支仍然会被列出来。

如果你检查 GitHub，分支仍然存在：

要完全删除远程分支，你需要使用带有 -d 标志的 git push origin 命令，然后指定远程分支的名称。

因此，删除远程分支的命令的语法如下所示：git push origin -d branch-name。

例如，要删除 test-branch1 分支，我将运行 git push origin –d test-branch1：

要验证远程分支是否已被删除，请再次运行 git branch -a。

你可以看到远程分支 test-branch1 不再列出。

如果你再次检查 GitHub，就会发现已经没有这个分支了：

小结

请记住，要从项目中完全删除 Git 分支，你需要使用 git push origin 命令。

那是因为你已经推送了分支。因此，运行 git branch -d 命令只会在本地删除分支。

如果你在使用 Git 时遇到问题，我建议你将终端切换到 Git bash，因为它对所有内容都有语法高亮显示——这使得使用 Git 更容易。

感谢你阅读本文。