type
status
date
slug
summary
tags
category
icon
password
Git
1. Git 基本使用
1.1 创建 ssh key
将
.pub
后缀文件内容添加到 GitHub 或 Gitee 的 ssh 管理库中,这样我们的机器就已经实现了和远端 ssh 链接的能力,但是要想使用还需要配置一下 config 文件。1.2 拉取与创建仓库
有几种方式获取一个 Git 仓库。一种是从网络上或者其他地方拷贝一个现有的仓库,另一种就是在一个目录中创建一个新的仓库。
- 创建一个本地仓库:
git init
。该命令可以将一个目录转变成一个 Git 仓库。
- 克隆一个远程仓库:
git clone git@github.com:<用户名>/<仓库名>.git <本地目录>
。
git clone
实际上是一个封装了多个命令的命令。首先它创建了一个新目录,并切换到该目录,然后git init
来初始化一个空的 Git 仓库,然后为你指定的 URL 添加一个(默认名称为origin
的)远程仓库(git remote add
),再针对远程仓库执行git fetch
,最后通过git checkout
将远程仓库的最新提交检出到本地的工作目录。
1.3 全局与本地配置
- 全局配置
- 全局配置
- 删除全局配置
全局配置对所有项目的当前用户可用,并存储在
~/.gitconfig
文件下。可以通过传递选项 --global
使 git 从 Global 读取和写入,如下。- 本地配置
- 首先进入项目的根目录,也就是
.git
所在的文件夹 - 配置本地
本地配置仅适用于当前存储库(文件夹)。您可以通过传递选项
--local
使 git 从本地读取和写入。一般不会用,除非你电脑上有多个 GitHub / Gitee 账号需要配置,每个账号下又有各自的仓库,此时就可以用到本地配置,以防在
123@qq.com
账号的仓库中留下 456@gmail.com
的提交信息,甚至提交失败。或者
1.4 配置 config 文件(选)
该文件在
~/.ssh/config
,可以使多个 GitHub / Gitee 账号在同一电脑上共存。接下来做一点简单的解释,如下是使用 ssh 连接到远端服务器的一个命令:
ssh root@localhost -p 22
root
:即User
,登录的用户,需要在服务器中真实存在
@
:分隔符
localhost
:即HostName
,远程连接的域名或 IP
-p
:即Port
,指定某个端口之后输入密码即可远程连接到服务器上。
在这里,我们想要连接到 Github,就需要改变
User
为 git
; HostName
为 ssh.github.com
为什么选择 443 端口?
- 端口 443 是 HTTPS 的默认端口:
- HTTPS 是大部分网络环境中不可或缺的协议,443 端口通常不会被阻止。
- 使用 443 端口可以伪装成 HTTPS 流量,通过防火墙或代理服务器。
- 避免被防火墙阻断:
- 防火墙通常会阻止不常用或安全风险较大的端口(如 22),但为了确保浏览网页和 HTTPS 流量正常,443 通常被允许。
- GitHub 提供了专用的 SSH 服务:
- GitHub 支持通过 SSH over HTTPS 的方式来使用 443 端口。这实际上是通过 HTTP CONNECT 隧道将 SSH 流量传递到 GitHub 的服务器上。
那么
Host
是什么?我将其称之为
HostName
的别名,还是上面那段命令 ssh root@localhost -p 22
,是不是有点长?若是服务器没有域名只有 IP ,那么一堆无规则的数字一般不太好记。只要我们配置了 User
和 HostName
,那么就可以使用 ssh 别名
来实现连接。请注意:Host
是HostName
的别名,若是 config 中没有配置User
,那么也可以用ssh User@别名
。
IdentityFile
是私钥的文件地址,如果我们使用 ssh root@localhost -p 22
来远程连接 ,那么还需要输入密码,每次都这样非常麻烦,而有了私钥和公钥就可以省去这一过程。注:#1.6.3 关联远程仓库也同样适用
1.5 测试连接
有别名的写别名,没别名的写
github.com
或 gitee.com
,返回 Hi xxx! ...
则说明成功,如下。
1.6 Git 操作流程
说明:
- workspace:工作区
- staging area:暂存区/缓存区
- local repository:本地仓库
- remote repository:远程仓库
若是看不太懂可以跳转至 #2.4 结合三区位置了解

