网站导航
> 技术文档 > 用动图带你更清晰的零基础掌握 Git 常用命令

用动图带你更清晰的零基础掌握 Git 常用命令

网友: 技术文档 2025-09-03 05:13:12

🧰 零基础掌握 Git 常用命令
📅 更新时间：2025年8月14日
🏷️ 标签：Git | 版本控制 | 命令行 | 基础 | 工作流

文章目录

  • 📖 前言
  • 🚀 一、什么是Git？
  • 🧱 二、主要
    • 🧩 1.基础篇
      • git commit
      • git branch
      • git merge
        • 总结
      • git rebase
    • 🧠 2.高级篇
      • HEAD
      • 分离的 HEAD
      • 相对引用
        • ^操作
        • ~ 操作
        • 强制修改分支位置
      • 撤销变更
        • git reset
        • git revert
    • 🔄 3.移动提交记录
      • git cherry-pick
      • 交互式的 rebase
    • ⏳ 未完待续......
  • 🌐 三、远程
    • 📤📥 1.Push & Pull —— Git 远程仓库！
      • git clone
      • 远程分支
      • Git Fetch
      • Git Pull
      • Git Push
      • 偏离的工作
      • 远程服务器拒绝!(Remote Rejected)
    • 🔗 关于 origin 和它的周边 —— Git 远程仓库高级操作
  • 📋 总结

📖 前言

在这里，我会介绍所有常用的git命令，同时我会用文字+动图的形式更加清晰的说明每一个命令的基础用法，大家如果想练习git可以通过这个网址git练习进行练习，本文也是基于此网址进行教学

🚀 一、什么是Git？

Git 是一款分布式版本控制系统，用于追踪文件变更、管理历史与多人协作。每个开发者的本地仓库都包含完整历史（可离线提交），通过远程仓库进行同步与协作。

  • 核心理念

    • 分布式：每个克隆都是完整仓库（含全部历史），不依赖中心服务器即可提交/回滚/查看历史。
    • 快照而非差异：一次提交记录项目快照（通过哈希指纹标识），高效且安全。
    • 三大区域：工作区（Working Directory）、暂存区（Staging Area）、本地仓库（Local Repository）。
    • 分支与合并：分支轻量、创建/切换/合并成本低，便于并行开发与代码评审。
    • 远程协作：通过 push/pull/fetch 与远程仓库同步，配合 PR/MR 完成交付与审阅。

  • 为什么用 Git（简要）

    • 离线可用、速度快；历史可追溯、可对比、可回滚。
    • 分支模型灵活（如 Git Flow、Trunk-Based）。
    • 社区与生态完善（GitHub/GitLab、Hooks、CI/CD 集成）。

一句话：Git 让“改动有据可查、协作有分有合、风险可控可回”。

🧱 二、主要

这部分讲解一些主要常用的git命令用法，不包含远程

🧩 1.基础篇

git commit

作用：把暂存区的改动记录为一次快照，写入本地仓库历史

我们现在来实际操作一下，现在我们有一个仓库
用动图带你更清晰的零基础掌握 Git 常用命令
此时仓库只有一条分支 main 并且我们当前在这条分支上，因为main 右上角有一个 * 代表我们当前所在目录，现在假设我们暂存区已经有一条记录了，我们要进行提交

输入git commit //在当前分支下进行提交

在这里插入图片描述
此时我们会发现仓库中多了一条提交记录，就是我们刚刚 git commit 的所执行的结果
我们刚才修改了代码库，并把这些修改保存成了一个提交记录 C2。C2的 parent 节点是 C1

git branch

作用：可以对分支进行调整 包括创建/移动/重命名…一系列操作

就好比一个仓库有一个主分支main，当团队协作的时候，所有人不可能都直接对主分支进行提交与修改，这样会导致主分支及其混乱，所以我们可以开一条新的分支进行操作

我们现在来实际操作一下，现在我们有一个仓库
用动图带你更清晰的零基础掌握 Git 常用命令
现在我们创建一个新分支 newImage

输入git branch newImage //创建分支 newImage

在这里插入图片描述
看到了吗，创建分支就是这么容易！新创建的分支 newImage 指向的是提交记录 C1

现在咱们试着往新分支里提交一些东西

输入git commit //在当前分支下进行提交

