当前位置：首页 > news >正文

Git教程

news 2026/2/9 0:17:09

文章目录

Git 介绍
GIt历史
Git 安装
环境配置
工作区、缓存区和仓库区（版本库）
- 工作区(工作目录)
- 暂存区
- 仓库区
- git工作目录下文件的装填
Git 生成公钥及添加到gitlab或Gerrit上
Git常用命令
- git stauts
- git statu -s
- git add
- git commit
- git reset
- - 1. git reset --hard
  - 2. git reset HEAD
  - 3. `git reset --hard`
- git reflog
- git log
- git checkout
- git diff
- git stash
- git rebase
- git branch
- git clean
- git remote
- git fetch
- git pull
- git push
- - git push <远程主机名> <本地分支名> : <远程分支名>
- git blame
git 常用举例
- git log输出格式
- 查看一个文件提交的提交记录
- - 查看一个文件的提交记录
  - 查看单个文件提交记录及内容
  - 查看某次提交中的某个文件变化
  - 显示每次提交的diff
其他问题
分支管理
- 合并模式
- 合并冲突
git 打补丁
注意事项
参考链接：

Git 介绍

GIt历史

Git 安装

环境配置

git config --list 查看信息
git config --global user.name “your name” // 设置username
```
git config --global user.name "yourname"
```
git config --global user.email “your_email@youremail.com” // 设置邮箱
git config user.name 查看username

工作区、缓存区和仓库区（版本库）

在这里插入图片描述

工作区(工作目录)

就是你在电脑里能看到的目录。对于添加、修改、删除文件的操作，都发生在工作区中。包含.git文件夹的目录就是工作目录，主要用于存放开发的代码

暂存区

暂存区指将工作区中的操作完成小阶段的存储，是版本库的一部分

仓库区

工作区有一个隐藏目录.git,这个不是工作区，而是git的版本库，版本库中存储了很多配置信息、日志信息和文件版本信息等，其中最重要的就是称为stage(或者叫index)的暂存区，仓库区中记录的各版本是可以查看并回退的，但是在暂存区的版本一旦提交就再也没有了。
在这里插入图片描述
因为我们创建git版本库时，git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。
你可以简单理解为，需要提交的文件修改通通放到暂存区【计算机的缓存区】，然后，一次性提交暂存区的所有修改，创建一个版本，放到master分支中。HEAD永远指向Master分支中的最新版本的。

git工作目录下文件的装填

Git工作目录下的文件存在两种状态：

untracked 未跟踪（未被纳入版本控制）
比如说新建了个文件，没有git add。
tracked 已跟踪的三种状态（被纳入版本控制）
- Unmodified 未修改状态
- Modified 已修改状态
- Staged 已暂存状态

Git 生成公钥及添加到gitlab或Gerrit上

通过SSH拉取代码时，实际上是通过公钥的验证机制来实现身份认证。具体过程如下：
1. 在本地电脑上，使用命令ssh-keygen生成一对公钥和私钥，将公钥保存在本地电脑的一个文件中（例如~/.ssh/id_rsa.pub）。
2. 将公钥（即上一步生成的文件中的内容）复制到服务器上。
3. 当你使用SSH协议从本地电脑连接到服务器并进行代码拉取或推送时，Git会自动查找本地电脑上的私钥，然后使用该私钥对身份进行验证，以确认是本地电脑所有者访问服务器。
4. 如果公钥与私钥匹配，服务器将接受身份验证并允许你访问代码库。
总之，通过SSH拉取代码时，需要确保本地电脑上的公钥已经添加到服务器中，以便在进行身份验证时可以让服务器确认你的身份。

进入ssh目录
cd ~/.ssh
查看是否生成公钥
ls
2.1 若存在，则目录下会有后缀为.pub的文件，如果不存在就自己生成公钥

2.2 如果不存在，生成公钥
先通过 git config --list 查看自己的邮箱
再通过ssh-keygen -t rsa -C "你的邮箱"命令生成公钥
查看公钥
cat id_rsa.pub
复制公钥分别添加到gitlab和Gerrit上
git lab添加公钥如下：

gerrit添加和gitlab步骤一样。

Git常用命令

git stauts

查看文件状态

git statu -s

输出更简洁的文件状态。

git add

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

git add 【file】【file2】…

添加一个或多个文件到暂存区
git add 【dir】