一般修改文件后提交就三个命令:
git add .
、git commit -m ""
、git push -u origin main
。如下查看具体说明。1.6.1 基本操作:
命令 | 说明 |
git init | 初始化仓库 |
git clone | 拷贝一份远程仓库,也就是下载一个项目 |
git add . | 添加已修改文件到暂存区 |
git status | 查看仓库当前的状态,显示有变更的文件 |
git diff | 比较文件的不同,即暂存区和工作区的差异 |
git commit -m "修改xxx文件" | 提交暂存区到本地仓库,并注释 |
git commit --amend | 修改上一个提交的注释信息,详情请看#2.5 |
git reset --hard <版本号> | 回退版本。版本号用 git log --online 查看 |
git rm | 将文件从暂存区和工作区中删除 |
git mv | 移动或重命名工作区文件 |
git branch | 查看所有分支 |
git checkout <分支名> | 分支切换 |
git merge <分支名> | 合并分支,先切换为主分支 |
git rebase <分支名> | 分支变基 |
git switch | 更清晰地切换分支 |
git restore | 恢复或撤销文件的更改 |
1.6.2 提交日志:
命令 | 说明 |
git log | 查看历史提交记录 |
git log --online | 查看版本记录 |
git blame <file> | 以列表形式查看指定文件的历史修改记录 |
1.6.3 远程操作:
以下
git@github.com
也可以更换为 别名
或 git@别名
。命令 | 说明 |
git remote -v | 查看关联的远程库 |
git remote remove origin | 取消关联的远程库 |
git remote add origin git@github.com:<用户名>/<仓库名>.git | 关联远程仓库 |
git remote set-url origin git@github.com:<用户名>/<仓库名>.git | 修改 https 通道为 ssh |
git fetch | 从远程获取代码库 |
git pull | 下载远程代码并合并 |
git push -u origin main | 上传远程代码并合并 |
git push origin <标签名> | 上传远程标签 |
git push -f origin main | 强推,删除远仓所有文件,将本地文件全推上去,慎用!! |
2 功能详解
2.1 分支
2.1.1 分支概念
分支是 git 的一个重要特性,它可以让开发人员从主线上分离出来,在一个独立的线路上继续开发,最后可以灵活的选择合并分支,还是丢弃分支。用一个生活中的例子,来理解分支:
比如我们正在写一本小说,这本小说的当前内容就像是 git 中的 master 分支,现在我们有几个新的想法,比如:新的角色、新的剧情,但不确定这些是否最终一定出现在故事里,所以我们可以这样做:
- 可以为每个新的想法,创建一个新的笔记本(一个笔记本就相当于 git 中的一个新分支)
- 每个笔记本(分支)中都可以自由地探索想法,且不会搅乱你的当前内容(master 分支)
- 当我们觉得一个剧情线非常好,并且想要将其包含在故事中时,就会把那个笔记本的内容(分支)合并到你的当前内容(master 分支)中。
- 如果某个想法实验失败,可以选择抛弃那个笔记本(相当于 git 中的删除分支),且这个过程不会影响当前内容(master 分支)
2.1.2 创建分支
- 使用
git branch xxx
可以创建分支;
- 使用
git checkout xxx
可以更改分支,其中xxx
是分支名字。
创建完分支后,分支并不是空的,而且保留了 master 分支当前所有的提交记录。
[!caution]
- 切换分支前,最好把当前分支管理好,即最好进行:
add
和commit
操作。
- 切换分支后,工作区、暂存区、会受到影响,具体为:
- 工作区:会变为切换到的分支的最后一次提交的状态
- 暂存区:同上,且如果暂存区有未提交的更改,那这些更改会被带到新分支的暂存区上。
比如:在 test 分支对 1.txt 文件进行了暂存,没提交,随后切换到 master 分支时,1.txt 文件会自动加在 master 分支的暂存区
2.1.3 合并分支
将两个分支的历史合并在一起,gti 会创建一个新的 " 合并提交 ",所有的分支和合并点都会被保留在历史中,有完整的历史记录。

2.1.4 分支变基
将一个分支(test)上的提交重新应用到另一个分支(master)上,变基会重写项目历史,因为它实际上是在创建一系列新的提交,会产生一个更线性的历史记录,看起来更干净、更简单。