在这里插入图片描述
我们会发现一个事情！我们的本意是想往新分支中提交一个记录，为什么提交到主分支main中了呢？
因为我们当前所在的分支是在main分支中，(右上角的*表示)我们当前所在的分支

所以现在解决办法很明确了，当我们创建分支后需要切换到新分支中然后再提交

git checkout A //转移到A分支上

这个checkout命令可以将当前分支转到A分支上

那我们现在来实操一下，转换到新分支上并且进行提交

输入git checkout newImage //转移到 newImage 分支上git commit //在newImage 分支上进行提交

在这里插入图片描述
从视频中我们可以看出确实是先转换到了新分支上，因为*从main中转移到了newImage上，然后再进行提交

注意：在 Git 2.23 版本中，引入了一个名为 git switch 的新命令，最终会取代 git checkout，因为 checkout 作为单个命令有点超载（它承载了很多独立的功能）

git merge

现在我们已经知道如何提交以及如何使用分支了。接下来咱们看看如何将两个分支合并到一起。就是说我们新建一个分支，在其上开发某个新功能，开发完成后再合并回主线。

咱们先来看一下第一种方法 —— git merge 在 Git 中合并两个分支时会产生一个 特殊的提交记录 ，它有两个 parent 节点。可以理解为：“我要把这两个 parent 节点本身及它们所有的祖先都包含进来。”

这里准备了两个分支，每个分支上各有一个独有的提交。这意味着没有一个分支包含了我们修改的所有内容。咱们通过合并这两个分支来解决这个问题
用动图带你更清晰的零基础掌握 Git 常用命令

我们要把 bugFix分支 合并到 main分支 里
注意我们当前所在分支！！！！！！！！

输入git merge bugFix //将 bugFix分支合并到当前分支上

在这里插入图片描述
看见了吗？首先，main 现在指向了一个拥有两个 parent 节点的提交记录。假如从 main 开始沿着箭头向上看，在到达起点的路上会经过所有的提交记录。这意味着 main 包含了对代码库的所有修改

我们如果此时需要再把 main 分支合并到 bugFix 分支 应该如何操作？
直接再一次 git merge main ？？
错误！！！！！！
我们需要先将自移动到bugFix分支上，然后再将main分支合并过来

输入git checkout bugFix //转移到 bugFix 分支上git merge main

在这里插入图片描述
现在所有提交记录的颜色都一样了，这表明每一个分支都包含了代码库的所有修改！大功告成！

总结

git merge 总是“把参数分支合到当前分支”，更新的是当前分支的指针，另一个分支不变。
在 A 上执行 git merge B：A 前进，包含 B 的改动；B 不变。
在 B 上执行 git merge A：B 前进，包含 A 的改动；A 不变。

git rebase

第二种合并分支的方法是 git rebase。Rebase 实际上就是取出一系列的提交记录，复制它们，然后在另外一个地方逐个的放下去。

Rebase 的优势就是可以创造更线性的提交历史，这听上去有些难以理解。如果只允许使用 Rebase 的话，代码库的提交历史将会变得异常清晰

还是准备了两个分支；注意当前所在的分支是 bugFix（星号标识的是当前分支）

我们想要把 bugFix 分支里的工作直接移到 main 分支上。移动以后会使得两个分支的功能看起来像是按顺序开发，但实际上它们是并行开发的。

咱们这次用 git rebase 实现此目标

输入git rebase main //将当前分支变基到 main 之上，使“当前分支”历史线性化；main 不变

在这里插入图片描述

现在 bugFix 分支上的工作在 main 的最顶端，同时我们也得到了一个更线性的提交序列。

注意，提交记录 C3 依然存在（树上那个半透明的节点），而 C3’ 是我们 Rebase 到 main 分支上的 C3 的副本

现在唯一的问题就是 main 还没有更新，下面咱们就来更新它吧

现在我们假设已经切换到了 main 上。把它 rebase 到 bugFix 分支上

输入git rebase bugFix //将当前分支变基到 bugFix 之上，使“当前分支”历史线性化；bugFix 不变

在这里插入图片描述

🧠 2.高级篇

在接触 Git 更高级功能之前，我们有必要先学习在你项目的提交树上前后移动的几种方法。

一旦熟悉了如何在 Git 提交树上移动，你驾驭其它命令的能力也将水涨船高！

HEAD