添加指定目录到暂存区，包括子目录
git add .

添加当前目录下的所有文件到暂存区
git add -A （git add --all 的简写形式）

它会将当前整个工作区中所有的文件改动提交至暂存区，包括新增、修改和被删除的文件，不受当前所在目录限制。
git add *.c

提交以.c结尾的文件。

git commit

git commit 命令一次性将暂存区所有内容添加到本地仓库中，并创建一个版本。

git commit -m [message]

提交暂存区到本地仓库中。 [message] 是备注消息
git commit [file1] [file2] … -m [message]

提交暂存区的指定文件到仓库区。
git commit -a 或者 git commit -am [message]

如果你觉得 git add 提交缓存的流程太过繁琐，Git 也允许你用 -a 选项跳过这一步，直接来提交。-a命令针对是tracked的文件（即已经放入仓库中的文件）。

git commit --amend

 在上一个commitID上继续提交，不新增新的提交，默认打开VIM编辑器，是否要修改commit信息

git commit --amend --no-edit
```
 可以不修改commit信息直接进行提交
```
如果你没有设置 -m 选项，Git 会尝试为你打开一个编辑器以填写提交信息。如果 Git 在你对它的配置中找不到相关信息，默认会打开 vim。

注：在 Linux 系统中，commit 信息使用单引号 '，Windows 系统，commit 信息使用双引号 "。所以在 git bash 中 git commit -m ‘提交说明’ 这样是可以的，在 Windows 命令行中就要使用双引号 git commit -m “提交说明”。

git reset

1. git reset --hard

后面不跟版本号，清除暂存区和工作区中tracked的改动。不会清除untracked的改动

其中HEAD表示当前分支最新版本【请记死】
在这里插入图片描述

HEAD^ 表示当前版本的前一个版本，

git reset --hard HEAD^

HEAD^^表示当前版本的前前个版本，也可以使用HEAD~1表示当前版本的前一个版本，HEAD~100表示当前版本的前100版本。

提示：这种都表示回退操作

git reset --hrad 版本号

回到指定的版本，这个存在两种情况。

git reset --hard commit_id
commit_id 是完整的。并且是git log 能够查到的否则会报错 unknown revision or path not in the working tree.
git reset --hard (通过 git reflog 查到的)

为什么有两种情况呢，存在这种场景，比方说我们分别提交了两个版本1 和版本2 ，提交顺序：版本1在前，版本2在后，当前Head指向版本2，现在执行git reset --hard HEAD^ 回退了一下，git log 看到的只有版本1的情况。即使你知道版本2的完整的commit_id ，执行git reset --hard commit_id 报错，只能通过
在这里插入图片描述
git reset --hard b79613 切换到版本2。

git reset --hrad origin/《分支名》

回退到某个远程分支某个commit。
有这样的场景，我们和远程分支相同的内容下，又做了修改，但是又想回退到和远程分支相同的情况，就可以执行这个。

2. git reset HEAD

撤销暂存区中的修改，从暂存区回到了工作区，既提交了，想撤回。但是本地的修改并不会消失(工作区的内容不会改变)。

git reset HEAD …

撤销指定文件的add
也可以指定不同版本的file
git reset HEAD *

撤销本地add的所有文件
git reset HEAD *.txt

3. `git reset --hard`

git reflog

可以查看所有版本的历史信息
在这里插入图片描述
git reflog命令中保留了从clone仓库开始，用户所有在本地库中的操作。

参考：https://www.jianshu.com/p/7e4cef3863e7

git log

git log 命令只可以查看到HEAD指针及其之前的版本信息，如果版本发生过回退操作，则可能会出现，HEAD指针之后仍存在历史提交版本的情况，而这些提交版本信息通过git log命令是看不到的。

git checkout

git checkout -- <文件> <文件> ...

git checkout -- <文件>来丢弃工作区指定文件的改动

2. git checkout *

丢弃工作区中所有文件的改动

git checkout -- *.txt

git diff

对比两个版本的差异

git diff

对比的是工作区修改之前和修改之后的差异。
git diff 版本1 版本2

对比的是版本1 和版本2 之间的差异
```
git diff HEAD HEAD^
```
git diff 分支1 分支2
git diff 文件

git stash

场景：当你接到一个修复一个代号001的bug的任务时，很自然地，你想创建一个分支bug-001来修复它，但是，等等，当前分支正在上进行的工作还没有提交：
并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug,怎么办？