2.1.5 游离分支
git checkout
也可以将代码签出到指定版本,即可以执行 git checkout <具体版本号>
,当签出到指定版本时,签出的代码出于一个游离分支中,如下图操作。
游离分支上可以对代码进行版本控制,但要注意:一旦从游离分支切走,游离分支的提交不会交给任何一个分支,所以对于游离分支我们的原则是:
- 尽量不修改游离分支的代码(只是看一看某个版本的代码)。
- 若确实需要修改游离分支代码,应该从当前游离分支,创建出一个新的分支,随后去修改。
- 若修在游离分支上发生了提交,随后从游离分支切走了,就要使用 reflog 寻找游离分支的提交。
2.2 tag(标签)
在 Git 中,标签(Tag)是用来指向特定提交的引用,通常用于标记项目中的重要点,比如版本发布。标签分为两种类型:
- 轻量标签(Lightweight)
轻量标签只是简单地指向一个提交,不包含其他信息,创建轻量标签不会存储任何额外的信息。
- 附注标签(Annotated)
附注标签存储了额外的信息,例如:标签名、标签信息、创建者名字、电子邮件、创建日期等。因为它们包含了更多的信息,附注标签更适用于公共或正式发布的场合,比如软件版本的发布。
2.2.1 创建标签
命令 | 作用 |
git tag 标签名 版本号 | 给指定提交打轻量标签。不写:最新 |
git tag -a 标签名 版本号 -m " 标签描述 " | 给指定提交打附注标签。不写:最新 |
git tag | 查看标签 |
git show 标签名 | 查看标签信息 |
git tag -d 标签名 | 删除标签 |
git push origin 标签名 | 提交标签 |
2.3 GitFlow
GitFlow 是团队开发的一种最佳实践,将代码划分为以下几个分支

分支 | 含义 |
master | 主分支,只保存正式发布的代码。 |
develop | 开发分支,开发者的编写的代码最终要出现在这个分支。 |
hotfix | 线上 bug 修复分支,修复完毕后要合并回 master 和 develop 分支,同时在 master 分支上打一个 tag。 |
feature | 功能分支,当开发某个功能时创建一个单独的分支,开发完毕后再合并到 dev 分支。 |
release | 待发布分支,Release 分支基于 Develop 分支创建,在这个 Release 分支上测试。 |
2.4 Git 三区位置

2.5 修改提交
git commit --amend
命令可以修改最近一次提交,它可以:- 重新编辑上次的提交信息。
如果在一次提交后,意识到提交信息有误或不够详细,可以使用
git commit --amend
来重新编辑上次提交信息- 将新的更改添加到上次提交中。
如果在一次提交后,意识到忘记将某文件提交了,可以先使用
git add .
将这些遗漏的更改添加到暂存区,然后通过 git commit --amend
将它们添加到上一个提交中。2.6 忽略文件
在项目开发过程中有些文件不应该存储到版本库中,这个时候配置忽略这些文件。
git 中需要创建一个文件
.gitignore
文件来设置忽略,.gitignore
文件与 .git
目录同级,常用规则如下:内容 | 含义 |
temp | 忽略任何路径下的名为 temp 的文件、文件夹。 |
*.log | 忽略任何路径下以.log 结尾的文件。 |
/dist | 忽略根目录下的 dist 文件,不会忽略其他目录下的 dist 文件 |
备注:.gitkeep
文件可以把空文件夹提交
3. 报错
3.1 git error:invalid path
git pull
的时候报错 git error:invalid path
原因:
源代码是在 linux 上编写的,但是在 Windows 上拉取代码却出现了问题。那么问题很可能是不通系统下文件属性或策略导致的。然后在 Git 文档上找到一个关于 NTFS 保护机制的配置:core.protectNTFS:If set to true, do not allow checkout of paths that would cause problems with the NTFS filesystem, e.g. conflict with 8.3 "short" names. Defaults to true on Windows, and false elsewhere.Windows 系统下默认值是 true,也就是说不符合 NTFS 策略的文件不会被签出,设置为 false 后可以关闭保护机制。
解决办法:
进入仓库目录打开 Git Bash:
再重新 pull 原分支:
3.2 Permission denied (publickey)
git clone
或 ssh -T git@github.com
的时候报错 git@github.com: Permission denied (publickey)
解决办法:
然后提示:
SSH_AUTH_SOCK=/tmp/ssh-kHOBLXgTAKU7/agent.593; export SSH_AUTH_SOCK; SSH_AGENT_PID=594; export SSH_AGENT_PID; echo Agent pid 594;
接着再输入:
- 注意,如果出现错误提示:
Could not open a connection to your authentication agent.
请执行命令:
eval ssh-agent -s
后,继续执行命令 ssh-add ~/.ssh/id_rsa
,这时候一般 OK 了。最后将 id_rsa.pub 的内容复制到 GitHub 账号,输入
ssh -T git@github.com
测试,出现 Hi xxx
则成功。3.3 kex_exchange_identification: read: Software caused connection abortbanner exchange: Connection to 20.205.243.166 port 22: Software caused connection abort
去 ~/.ssh/config 文件中把 HostName 修改为 ssh.github.com
3.4 Connection closed by 180.76.199.13 port 443
请注意,Gitee 和 Github 的端口可能不一样,Github 使用的是 443 端口,Gitee 使用的还是 22 端口,因此要注意 config 文件中端口是否配置正确,或者取消端口配置。

- 作者:林明菁
- 链接:https://blog.lxuan.fun/article/git
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议,转载请注明出处。
相关文章