Git常用命令 | 飙戈的博客

type

status

date

slug

summary

概述

1、配置

git config 命令就是对 git 进行一些配置。git 的配置文件有三种级别：

.git/config 文件，即「仓库级配置」文件：这个配置中的设置只对当前所在仓库有效。使用.git/config --local，此时读写的就是这个文件。这里的配置仅仅针对当前项目有效。

~/.gitconfig 文件，即「全局级配置」文件：用户目录下的配置文件只适用于该用户。可以使用 git config --global 选项去设置它。

/etc/gitconfig 文件，即「系统级配置」文件：系统中对所有用户都普遍适用的配置。可以使用 git config --system 选项。

通过下面命令可以查看或者修改不同级别的 config。

1.1 配置操作

1.1.1 查看配置

1.1.2 新增配置

key 和 value 必须成对出现，缺一不可，缺项则报错。默认情况，即添加到 local 配置中。

1.1.3 修改配置

1.1.4 删除配置

1.2 代理

1.2.1 查看代理

1.2.2 设置代理

1.2.3 取消代理

2、仓库和分支

2.1 远程仓库

2.1.1 拉取远程仓库到本地

2.1.2 查看远程仓库信息

2.1.3 添加远程仓库地址

2.1.4 查看某个远程仓库

2.1.5 远程仓库重命名

2.1.6 移除远程仓库

2.2 远程分支

2.2.1 查看远程分支

2.2.2 推送分支到远程仓库

upstream 和 downstream：相当于把远程分支和本地分支进行绑定，当我们把仓库 A 中某分支 x 的代码 push 到仓库 B 分支 y，此时仓库B的这个 y 分支就叫做 x 分支的 upstream，而 x 则被称作 y 的 downstream。

2.2.3 删除远程分支

2.2.4 拉取远程分支到本地

有 git fetch 和 git pull 两种方式，两者的区别：

git fetch 是将远程主机的最新内容拉到本地，用户在检查了以后决定是否合并到工作本机分支中。本地的库中 master 的 commitID 不变，还是等于 1。

git pull 则是将远程主机的最新内容拉下来后直接合并，本地的库中 master 的 commitID 发生改变，变成了2，这样可能会产生冲突，需要手动解决。

拉取并创建本地分支

2.3 本地仓库

2.3.1 查看本地仓库的状态

2.3.2 查看本地仓库的提交历史

2.3.3 查看某次提交的详细信息

2.3.4 查看指定文件的修改记录

2.4 本地分支

3.1.1 删除本地分支

3、常用操作

3.1 提交和修改

3.1.1 提交

git add 命令可将该文件的修改添加到暂存区。

git commit 命令将暂存区内容添加到本地仓库中。

3.1.2 修改提交历史

修改最近一次提交的commit信息

git rebase 可以修改或者合并多次历史提。在交互模式下，可以选择要编辑、删除、交换历史提交。

修改多个commit信息的步骤：

git rebase -i 列出 commit 列表

找到需要修改的 commit 记录，把 pick 修改为 edit 或 e，:wq 保存退出

修改 commit 的具体信息git commit --amend，保存并继续下一条git rebase --continue，直到全部完成

中间也可跳过或退出git rebase (--skip | --abort)

git rebase修改提交历史

1、查看提交历史

例如显示如下

我们要把前四次提交合并

2、使用git rebase

或者

bf11695c 为第五次提交的hash值（只需要取前几位），会把第五次提交之前也就是前四次提交合并

显示如下

commit id 前面的 pick 是一个配置项，具体可选配置如下：

p，pick：保留该 commit

r，reword：保留该 commit，但我需要修改该 commit 的注释

e，edit：保留该 commit，但我要停下来修改该提交(不仅仅修改注释)

s，squash：将该 commit 和前一个 commit 合并

f，fixup：将该 commit 和前一个 commit 合并，但我不要保留该提交的注释信息

x，exec：执行 shell 命令

d，drop：丢弃该 commit

我们把 pick 改成 f 或者 s ，保存退出，然后输入以下命令：

或者把 pick 改成 e ，保存退出，然后重复执行下面命令直到完成

中间也可跳过或退出 rebase 模式

3、同步到远程仓库

3.1.3 取消文件追踪

未 add 的文件，通过 .gitignore 文件排除。注意，.gitignore 只能忽略那些原来没有被 track 的文件，如果某些文件已经被纳入了版本管理中，则修改 .gitignore 是无效的。

已 add 的文件，通过 git rm 删除后，再 add 提交

3.2 合并

git rebase 和 git merge 这两个命令都可以用来集成从一个分支和另一个分支的更改。它们的区别是：

git merge 将两个分支中的所有提交都合并到一起，并创建一个新的合并提交，保留了历史记录。这导致了 Git 历史记录中出现多个分支合并点的情况，从而使历史记录更加复杂。

git rebase 是将一个分支的提交序列“拉直”，并且将其与另一个分支合并。这意味着，提交历史看起来好像是一条直线，没有分叉，因此整个提交历史看起来更加整洁，历史记录保持相对简单。

总的来说，git rebase 可以提供更整洁的提交历史，但它需要更多的注意力和精细的操作，因为它可能导致原有的提交变得不可用。git merge 则是更为保守的合并方法，它更简单，但历史记录更加复杂。因此，选择哪种方法取决于团队和项目的需求和偏好。

git merge和git rebase的区别

3.2.1 git merge合并

git merge 有三个合并参数：