我们首先看一下 HEAD。 HEAD 是一个对当前所在分支的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。

HEAD通常情况下是指向当前分支名的（如 bugFix）。在你提交时，改变了 bugFix 的状态，这一变化通过 HEAD 变得可见

下面咱们通过实际操作看一下。我们将会观察提交前后 HEAD 的位置

下面这是当前仓库
用动图带你更清晰的零基础掌握 Git 常用命令
初始的时候HEAD应该指向main分支名

输入git checkout C1 //切换到C1这个提交记录上git checkout main //切换到main分支上git commit //在当前分支上进行提交git checkout C2 //切换到C2这个提交记录上

在这里插入图片描述
看到了吗？ HEAD 指向了 main，随着提交向前移动

分离的 HEAD

分离的 HEAD 就是让其指向了某个具体的提交记录而不是分支名。在命令执行之前的状态如下所示：

HEAD -> main -> C1
HEAD 指向 main， main 指向 C1
用动图带你更清晰的零基础掌握 Git 常用命令
我们通过下面这个命令来实现分离HEAD

git checkout C1 //切换到C1这个提交记录上

在这里插入图片描述
现在变成了

HEAD -> C1

相对引用

使用相对引用的话，你就可以从一个易于记忆的地方（比如 bugFix 分支或 HEAD）开始计算。

相对引用非常给力，这里我介绍两个简单的用法：

  • 使用 ^ 向上移动 1 个提交记录
  • 使用 ~ 向上移动多个提交记录，如 ~3
^操作

首先看看操作符 ^。把这个符号加在引用名称的后面，表示让 Git 寻找指定提交记录的 parent 提交。因为前面说了是向上1个提交记录

所以 main^ 相当于main 的 parent 节点

main^^ 是 main 的第二个 parent 节点

比如下面是我们当前的仓库
用动图带你更清晰的零基础掌握 Git 常用命令
现在咱们切换到 main 的 parent 节点

输入git checkout main^ //切换到 main 的 parent 节点

在这里插入图片描述
我们通过这个动图可以发现确实移动到了上一个节点上

你也可以将 HEAD 作为相对引用的参照。下面咱们就用 HEAD 在提交树中向上移动几次

输入git checkout C3git checkout HEAD^git checkout HEAD^git checkout HEAD^

在这里插入图片描述

~ 操作

如果你想在提交树中向上移动很多步的话，敲那么多 ^ 貌似也挺烦人的，Git 当然也考虑到了这一点，于是又引入了操作符 ~

该操作符后面可以跟一个数字（可选，不跟数字时与 ^ 相同，向上移动一次），指定向上移动多少次。咱们还是通过实际操作看一下吧

假设下图是我们当下的一个仓库
用动图带你更清晰的零基础掌握 Git 常用命令
咱们用 ~ 一次后退四步

输入git checkout HEAD~4

在这里插入图片描述
从图中我们可以明显的发现直接移动了4步，简洁了很多

强制修改分支位置

使用相对引用最多的就是移动分支。可以直接使用 -f 选项让分支指向另一个提交。例如:

git branch -f main HEAD~3

上面的命令会将 main 分支强制指向 HEAD 的第 3 级 parent 提交

假设下图是我们当前仓库
用动图带你更清晰的零基础掌握 Git 常用命令
我们来实际操作一下Git指令实现强制修改分支位置

输入git branch -f main HEAD~3

在这里插入图片描述
有一个小细节就是我们当前是在bugFix分支上执行的这条命令
那能不能在main分支上实现呢？

用这条命令时最好别在 main 上 因为 指定分支不能与当前所在分支相同！
原因：git branch -f 会强制移动“指定分支”的指针，但 Git 不允许强更当前检出的分支，常见报错是Cannot force update the current branch
因此应在别的分支或分离头（detached HEAD）下执行

撤销变更

在 Git 里撤销变更的方法很多。和提交一样，撤销变更由底层部分（暂存区的独立文件或者片段）和上层部分（变更到底是通过哪种方式被撤销的）组成。我们这个应用主要关注的是后者。

主要有两种方法用来撤销变更 —— 一是 git reset，还有就是 git revert
接下来咱们逐个进行讲解

git reset

git reset 通过把分支记录 回退几个提交记录 来实现撤销改动。你可以将这想象成 “改写历史” ，git reset 向上移动分支，原来指向的提交记录就跟从来没有提交过一样