在这里插入图片描述
git stash ：git还提供了一个stash功能，可以把当前工作现场“储藏“起来，等以后恢复现场后继续工作。即缓存起来。

git stash save "save message"
执行存储时，添加备注，方便查找，只有git stash 也要可以的，但查找时不方便识别。
git stash list
查看stash了哪些存储
git stash show
显示做了哪些改动，默认show第一个存储,如果要显示其他存贮，后面加stash@{$num}，比如第二个 git stash show stash@{1}
git stash apply
应用某个存储,但不会把存储从存储列表中删除，默认使用第一个存储,即stash@{0}，如果要使用其他个，git stash apply stash@{$num} ，比如第二个：git stash apply stash@{1}
git stash pop
命令恢复之前缓存的工作目录，将缓存堆栈中的对应stash删除，并将对应修改应用到当前的工作目录下,默认为第一个stash,即stash@{0}，如果要应用并删除其他stash，命令：git stash pop stash@{$num} ，比如应用并删除第二个：git stash pop stash@{1}
git stash drop stash@{$num}
丢弃stash@{$num}存储，从列表中删除这个存储
git stash clear
删除所有缓存的stash
注意 untracked的文件，执行stash是不会被存储的。

新建了一个e.txt，e.txt并没有被加入到版本控制，git add 把文件加入到版本控制之后才行。

git rebase

参考：
https://blog.csdn.net/weixin_42310154/article/details/119004977
https://blog.csdn.net/qq_39512532/article/details/110260369

git branch

后面什么都不写，列出所有本地分支

git branch -r

列出所有远程分支
git branch -a

列出所有本地分支和远程分支
git branch <分支名>

创建分支
git checkoout -b <分支名>

创建并切换分支
git checkout -b 本地分支名x origin/远程分支名x

使用该方式会在本地新建分支x，并自动切换到该本地分支x。采用此种方法建立的本地分支会和远程分支建立映射关系（跟踪远程分支）。
git checkout <分支名>

切换分支
git merge <分支名>

合并分支到当前分支
git branch -d <分支名>

删除分支
git branch -m <旧分支名字> <新分支名字>

git branch -m master main
把master分支名字，改为新分支名字。

git clean

git clean -f

删除当前目录下所有untracked的文件. 它不会删除.gitignore文件里面指定的文件夹和文件, 不管这些文件有没有被track过
git clean -df

删除当前目录下没有untracked的文件和文件夹

和git reset --hard 是一对好基友，结合使用他们能让你的工作目录完全回退到最近一次commit的时候

git remote

如果想查看已经配置的远程仓库服务器，可以运行 git remote 命令。它会列出指定的每一个远程服务器的简写。如果已经克隆了远程仓库，那么至少应该能看到 origin ，这是 Git 克隆的仓库服务器的默认名字

git remote
git remote -v
git remote add 添加一个新的远程 Git 仓库，同时指定一个可以引用的简写

这个使用场景式：我本地已经创建了git仓库，但是我想和远程仓库建立联系。即通过git remote add <shortname> <url> 添加远程仓库。
git remote rm

如果因为一些原因想要移除一个远程仓库，可以使用 git remote rm
注意：此命令只是从本地移除远程仓库的记录，并不会真正影响到远程仓库

git fetch

git fetch 是从远程仓库获取最新版本到本地仓库，不会自动merge
在这里插入图片描述

git pull

git pull 是从远程仓库获取最新版本并merge到本地仓库
在这里插入图片描述

如果当前本地仓库不是从远程仓库克隆，而是本地创建的仓库，并且仓库中存在文件，此时再从远程仓库拉取文件的时候会报错（fatal: refusing to merge unrelated histories ），解决此问题可以在git pull命令后加入参数**–allow-unrelated-histories**

git push

当你想分享你的代码时，可以将其推送到远程仓库。命令形式：git push [remote-name] [branch-name]
在这里插入图片描述
远程仓库 master分支多了 hello.txt文件。

git push <远程主机名> <本地分支名> : <远程分支名>

git push origin HEAD:refs/for/master