ff：自动合并模式，当合并的分支为当前分支的后代的，那么会自动执行 --ff (Fast-forward) 模式，如果不匹配则执行 --no-ff（non-Fast-forward）合并模式

-no-ff：非 Fast-forward 模式，在任何情况下都会创建新的 commit 进行多方合并（及时被合并的分支为自己的直接后代）

-ff-only：Fast-forward 模式，只会按照 Fast-forward 模式进行合并，如果不符合条件（并非当前分支的直接后代），则会拒绝合并请求并且退出

git merge的三种模式区别

3.2.2 git rebase合并

与git merge命令不同，git rebase会将提交逐个应用到目标分支上，并按照提交顺序重新组织提交历史。这种操作可以让代码库的提交历史更加整洁、线性，并且方便后续的代码审查和维护。

常用命令

假设我们有一个开发分支和一个主分支，现在我们要将开发分支的修改合并到主分支上。以下是一种常见的使用Git Rebase的步骤：

首先，切换到主分支：git checkout main。

执行 git pull命令，确保主分支是最新的。

切换回开发分支：git checkout dev。

执行 git rebase main命令，将开发分支的提交逐个应用到主分支上。

如果在 rebase过程中出现冲突，使用 git status查看冲突文件，并手动解决冲突。

使用 git add <file> 命令将解决冲突后的文件标记为已解决。

使用 git rebase --continue 命令继续rebase操作，直到所有提交都被应用到主分支上。

最后，切换回主分支：git checkout main。

使用 git merge dev 命令将主分支与开发分支合并。

3.2.3 合并后解决冲突

上面为本地版本，下面为远程版本解决冲突后需要重新 add 和 commit

3.2.4 中断合并

在合并的时候，出现了冲突，但是还没有解决冲突，没有进行提交的时候，放弃合并。

3.3 回滚

回滚有下面几种方式：

git checkout：针对修改后未 add 的提交。将当前 HEAD 指针指向指定的提交，也就是将该次提交的内容检出到工作区。

git reset：使 HEAD 节点指向之前的提交，该提交及之前的 commit 都会被保留，但是此 commit 之后的修改都会被删除，会改变提交历史。生产建议慎用。

git revert：创建一个新的提交来撤销之前的提交，不会改变提交历史，可以用于安全地撤销已发布的提交。

git restore ：还原文件到最新提交的状态、丢弃未暂存的更改、丢弃已暂存但未提交的更改等。

git checkout、git reset和git revert的区别

3.3.1 git checkout

git checkout 针对修改后未 add 的提交。

3.3.2 git reset

git reset 用于回退版本，可以指定退回到某一次提交的版本，针对 add 和 commit 的提交。有三种模式：

-soft：缓存区和工作目录都不会被改变

-mixed：缓存区和你指定的提交同步，但工作目录不受影响（但不会恢复被删除的文件和内容），默认选项。

-hard：缓存区和工作目录都同步到你指定的提交

3.3.3 git revert

git revert 用于撤销一次提交的修改，并创建一个新的提交来记录，只能修改 commit 的提交。

revert 是撤销一次提交，所以后面的 commit id 是你要撤销的 commit id ，而不是撤销到该 commit，这也是 revert 和 reset 的重要区别。比如 git revert HEAD 撤销最近一次提交，git reset HEAD 则是撤回到最近一次提交的版本（结果就是没有变化）。

使用 revert HEAD 是撤销最近的一次提交，如果你最近一次提交是用 revert 命令产生的，那么你再执行一次，就相当于撤销了上次的撤销操作，换句话说，你连续执行两次 revert HEAD命令，就跟没执行是一样的

3.1.3 git restore

git restore 是 Git 2.23 版本引入的一个命令，可以还原文件到最新提交的状态、丢弃未暂存的更改、丢弃已暂存但未提交的更改等。作用有点类似于 git checkout

3.4 缓存区

git stash 用于缓存区。缓存区修改一般使用场景：

在某个分支上做了一些修改，但是不想保存到该分支，想把修改保存到一个新的分支。

在某个分支上开发的过程中，突然需要切换到另外一个分支上，但是目前只开发到一半还不想提交add和commit的信息。

3.4.1 保存所有未提交的修改到stash

3.4.2 查看当前stash中的内容

3.4.3 弹出并删除当前stash中的内容

3.4.4 弹出不删除当前stash中的内容

3.4.5 删除stash内容

3.4.6 清空stash

3.4.7 显示stash和当前目录的差异

4、标签

Git 可以给仓库历史中的某一个提交打上标签，以示重要。比较有代表性的是人们会使用这个功能来标记发布结点（ v1.0 、 v2.0 等等），方便后期回溯。

4.1 列出已有的tag

加上 -l 或者 --list 命令可以使用通配符来过滤 tag。

4.2 新建tag

4.3 查看tag详细信息

git show 命令可以查看 tag 的详细信息，包括备注、 commit 号等。

4.4 切换到某个tag

跟分支一样，可以直接切换到某个 tag 去。这个时候不位于任何分支，处于游离状态。

如果你做了某些更改然后提交它们，标签不会发生变化，但你的新提交将不属于任何分支，并且将无法访问。可以考虑基于这个 tag 创建一个分支。

4.5 将tag同步到远程服务器

同提交代码后，使用 git push 来推送到远程服务器一样，tag 也需要进行推送才能到远端服务器。

4.6 从远程服务器拉取tag

tag 在使用 git pull 或者 git fetch 拉取远程分支的时候，会自动把远程服务器的 tag 同步到本地。

概述