假设我们当下仓库如下图所示:
用动图带你更清晰的零基础掌握 Git 常用命令
我们现在的需求是 撤销本地的C2提交记录
我们可以用reset这样做

输入git reset HEAD^ 或者 git reset main^ 或者 git reset HEAD~1

在这里插入图片描述
Git 把 main 分支移回到 C1；现在我们的本地代码库根本就不知道有C2 这个提交了

git revert

虽然在你的本地分支中使用 git reset 很方便，但是这种 “改写历史” 的方法对大家一起使用的远程分支 是无效的哦！

为了撤销更改并分享给别人，我们需要使用 git revert

假设我们当下远程仓库如下图所示:
用动图带你更清晰的零基础掌握 Git 常用命令

输入git revert HEAD

在这里插入图片描述
奇怪！在我们要撤销的提交记录后面居然多了一个新提交！ 这是因为新提交记录 C2\' 引入了更改 —— 这些更改刚好是用来撤销 C2 这个提交的。也就是说 C2’ 的状态与 C1 是相同的

revert 之后就可以把你的更改推送（push）到远程仓库与别人分享啦。

🔄 3.移动提交记录

到现在，我们已经学习了 Git 的基础知识 —— 提交、分支以及在提交树上移动。 这些概念涵盖了 Git 90% 的功能，同样也足够满足开发者的日常需求