git push 肯定是推送
origin : 是远程的库的名字
HEAD: 是一个特别的指针，它是一个指向你正在工作的本地分支的指针，
可以把它当做本地分支的别名，git这样就可以知道你工作在哪个分支
refs/for :这个不是git的规则，而是gerrit的规则，意义在于我们提交代码到服务器之后是需要经过 code review 之后才能进行merge的
refs/heads：不需要
简单来说： refs/for/mybranch需要经过code review之后才可以提交；refs/heads/mybranch不需要code review

git blame

git blame用来追溯一个指定文件的历史修改记录

git blame用来追溯一个指定文件的历史修改记录。它是显示任何文件中每行最后一次修改的提交记录。 所以，如果你在代码中看到有一个bug，你可以使用 git blame 标注这个文件，查看哪一次提交引入了这行。

命令用法：

git blame filename

可以使用 -L 指定文件的行数范围：

git blame -L n1,n2 filename

举例

git blame -L 69,82 Makefile		查看Makefile这个文件第69--82行最近一次的修改记录

git 常用举例

git log输出格式

git log --pretty是指定Git log命令的输出格式。

git log --pretty=oneline // 将每个commit 以一行显示。包括了commit的SHA-1值和提交信息的第一行

查看一个文件提交的提交记录

查看一个文件的提交记录

git log filename  // git log 直接与文件相关的提交记录
git log --pretty=oneline filename

查看单个文件提交记录及内容

git log -p filename

查看某次提交中的某个文件变化

git show commitId filename //使用git show命令 后跟commitId和文件名

显示每次提交的diff

git log -p filename

其他问题

克隆http和ssh有什么区别？
http不管你是谁，都可以下载【克隆】/提交项目代码。每次提交代码需要你输入用户名和密码；
SSH，如果你的电脑需要与github上的仓库交互，那么就要把你的电脑的ssh公钥添加到这个github账户上。
比如工作中你是ZXC这个项目组的成员，拥有者，你把你每天的代码——本地电脑跟github上公司项目交互，你得是这个项目的成员或者拥有者才能提交代码，这个方式就不需要输入用户名和密码提交代码，直接提交。工作中，你的老大会找你要你的github账号，邀请你到项目组，你是小组成员，为了方便提交代码，此时用SSH方式，工作中都是这种方式。SSH方式有一个条件要记住:你是项目的拥有者或组成员才可以使用此方法。知道这些就够了。

分支管理

(1)一开始的时候，master分支是一条线，git用master指向最新的提交，再用HEAD指向master,就能确定当前分支，以及当前分支的提交点：
在这里插入图片描述
每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长

（2）当我们创建新的分支，例如dev时，git新建了一个指针叫dev,指向master相同的提交，再把HEAD指向dev,就表示当前分支在dev上：
在这里插入图片描述

git创建一个分支很快，因为除了增加一个dev指针，改变HEAD的指向，工作区的文件都没有任何变化。

3)不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
在这里插入图片描述
(4)假如我们在dev上的工作完成了，就可以把dev合并到master上。git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

git合并分支也很快，就改改指针，工作区内容也不变。
（5）合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：
在这里插入图片描述

合并模式

Fast-forward信息，Git告诉我们，这次合并是“快进模式“，也就是直接把master指向dev的当前提交，仅仅是更新了分支的指针，不会产生合并提交，所以合并速度非常快。默认的合并行为。
合并冲突，遇到合并冲突的时候，需要处理冲突内容，然后再add、commit提交。
但是有些快速合并不能成功而且合并时没有冲突，这个时候git会帮我们在合并之后做一次新的提交，但这种模式下，删除分支后，会丢掉分支信息。使用的命令是 git merge --no-ff <分支名称> 不使用默认快速合并。

合并冲突

在master分支和dev分支对code.text文件有相同的位置修改了内容。合并两个分支的时候就会有冲突。
在这里插入图片描述

git用<<<<<<<<,========,>>>>>>>>标记不同分支的内容，我们修改如下后保存：
在这里插入图片描述
手动解决的方法就是删除箭头所指。然后再提交。

git 打补丁

参考：Git 补丁 —— diff 和 patch 使用详解

注意事项

跨系统拷贝git的代码，（比方说，你在Linux上拉取的代码，直接复制到Windows上去执行git操作），由于文件的属性变了，所以git操作会出现一些问题。如果想要在Windows上操作，尽量跨系拷贝，直接拉取代码即可。

参考链接：

强推：https://blog.csdn.net/YJG7D314/article/details/104551896