然而, 剩余的 10% 在处理复杂的工作流时(或者当你陷入困惑时）可能就显得尤为重要了。接下来要讨论的这个话题是“整理提交记录” —— 开发人员有时会说“我想要把这个提交放到这里, 那个提交放到刚才那个提交的后面”, 而接下来就讲的就是它的实现方式，非常清晰、灵活，还很生动。

看起来挺复杂, 其实是个很简单的概念

git cherry-pick

本系列的第一个命令是 git cherry-pick, 命令形式为:

  • git cherry-pick …

如果你想将一些提交复制到当前所在的位置（HEAD）下面的话， Cherry-pick 是最直接的方式了。我个人非常喜欢 cherry-pick，因为它特别简单。

咱们还是通过例子来看一下！

假设下图是我们当前仓库
用动图带你更清晰的零基础掌握 Git 常用命令
我们想将 side 分支上的工作复制到 main 分支但又不想将C3这个提交记录复制过去，你可能立刻想到了之前学过的 rebase 了吧？但是咱们还是看看 cherry-pick 有什么本领吧

输入git cherry-pick C2 C4

在这里插入图片描述

我们只需要提交记录 C2 和 C4，所以 Git 就将被它们抓过来放到当前分支下了。 就是这么简单!

交互式的 rebase

当你知道你所需要的提交记录（并且还知道这些提交记录的哈希值）时, 用 cherry-pick 再好不过了

但是如果你不清楚你想要的提交记录的哈希值呢? 幸好 Git 帮你想到了这一点, 我们可以利用交互式的 rebase , 如果你想从一系列的提交记录中找到想要的记录, 这就是最好的方法了

咱们具体来看一下

交互式 rebase 指的是使用带参数 --interactive 的 rebase 命令, 简写为 -i

如果你在命令后增加了这个选项, Git 会打开一个 UI 界面并列出将要被复制到目标分支的备选提交记录，它还会显示每个提交记录的哈希值和提交说明，提交说明有助于你理解这个提交进行了哪些更改。

在实际使用时，所谓的 UI 窗口一般会在文本编辑器 —— 如 Vim —— 中打开一个文件。 考虑到演示问题，这里用一个对话框来模拟这些操作

当 rebase UI界面打开时, 你能做3件事:

  • 调整提交记录的顺序（通过鼠标拖放来完成）
  • 删除你不想要的提交（通过切换 pick 的状态来完成，关闭就意味着你不想要这个提交记录）
  • 合并提交 , 简而言之，它允许你把多个提交记录合并成一个

接下来咱们看个实例

假设下图是我们当前仓库
用动图带你更清晰的零基础掌握 Git 常用命令
当我们想调整提交顺序的时候，但又不知道这些提交的哈希值(这里有ui图，但实际是没有的)
我们可以通过下面这个命令打开一个窗口

输入git rebase -i HEAD~4 //这里HEAD~4表示操作从当前提交记录网上数4个，操作这4个

用动图带你更清晰的零基础掌握 Git 常用命令
这里就弹出了窗口，可以删除，也可以编辑提交位置，假设我们要删除C2并且将提交记录改为C5 C4 C3

我们可以直接在ui上用鼠标进行操作

在这里插入图片描述
操作完后的效果如下:
在这里插入图片描述
Git 严格按照你在对话框中指定的方式进行了复制

⏳ 未完待续…

还会有些杂项与技巧 稍后更新…

🌐 三、远程

远程仓库并不复杂, 在如今的云计算盛行的世界很容易把远程仓库想象成一个富有魔力的东西, 但实际上它们只是你的仓库在另个一台计算机上的拷贝。你可以通过因特网与这台计算机通信 —— 也就是增加或是获取提交记录

话虽如此, 远程仓库却有一系列强大的特性

首先也是最重要的的点, 远程仓库是一个强大的备份。本地仓库也有恢复文件到指定版本的能力, 但所有的信息都是保存在本地的。有了远程仓库以后，即使丢失了本地所有数据, 你仍可以通过远程仓库拿回你丢失的数据。

还有就是, 远程让代码社交化了! 既然你的项目被托管到别的地方了, 你的朋友可以更容易地为你的项目做贡献(或者拉取最新的变更)

现在用网站来对远程仓库进行可视化操作变得越发流行了(像 GitHub), 但远程仓库永远是这些工具的顶梁柱, 因此理解其概念非常的重要!

📤📥 1.Push & Pull —— Git 远程仓库！

直到现在, 教程都聚焦于本地仓库的操作（branch、merge、rebase 等等）。但我们现在需要学习远程仓库的操作 —— 我们需要一个配置这种环境的命令, 它就是 git clone。 从技术上来讲，git clone 命令在真实的环境下的作用是在本地创建一个远程仓库的拷贝（比如从 github.com）

git clone

假设下图是我们的远程仓库
用动图带你更清晰的零基础掌握 Git 常用命令
我们在通过git在本地目录输入以下命令

输入git clone

在这里插入图片描述
我们会发现左侧多了一个一模一样的仓库，用实线表示，这个会复制到我们当下的本地目录中，图仅供演示，不代表是远程仓库多了一份一模一样的仓库

远程分支

既然你已经看过 git clone 命令了，咱们深入地看一下发生了什么。

你可能注意到的第一个事就是在我们的本地仓库多了一个名为 o/main 的分支, 这种类型的分支就叫远程分支。由于远程分支的特性导致其拥有一些特殊属性。

远程分支反映了远程仓库(在你上次和它通信时)的状态。这会有助于你理解本地的工作与公共工作的差别 —— 这是你与别人分享工作成果前至关重要的一步.

远程分支有一个特别的属性，在你切换到远程分支时，自动进入分离 HEAD 状态。Git 这么做是出于不能直接在这些分支上进行操作的原因, 你必须在别的地方完成你的工作, （更新了远程分支之后）再用远程分享你的工作成果

为什么有 o/ ？
你可能想问这些远程分支的前面的 o/ 是什么意思呢？好吧, 远程分支有一个命名规范 —— 它们的格式是:

/
因此，如果你看到一个名为 o/main 的分支，那么这个分支就叫 main，远程仓库的名称就是 o。

大多数的开发人员会将它们主要的远程仓库命名为 origin，并不是 o。这是因为当你用 git clone 某个仓库时，Git 已经帮你把远程仓库的名称设置为 origin 了

不过 origin 对于我们的 UI 来说太长了，因此不得不使用简写 o 😃 但是要记住, 当你使用真正的 Git 时, 你的远程仓库默认为 origin!

说了这么多，让我们看看实例
假设下图 左侧是我们clone的本地远程仓库 右侧是远程仓库
用动图带你更清晰的零基础掌握 Git 常用命令

如果我们切换到远程仓库分支并且提交会怎么样？

输入git checkout o/maingit commit

在这里插入图片描述
正如你所见，Git 变成了分离 HEAD 状态，当添加新的提交时 o/main 也不会更新。这是因为 o/main 只有在远程仓库中相应的分支更新了以后才会更新

Git Fetch

Git 远程仓库相当的操作实际可以归纳为两点：向远程仓库传输数据以及从远程仓库获取数据。既然我们能与远程仓库同步，那么就可以分享任何能被 Git 管理的更新（因此可以分享代码、文件、想法、情书等等）。

这里介绍如何从远程仓库获取数据 —— 命令如其名，它就是 git fetch。

你会看到当我们从远程仓库获取数据时, 远程分支也会更新以反映最新的远程仓库

在解释 git fetch 前，我们先看看实例。这里我们有一个远程仓库(虚线), 它有两个我们本地仓库中没有的提交
用动图带你更清晰的零基础掌握 Git 常用命令
我们使用 git fetch

输入git fetch

在这里插入图片描述
就是这样了! C2,C3 被下载到了本地仓库，同时远程分支 o/main 也被更新，反映到了这一变化

git fetch 做了些什么
git fetch 完成了仅有的但是很重要的两步:

  • 从远程仓库下载本地仓库中缺失的提交记录
  • 更新远程分支指针(如 o/main)
  • git fetch 实际上将本地仓库中的远程分支更新成了远程仓库相应分支最新的状态

如果你还记前面中我说过的，远程分支反映了远程仓库在你最后一次与它通信时的状态，git fetch 就是你与远程仓库通信的方式了！

git fetch 不会做的事
git fetch 并不会改变你本地仓库的状态。它不会更新你的 main 分支，也不会修改你磁盘上的文件

理解这一点很重要，因为许多开发人员误以为执行了 git fetch 以后，他们本地仓库就与远程仓库同步了。它可能已经将进行这一操作所需的所有数据都下载了下来，但是并没有修改你本地的文件。我们在后面的课程中将会讲解能完成该操作的命令 😄

所以, 你可以将 git fetch 的理解为单纯的下载操作

Git Pull

既然我们已经知道了如何用 git fetch 获取远程的数据, 现在我们学习如何将这些变化更新到我们的工作当中

其实有很多方法的 —— 当远程分支中有新的提交时，你可以像合并本地分支那样来合并远程分支。也就是说就是你可以执行以下命令:

git cherry-pick o/main
git rebase o/main
git merge o/main
等等
实际上，由于先抓取更新再合并到本地分支这个流程很常用，因此 Git 提供了一个专门的命令来完成这两个操作。它就是我们要讲的 git pull

假设下图是我们当前本地仓库(实线) 与 远程仓库(虚线)
用动图带你更清晰的零基础掌握 Git 常用命令
我们先来看看 fetch、merge 依次执行的效果

输入git fetchgit merge o/main

在这里插入图片描述
我们用 fetch 下载了 C3, 然后通过 git merge o/main 合并了这一提交记录。现在我们的 main 分支包含了远程仓库中的更新（在本例中远程仓库名为 origin）

如果使用 git pull 呢?

输入git pull

在这里插入图片描述
同样的结果！这清楚地说明了 git pull 就是 git fetch 和 git merge 的缩写！

Git Push

OK，我们已经学过了如何从远程仓库获取更新并合并到本地的分支当中。这非常棒……但是我如何与大家分享我的成果呢？

嗯，上传自己分享内容与下载他人的分享刚好相反，那与 git pull 相反的命令是什么呢？git push！

git push 负责将你的变更上传到指定的远程仓库，并在远程仓库上合并你的新提交记录。一旦 git push 完成, 你的朋友们就可以从这个远程仓库下载你分享的成果了！

你可以将 git push 想象成发布你成果的命令。它有许多应用技巧，稍后我们会了解到，但是咱们还是先从基础的开始吧……

注意 —— git push 不带任何参数时的行为与 Git 的一个名为 push.default 的配置有关。它的默认值取决于你正使用的 Git 的版本，但是在教程中我们使用的是 upstream。 这没什么太大的影响，但是在你的项目中进行推送之前，最好检查一下这个配置

假设我们的本地仓库(实线)与远程仓库(虚线)如下：
用动图带你更清晰的零基础掌握 Git 常用命令
我们可以发现本地比远程多了一些提交
我们现在要推送到远程仓库中

输入git push

在这里插入图片描述
远程仓库接收了 C2，远程仓库中的 main 分支也被更新到指向 C2 了，我们的远程分支 (o/main) 也同样被更新了。所有的分支都同步了！

偏离的工作

现在我们已经知道了如何从其它地方 pull 提交记录，以及如何 push 我们自己的变更。看起来似乎没什么难度，但是为何还会让人们如此困惑呢？

困难来自于远程库提交历史的偏离。在讨论这个问题的细节前，我们先来看一个例子

假设你在周一，克隆了一个仓库，然后开始研发某个新功能。到周五时，你新功能开发测试完毕，可以发布了。但是 ,天啊！你的同事这周写了一堆代码，还改了许多你的功能中使用的 API，这些变动会导致你新开发的功能变得不可用。但是他们已经将那些提交推送到远程仓库了，因此你的工作就变成了基于项目旧版的代码，与远程仓库最新的代码不匹配了。

这种情况下, git push 就不知道该如何操作了。如果你执行 git push，Git 应该让远程仓库回到星期一那天的状态吗？还是直接在新代码的基础上添加你的代码，亦或由于你的提交已经过时而直接忽略你的提交？

因为这情况（历史偏离）有许多的不确定性，Git 是不会允许你 push 变更的。实际上它会强制你先合并远程最新的代码，然后才能分享你的工作

比如我们看下面的本地仓库与远程仓库
用动图带你更清晰的零基础掌握 Git 常用命令
我们可以明显的发现，在远程仓库中已经更新到了C2提交 (可能是同事提交的)
但你本地还没有与远程仓库同步
此时如果进行 git push
将会报错 ，并且不会发生任何变化

失败是因为你最新提交的 C3 基于远程分支中的 C1。而远程仓库中该分支已经更新到 C2 了，所以 Git 拒绝了你的推送请求

那该如何解决这个问题呢？很简单，你需要做的就是使你的工作基于最新的远程分支。

有许多方法做到这一点呢，不过最直接的方法就是通过rebase 调整你的工作

如果我们在 push 之前做 rebase 呢？
还是以下图为例子
用动图带你更清晰的零基础掌握 Git 常用命令

输入git fetch //下载远程最新的提交git rebase o/main //合并git push //提交

在这里插入图片描述
我们用 git fetch 更新了本地仓库中的远程分支，然后用 rebase 将我们的工作移动到最新的提交记录下，最后再用 git push 推送到远程仓库

这里可能会有疑问？合并的时候能不能用merge呢？？
当然可以，不过rebase会使得历史提交更为线性

如果觉得这种命令过于冗长

git fetch //下载远程最新的提交
git rebase o/main //合并
git push //提交

可以直接

git pull --rebasegit push

为什么不是直接git pull 然后 git push呢？
因为git pull 默认会使用merge合并，会保留历史，不会更线性

我们来演示一下

git pullgit push

在这里插入图片描述
可以明显看出保留了历史，并且提交并不是线性的

远程服务器拒绝!(Remote Rejected)

如果你是在一个大的合作团队中工作, 很可能是main被锁定了, 需要一些Pull Request流程来合并修改。如果你直接提交(commit)到本地main, 然后试图推送(push)修改, 你将会收到这样类似的信息:

! [远程服务器拒绝] main -> main (TF402455: 不允许推送(push)这个分支; 你必须使用pull request来更新这个分支.)

为什么会被拒绝?
远程服务器拒绝直接推送(push)提交到main, 因为策略配置要求 pull requests 来提交更新.

你应该按照流程,新建一个分支, 推送(push)这个分支并申请pull request,但是你忘记并直接提交给了main.现在你卡住并且无法推送你的更新.

解决办法
新建一个分支feature, 推送到远程服务器. 然后reset你的main分支和远程服务器保持一致, 否则下次你pull并且他人的提交和你冲突的时候就会有问题

假设下面是本地仓库与远程仓库
用动图带你更清晰的零基础掌握 Git 常用命令
当你在大团队中合作的时候，你没有权限直接git push主分支
按照我们之前的解决办法应该是以下操作

  • 新建一条分支 git branch feature
  • 回退本地main分支与远程仓库一致 git reset HEAD^
  • 切换到新分支上 git checkout feature
  • 推送 git push

🔗 关于 origin 和它的周边 —— Git 远程仓库高级操作

未完待续…

📋 总结

这些基本上包含的Git中大部分常用的基础命令
我并没有详细的介绍每一个命令后所带的参数，因为太多了
如果需要用到，可以直接网上搜索
后续我会继续完善本文章，争取把大部分常用的Git命令总结出来

网络标签：

相关问题