【DevOps专项】Git 部署及使用方法

Cyber4K2026-04-23 10:20

Git版本控制服务器

GitHub ：https://github.com/

Gitee ：https://gitee.com/

GitLab ：https://gitlab.cn/

AtomGit ：https://atomgit.com

1.Git简介

1.1 什么是Git

​ Git是一个免费的、分布式的版本控制工具，或是一个强调了速度快的源代码管理工具。每一个Git的工作目录都是一个完全独立的代码库，并拥有完整的历史记录和版本追踪能力，不依赖于网络和中心服务器。

1.2 关于版本控制

​ **什么是版本控制？**版本控制是一种记录若干文件内容变化，以便将来查阅特定版本修订情况的系统。在本文所展示的例子中，我们仅对保存着软件源代码的文本文件作版本控制管理，但实际上，你可以对任何类型的文件进行版本控制。

我们用word写文档会遇到以下问题：

  1. 想删除一个段落，又怕将来想恢复找不回，然后把文件另存为，最后在windows下生成好多的文档。
  2. 过段时间想找回被删除的文字，已经不知道删除前保存在哪个文件。
  3. 想保留最新的一个，然后把其他的删掉，又怕哪天会用上，还不敢删。
  4. 有些文档需要别人帮助填写，你传给同事以后，你又更新了文档，然后同事填完文件又传给了你，怎么去合并文档。

​ 采用版本控制系统就可以解决上面遇到的所有问题。它可以统一进行版本控制，自动帮我们记录每次文件的改动，进行代码合并，不需要把文件传来传去，如果想查看某次改动，只需要在软件里瞄一眼就可以。

​ 有了版本控制你就可以将某个文件回滚到之前的状态，**甚至将整个项目都回退到过去某个时间点的状态。**你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而导致出现怪异问题，又是谁在何时报告了某个功能缺陷等等。使用版本控制系统通常还意味着，就算你乱来一气把整个项目中的文件改的改，删的删，你也照样可以轻松恢复到原先的样子。但额外增加的工作量却微乎其微。

1.3 Git内文件的三种状态及三个工作区域

1.3.1 三种状态

对于任何一个文件，在 Git 内都只有三种状态：

  • **已提交(committed)**表示该文件已经被安全地保存在本地数据库中了；
  • **已修改(modified)**表示修改了某个文件，但还没有提交保存；
  • **已暂存(staged)**表示把已修改的文件放在下次提交时要保存的清单中。
1.3.2 三个工作区域

由此我们看到Git管理项目时，文件流转的三个工作区域：

  • **工作目录：**从项目中取出某个版本的所有文件和目录，用以开始后续工作的叫做工作目录。这些文件实际上都是从 Git 目录中的压缩对象数据库中提取出来的，接下来就可以在工作目录中对这些文件进行编辑。所以工作目录就是写代码的地方，如果有新增、修改、删除文件都是在工作目录发生变化。工作目录的文件可以通过 git add 命令将文件提交到暂存区。
  • **暂存区：**所谓的暂存区域只不过是个简单的文件，一般都放在 Git 目录中的index文件（.git/index）中。有时候我们会把这个文件叫做索引文件，不过标准说法还是叫暂存区域。暂存区就是用来临时存储代码的一片区域，是已经修改了但是还没有提交，将来可以提交到本地库也可以撤回来。通过 git commit 命令可以将暂存区的文件提交到本地仓库。
  • **本地库：**每个项目都有一个 Git 目录（注：如果 git clone 出来的话，就是其中 .git 的目录；如果 git clone --bare 的话，新建的目录本身就是 Git 目录。），它是 Git 用来保存元数据和对象数据库的地方。该目录非常重要，每次克隆镜像仓库的时候，实际拷贝的就是这个目录里面的数据。本地库就是存储的实实在在的历史版本，可以通过 git push 命令来将本地库的文件推送到服务器。

2.部署Git及Git使用

2.1 环境

bash 复制代码 
Git-Server	172.25.254.44
Git-Client	172.25.254.45

2.2 软件安装

  • yum命令安装：此方法简单，并且会自动安装依赖的包，而且会从源里安装最新的版本，不过不一定是git最新的
  • 源码安装，这个要比yum方式较麻烦点，不过过程还是比较清晰的，毕竟源码安装也比较普遍了。
bash 复制代码 
[root@Git-Server ~]# yum install -y git
[root@Git-Client ~]# yum install -y git

需要ssh的支持。某些版本服务器需要安装git-core才是服务器

查看git版本

bash 复制代码 
]# git --version
git version 2.39.3

2.3 git使用

bash 复制代码 
# 在Git客户端设置当前操作系统用户的全局用户名和电子邮件地址。
]# git config --global user.name "xxxx"
]# git config --global user.email "xxx@xxxx.com
2.3.1 服务端创建仓库

创建git账号

bash 复制代码 
[root@cong11 ~]# useradd  git
[root@cong11 ~]# echo git:123456 | chpasswd

创建版本库(仓库)并初始化

bash 复制代码 
[root@Git-Server ~]# useradd git
[root@Git-Server ~]# echo 'git' | passwd --stdin git
[root@Git-Server ~]# su - git

[git@Git-Server project.git]$ git config --global user.name 'kaser'
[git@Git-Server project.git]$ git config --global user.email 'kaser@163.com'

[git@Git-Server ~]$ mkdir project.git
# 初始化仓库
[git@Git-Server ~]$ git init --bare project.git/

版本库又名仓库，可简单理解为一个目录，该目录里所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，在将来某个时刻可以"还原"。

2.3.2 客户端测试

git add,git status,git rm --cached <file>

bash 复制代码 
[root@Git-Client ~]# mkdir git
[root@Git-Client ~]# cd git/

# 从服务端拉取仓库
[root@Git-Client git]# git clone git@172.25.254.44:/home/git/project.git


[root@Git-Client project]# git config --global user.name "Saker"
[root@Git-Client project]# git config --global user.email "Saker@163.com


# 写入测试文件，并查看状态（提醒并未存储到暂存区）
[root@Git-Client project]# echo "No.1" >  Version.html
[root@Git-Client project]# git status

# 存入，并再次查看状态（提醒成功）
[root@Git-Client project]# git add Version.html
[root@Git-Client project]# git status

# 可以删去暂存区的具体文件，并再次查看状态
[root@Git-Client project]# git rm --cached Version.html
rm 'Version.html'
[root@Git-Client project]# git status

# 再次存入，并查看状态
[root@Git-Client project]# git add Version.html
[root@Git-Client project]# git status

git commit提交至本地仓库，git log查看日志

bash 复制代码 
[root@Git-Client project]# git commit -m "Version 1"
[root@Git-Client project]# git log
2.3.3 查看远程仓库信息

git remote -v 查看本地存储的远程仓库信息

bash 复制代码 
[root@Git-Client project]# git remote -v
origin  git@172.25.254.44:/home/git/project.git (fetch)
origin  git@172.25.254.44:/home/git/project.git (push)

说明：origin表示的是远程仓库的别名（默认为origin，fetch更新类似于update，push推数据相当于commit），以后提交代码的时候只需要使用origin这个别名即可。

2.3.4 添加远程仓库(扩展)

法1

bash 复制代码 
]# git remote add 仓库名 git@仓库地址:/xxxxxxxxxx

# 举例
]# git remote add origin git@172.25.254.44:/home/git/project.git

法2（ssh协议）

bash 复制代码 
]# git remote add 仓库名 ssh://git@仓库地址/xxxxxxxx

# 举例
]# git remote add origin ssh://git@172.25.254.44/home/git/project.git

法3（http协议）

bash 复制代码 
]# git remote add 仓库名 http://git@仓库地址/xxxxxxxx

]# git remote add origin http://git@172.25.254.44/home/git/project.git

（必须保证本地仓库里面有提交(commit)，注意是本地仓库而不是暂存区）

2.3.5 将本地仓库代码推送到远程仓库
bash 复制代码 
[root@Git-Client project]# git push origin master

上面就是一个标准的代码提交的过程，到此自己创建的文件就推到了远程的git仓库了。

2.3.6 git版本回退

git reset --hard <具体版本hash值>

bash 复制代码 
[root@Git-Client project]# cat Version.html
No.1

[root@Git-Client project]# echo "No.2" >>  Version.html
[root@Git-Client project]# cat Version.html
No.1
No.2

[root@Git-Client project]# git commit -m "Version 2"
[root@Git-Client project]# git log
bash 复制代码 
[root@Git-Client project]# git log
commit 8789f8898667725b823dc4aedda7eb51100bba05 (HEAD -> master)
    Version 2

commit 32f20d47638365bb85b052a654e128f608e1ec66 (origin/master)
    Version 1
    

[root@Git-Client project]# git reset --hard 32f20d47638365bb85b052a654e128f608e1ec66

[root@Git-Client project]# cat Version.html
No.1

[root@Git-Client project]# git reset --hard 8789f8898667725b823dc4aedda7eb51100bba05
[root@Git-Client project]# cat Version.html
No.1
No.2
  1. 先进行本地的版本回退 git reset --hard commit_id
  2. git reset 后，本地版本回退了，但无法直接 push 到远程仓库（因为远程仓库版本更加新）git push -f 覆盖推送即可
  3. 回退前，用 git log 可以查看提交历史，以确定要回退的commit_id。
  4. 如果后悔回退了，用 git reflog 查看命令历史，以便确定要回到的版本的commit_id。
2.3.7 删除本地仓库并克隆远程仓库
bash 复制代码 
[root@Git-Client project]# echo "No.3" >>  Version.html
[root@Git-Client project]# git add Version.html
[root@Git-Client project]# git commit -m "Version 3" Version.html
[root@Git-Client project]# git log
[root@Git-Client project]# git push origin master

[root@Git-Client ~]# rm -rf git/project/

[root@Git-Client ~]# git clone git@172.25.254.44:/home/git/project.git


[root@Git-Client ~]# git clone git@172.25.254.44:/home/git/project.git

[root@Git-Client ~]# ls -la project/
total 8
drwxr-xr-x   3 root root   38 Apr 19 21:33 .
dr-xr-x---. 15 root root 4096 Apr 19 21:33 ..
drwxr-xr-x   8 root root  163 Apr 19 21:33 .git
-rw-r--r--   1 root root   15 Apr 19 21:33 Version.html

[root@Git-Client ~]# cat project/Version.html
No.1
No.2
No.3

3.git使用扩展

这部分内容主要介绍一下Git的基本命令和操作，会从Git的版本库的初始化，基本操作和独有的常用命令三部分着手，让大家能够开始使用Git。

3.1 git初始化(git clone,git init+git remote add)

3.1.1 git clone
bash 复制代码 
# 示例如下：

]# mkdir -p xxxx  # git仓库目录
]# git clone git@远程仓库地址:仓库路径  xxxx



[git@Git-Server ~]$ mkdir Test.git
[git@Git-Server ~]$ git init --bare Test.git/

[root@Git-Client ~]# mkdir /New_Base
[root@Git-Client ~]# git clone git@172.25.254.44:/home/git/Test.git /New_Base/

注：上面命令实际是基于ssh协议的，如果不想通过密码验证，可以使用密钥对方式，需要将自己的公钥传到服务器，这样就可以不输入密码直接git clone。

3.1.2 git init,git remote
bash 复制代码 
[root@Git-Client ~]# mkdir /Ceshi
# 初始化git，指定git仓库路径，同时也是工作目录。
[root@Git-Client ~]# git init /Ceshi
[root@Git-Client Ceshi]# git remote add xxx ssh://git@172.25.254.44:/home/git/aaa.git
[root@Git-Client Ceshi]# git remote -v
xxx     ssh://git@172.25.254.44:/home/git/aaa.git (fetch)
xxx     ssh://git@172.25.254.44:/home/git/aaa.git (push)

3.2 git基本命令

3.2.1 git pull与git clone定位与区别

git clone 与 git pull 是 Git 版本控制中两个核心但定位完全不同的指令，其差异主要体现在执行前提、底层机制、作用范围与配置依赖四个维度：

  1. 执行前提与上下文依赖

    • git clone <url> 无需本地存在任何仓库环境。它可在任意空目录或系统路径下直接执行，Git 会自主创建目标文件夹并建立完整的版本控制上下文。
    • git pull 强依赖本地仓库上下文。执行时 Git 会递归向上查找 .git 元数据目录，若未找到则立即报错 fatal: not a git repository。必须在已初始化的项目目录内运行。

  2. 底层执行机制

    • git clone 是原子化的初始化+全量同步操作 。底层依次执行：创建目录 → git init 生成 .git 结构 → 将远程仓库自动注册为 origin → 执行 git fetch 下载全部对象（commits、trees、blobs）及所有分支引用 → 创建本地跟踪分支并检出默认分支（如 main）。
    • git pull 是增量更新操作 ，本质为 git fetch 与 git merge 的组合（若配置 pull.rebase=true 则为 fetch + rebase）。它仅下载远程分支相对于本地已有历史的新增提交对象，随后将差异合并至当前已检出的工作分支，并更新工作区文件。

  3. 作用范围与数据量

    • clone 针对整个远程仓库，一次性拉取全量历史、所有分支指针、标签及远程配置信息，数据量等于仓库完整体积。
    • pull 仅针对当前分支及其配置的 upstream 远程分支，仅同步自上次 fetch 之后的新增提交，数据量为增量大小。

  4. 配置状态与工作流定位

    • clone 自动写入 .git/config 中的 [remote "origin"] 区块，并建立本地分支与远程分支的跟踪关系（tracking branch）。属于项目接入阶段的一次性指令。
    • pull 依赖预先存在的远程配置。若本地仓库未通过 clone 或 remote add 绑定过远程源，或当前分支未设置跟踪关系，则必须显式指定 <remote> 与 <branch> 参数，否则提示需配置上游分支。属于日常开发阶段的高频同步指令。

在标准的团队协作工作流中，两者严格分工：clone 负责"环境搭建与首次数据获取"，pull 负责"持续集成与分支对齐"。混用或颠倒顺序将导致上下文缺失、重复下载或合并冲突。

你可以把 git clone 理解为"第一次搬家入住并配齐所有家具 "，而 git pull 则是"住进去之后，每天收快递补充新到的物品"。

  • 具体生活场景对照：

  • 当你换了一台新电脑，或者刚接手一个别人写好的项目，本地连文件夹都没有时，必须用 git clone。它会自动帮你建好项目文件夹、生成记录本（.git）、贴好服务器地址标签，并把服务器上所有的历史版本、所有分支的代码一次性完整搬到你电脑里。这是一次性动作，做完后你就拥有了可以正常工作的本地环境。

  • 当你已经用 clone 把项目拉下来了，并且每天都在本地写代码。某天同事向服务器提交了新功能或修复了 Bug，你想把这些更新同步到自己的电脑上，这时就该用 git pull。它只会去服务器核对"从你上次同步之后，多了哪些新改动"，然后自动把这些新内容合并到你正在干的活里。它不会重新下载整个项目，也不会新建文件夹。

  • 为什么不能混用或替代 ：

    如果你电脑里根本没有这个项目，直接敲 git pull，就像对着空房间喊"把新快递拿来"，系统根本不知道快递该放哪个柜子、怎么记账，只能报错拒绝。反过来，如果你本地已经有项目了还反复用 git clone，它会强行新建一个同名文件夹重新下载全套数据，导致硬盘里出现多份重复代码，不仅浪费空间，还会让你后续的版本记录彻底混乱，分不清该进哪个目录干活。

  • 实操建议 ：

    记住一个简单原则："从无到有用 clone，从有到新用 pull" 。在你之前的实验中，报错正是因为删除了本地文件夹后跳过了"安家"步骤，直接尝试"收快递"。今后操作时，首次接触远程仓库永远使用 git clone 仓库地址，之后每次开工前进入该目录执行 git pull，即可保持本地与服务器的平滑同步。

3.2.2 git pull拉取变更并应用（对齐并写入）

git pull=git fetch+git log+git diff+git merge

正确的实验路径应严格区分"首次获取"与"后续同步"两种场景：

  1. 首次获取远程仓库 ：必须使用 git clone <url>。该命令会自动创建目标目录、执行 git init、写入远程源配置（默认命名为 origin）、获取所有分支对象，并检出默认分支。
  2. 已存在本地仓库需更新 ：需先进入包含 .git 的目录，执行 git pull。若远程地址未配置，可先用 git remote add <name> <url> 绑定，再通过 git fetch 与 git merge 完成同步。
bash 复制代码 
# 示例
# 三个版本
[root@Git-Client project]# git log
commit 04467435b11c8827103f2068afb01727a2049ab8 (HEAD -> master, origin/master, origin/HEAD)
    Version 3
commit 8789f8898667725b823dc4aedda7eb51100bba05
    Version 2
commit 32f20d47638365bb85b052a654e128f608e1ec66
    Version 1
    

# 回退到版本2
[root@Git-Client project]# git reset --hard 8789f8898667725b823dc4aedda7eb51100bba05

# 确实是版本2
[root@Git-Client project]# git log
commit 8789f8898667725b823dc4aedda7eb51100bba05 (HEAD -> master)
    Version 2
commit 32f20d47638365bb85b052a654e128f608e1ec66
    Version 1

# 查看远程
[root@Git-Client project]# git remote -v
origin  git@172.25.254.44:/home/git/project.git (fetch)
origin  git@172.25.254.44:/home/git/project.git (push)

# git pull 拉取远程仓库
[root@Git-Client project]# git pull

# 再次查看，发现版本回到3
[root@Git-Client project]# git log
commit 04467435b11c8827103f2068afb01727a2049ab8 (HEAD -> master, origin/master, origin/HEAD)
    Version 3
commit 8789f8898667725b823dc4aedda7eb51100bba05
    Version 2
commit 32f20d47638365bb85b052a654e128f608e1ec66
    Version 1
3.2.3 git fetch拉取变更不应用（只读型同步）
bash 复制代码 
]# git clone git@172.25.254.44:/home/git/project.git
]# echo "测试更新测试更新！！！" >>  test_fetch.txt
]# git add test_fetch.txt
]# git commit -m "更新Tag" test_fetch.txt
]# git log
]# git remote -v
]# git push


[root@Git-Client project]# git fetch
[root@Git-Client project]# git log
[root@Git-Client project]# git diff master origin/master
[root@Git-Client project]# git merge
[root@Git-Client project]# git log
commit 6ed3578a0b3c70daf4eda39bd9076b8b5491b99a (HEAD -> master, origin/master, origin/HEAD)
    更新Tag
commit 902b97293a2e7a31ee5236db29d65b9bee4ef76b
    模拟测试
commit a013204442df1b6b28f2a1a01a636efa9406be80
    Version 4
commit 04467435b11c8827103f2068afb01727a2049ab8
    Version 3
commit 8789f8898667725b823dc4aedda7eb51100bba05
    Version 2
commit 32f20d47638365bb85b052a654e128f608e1ec66
    Version 1
3.2.4 git pull与git fetch区别

git fetch 与 git pull 的核心差异体现在数据同步范围 、工作区状态干预 与冲突处理时机三个技术维度。

  1. 底层执行链路与状态影响

    • git fetch 仅执行网络对象下载阶段。它会连接远程仓库，获取本地缺失的 commits、trees、blobs 对象，并更新本地 .git/refs/remotes/origin/ 下的远程跟踪分支指针。该过程严格隔离于当前分支（HEAD）与工作区（Working Tree），不会修改任何本地文件，属于只读型同步。
    • git pull 是 git fetch 与 git merge（默认）或 git rebase（若配置 pull.rebase=true）的原子组合。它在完成对象下载与跟踪分支更新后，立即尝试将远程变更集成至当前检出的本地分支。该操作会直接重写工作区文件、更新暂存区（Index）与 HEAD 指针，若存在同文件同区域的修改差异，将触发合并冲突并阻塞流程。

  2. 命令行工作流示例

    假设远程 origin/main 新增了 3 个提交，本地 main 落后 2 个提交：

    bash 复制代码 
    # 场景A：使用 fetch（安全审查型）
$ git fetch origin
# 仅下载数据，更新 origin/main 指针，本地工作区无变化
$ git log main..origin/main  # 预览远程新增的提交记录
$ git diff main..origin/main # 逐文件比对差异
$ git merge origin/main      # 确认无误后，手动执行合并

# 场景B：使用 pull（自动集成型）
$ git pull origin main
# 等价于 fetch + merge。直接下载并将远程变更合并至当前 main 分支
# 若本地与远程修改重叠，终端将输出 CONFLICT 提示并暂停，需手动解决

  3. 工程实践定位

    • fetch 适用于 CI/CD 预检、多分支交叉验证、本地存在未提交修改（Dirty Tree）或需审查远程代码质量后再决定是否集成的场景。
    • pull 适用于本地工作区干净、团队已约定直连同步策略或追求快速对齐主干的日常开发场景。
      两者并非互斥替代关系，而是"审查缓冲"与"一键同步"的协作分工。合理选择取决于对变更可控性与操作效率的权衡。
  • git fetch 相当于"下载附件，暂不替换原文件"：同事通过邮件把新版合同发给你。你点击"保存附件"到桌面，但继续打开自己电脑里原来的旧版合同继续修改。你可以随时点开桌面上的新版，逐条对比同事改了哪些条款、是否影响你的谈判策略。确认完全没问题后，你再手动把需要的改动复制粘贴到你的正式文件里。这个过程完全不会打乱你当前的进度，即使新版里有冲突条款，你也能从容评估后再处理。
  • git pull 相当于"下载并自动替换合并"：你点击"一键同步更新"，系统不仅把新版下载下来，还立刻打开你正在编辑的合同，把同事改的内容直接覆盖进去。如果你们改的是不同条款，文件就顺利变成最新合集；但如果同事改了"违约责任"条款，而你今天也在改同一条款，系统就会立刻弹窗提示"内容冲突"，强制暂停保存，要求你逐条勾选"保留我的"还是"保留对方的"。这个过程一步到位，但一旦撞车就会中断你的工作流。
3.2.5 git add提交至暂存区

将所有改动的文件（新增和有变动的）放在暂存区，由git进行管理

bash 复制代码 
[root@Git-Client project]# echo 'No.4' >> Version.html
[root@Git-Client project]# cat Version.html
No.1
No.2
No.3
No.4

[root@Git-Client project]# git status

# add提交至暂存区
[root@Git-Client project]# git add Version.html
[root@Git-Client project]# git status

[root@Git-Client project]# git commit -m 'Version 4'

[root@Git-Client project]# git log
commit a013204442df1b6b28f2a1a01a636efa9406be80 (HEAD -> master)
    Version 4
commit 04467435b11c8827103f2068afb01727a2049ab8 (origin/master, origin/HEAD)
    Version 3
commit 8789f8898667725b823dc4aedda7eb51100bba05
    Version 2
commit 32f20d47638365bb85b052a654e128f608e1ec66
    Version 1
    
[root@Git-Client project]# git push

git status 获取仓库当前的状态：

  • Untracked files：有未被跟踪的文件
  • Changes to be committed：有未提交的文件
  • nothing to commit, working tree clean：没有被修改的文件
3.2.6 删除暂存区缓存（工作区文件不受影响）
3.2.6.1 git restore --staged xxx(推荐，频率高)
bash 复制代码 
[root@Git-Client fz]# echo "Docker" > 9.txt
[root@Git-Client fz]# git add 9.txt

[root@Git-Client fz]# echo "DDDD" > 11.txt
[root@Git-Client fz]# git add 11.txt

[root@Git-Client fz]# git status
        new file:   11.txt
        new file:   9.txt

[root@Git-Client fz]# git restore --staged 11.txt
[root@Git-Client fz]# git status
        new file:   9.txt
        11.txt
3.2.6.2 git rm --cached xxx
bash 复制代码 
[root@Git-Client fz]# git add 11.txt
[root@Git-Client fz]# git status
        new file:   11.txt
        new file:   9.txt

[root@Git-Client fz]# git rm --cached 11.txt
[root@Git-Client fz]# git status
        new file:   9.txt
        11.txt
3.2.6.3 区别(跟踪/不跟踪)

模拟测试

bash 复制代码 
# 步骤1：创建一个会被跟踪的文件
echo "test" > track.txt
git add track.txt
git commit -m "add track.txt"  # 关键：让它被跟踪

# 步骤2：修改并暂存
echo "new" >> track.txt
git add track.txt

# 步骤3：用 restore（文件保持跟踪）
git restore --staged track.txt
git status | grep "track.txt"
# 输出：modified: track.txt  （注意：是 modified，不是 untracked）

# 步骤4：重新 add
git add track.txt

# 步骤5：用 rm --cached（文件失去跟踪）
git rm --cached track.txt
git status | grep "track.txt"
# 输出：Untracked files: track.txt  （注意：是 untracked）

自我测试

bash 复制代码 
[root@Git-Client fz]# git add 123.txt
[root@Git-Client fz]# git add 456.txt

[root@Git-Client fz]# git status
        new file:   123.txt
        new file:   456.txt

[root@Git-Client fz]# git commit -m "v1" 123.txt
[root@Git-Client fz]# git status
        new file:   456.txt


[root@Git-Client fz]# echo "000" >> 123.txt
[root@Git-Client fz]# git add 123.txt
[root@Git-Client fz]# git status
        modified:   123.txt
        new file:   456.txt


[root@Git-Client fz]# git restore --staged 123.txt
[root@Git-Client fz]# git status
        new file:   456.txt
        modified:   123.txt


[root@Git-Client fz]# git add 123.txt
[root@Git-Client fz]# git rm --cached 123.txt
[root@Git-Client fz]# git status
        deleted:    123.txt
        new file:   456.txt
        123.txt
3.2.7 git commit提交暂存区内容
bash 复制代码 
HEAD         # 当前提交（最新）
HEAD~1       # 上一次提交（父提交）
HEAD~2       # 上两次提交
HEAD~3       # 上三次提交

# 等价写法
HEAD^        # 等同于 HEAD~1
HEAD^^       # 等同于 HEAD~2

提交当前工作空间的修改内容到本地仓库

bash 复制代码 
[root@Git-Client project]# git add 123.txt

# -m 是本次提交内容的注释/备注
[root@Git-Client project]# git commit -m "测试 commit" 123.txt
[root@Git-Client project]# git log
3.2.8 git reset删除commmit内容
bash 复制代码 
# 环境准备
[git@Git-Server ~]$ mkdir xx.git
[git@Git-Server ~]$ git init --bare xx.git/

[root@Git-Client ~]# git clone git@172.25.254.44:/home/git/xx.git
[root@Git-Client ~]# cd xx/
[root@Git-Client xx]# echo "1111" > x.html
[root@Git-Client xx]# git add x.html
[root@Git-Client xx]# git status
        new file:   x.html
[root@Git-Client xx]# git commit -m "v1" x.html
3.2.8.1 温柔git reset --soft xxx删除commit,保留修改(暂存区)

代码还在，git add 也帮你做好了。

bash 复制代码 
[root@Git-Client xx]# git reset --soft HEAD~1
[root@Git-Client xx]# git status
        modified:   x.html
3.2.8.2 默认git reset --mixed xxx删除commmit,保留修改(工作区)

代码还在，但git add 被取消了。

bash 复制代码 
[root@Git-Client xx]# git reset --mixed  HEAD~1
[root@Git-Client xx]# git status
3.2.8.3 暴力git reset --hard xxx丢弃所有修改(包括历史修改)

干净得像新克隆的一样。

bash 复制代码 
[root@Git-Client xx]# git add x.html
[root@Git-Client xx]# git commit -m "v3" x.html
[root@Git-Client xx]# git status
[root@Git-Client xx]# git reset --hard HEAD~
[root@Git-Client xx]# git log --oneline		# v3->v1
be778b6 (HEAD -> master) v1
3.2.9 git push推送更新

将本地commit的代码更新到远程版本库中

bash 复制代码 
[root@Git-Client project]# echo "NO.555" >> Version.html
[root@Git-Client project]# git add Version.html
[root@Git-Client project]# git commit -m "Version 555" Version.html
[root@Git-Client project]# git remote -v
origin  git@172.25.254.44:/home/git/project.git (fetch)
origin  git@172.25.254.44:/home/git/project.git (push)

# 推送到远程仓库
[root@Git-Client project]# git push



# 进行远程仓库拉取测试，并查看是否成功？
[root@Git-Client ~]# mkdir temp
[root@Git-Client ~]# cd temp/
[root@Git-Client temp]# git clone git@172.25.254.44:/home/git/project.git
[root@Git-Client project]# cat Version.html
No.1
No.2
No.3
No.4
NO.555
3.2.10 git log查看历史日志

查看历史记录，显示从最近到最远的提交日志，以便确定要回退到哪个版本。

  • git log --pretty=oneline 使每条记录显示在同一行。
  • git log --pretty=oneline --abbrev-commit 使每条记录显示在同一行且简写。
bash 复制代码 
[root@Git-Client project]# git log --pretty=oneline
10519ddad7cf0ac438e5c9cb7adf8a106ce21d47 (HEAD -> master, origin/master, origin/HEAD) Version 555
433448a95cddcaf98f391062d9e5d2efc6f74fa4 测试 commit
63e4bcb1c0c930ad3cc5ccba219c645e42cc767e 测试 git rm
6ed3578a0b3c70daf4eda39bd9076b8b5491b99a 更新Tag
902b97293a2e7a31ee5236db29d65b9bee4ef76b 模拟测试
a013204442df1b6b28f2a1a01a636efa9406be80 Version 4
04467435b11c8827103f2068afb01727a2049ab8 Version 3
8789f8898667725b823dc4aedda7eb51100bba05 Version 2
32f20d47638365bb85b052a654e128f608e1ec66 Version 1


[root@Git-Client project]# git log --pretty=oneline  --abbrev-commit
10519dd (HEAD -> master, origin/master, origin/HEAD) Version 555
433448a 测试 commit
63e4bcb 测试 git rm
6ed3578 更新Tag
902b972 模拟测试
a013204 Version 4
0446743 Version 3
8789f88 Version 2
32f20d4 Version 1

4.分支操作

4.1 git的分支是什么？

​ 顾名思义，分支就是从主分支上分离出来进行另外的操作，而又不影响主分支，主分支又可以继续干它的事，最后分支做完事后合并到主分支上而分支的任务完成可以删掉了。使用分支意味着你可以从开发主分支上分离开来，然后在不影响主分支的同时继续工作。创建一个属于自己的分支，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，既安全又不影响别人工作。Git的分支无论创建、切换和删除，无论版本库大小，都很快，只是修改指针。

4.2 git分支管理

准备前期环境

bash 复制代码 
[git@Git-Server ~]$ mkdir fz.git
[git@Git-Server ~]$ git init --bare fz.git/


[root@Git-Client ~]# git clone git@172.25.254.44:/home/git/fz.git
[root@Git-Client ~]# cd fz/

# 如果拉下来的仓库是裸仓库，因此需要第一次commmit之后，才会出现分支
[root@Git-Client fz]# git branch

[root@Git-Client fz]# echo "hello" > README.md
[root@Git-Client fz]# git add README.md
[root@Git-Client fz]# git commit -m "v1" README.md

[root@Git-Client fz]# git branch
* master

# 推送至远程仓库，远程裸仓库里也会出现 master 分支
[root@Git-Client fz]# git push -u origin master
4.2.1 git branch查看分支
bash 复制代码 
# * 代表此时处于那个分支
[root@Git-Client fz]# git branch
* master
4.2.2 git branch <name>创建分支
bash 复制代码 
[root@Git-Client fz]# git branch nginx
[root@Git-Client fz]# git branch
* master
  nginx
4.2.3 git checkout <name>切换分支
bash 复制代码 
[root@Git-Client fz]# git checkout nginx
[root@Git-Client fz]# git branch
  master
* nginx
4.2.4 git checkout -b <name> 创建并切换到分支
bash 复制代码 
[root@Git-Client fz]# git checkout -b tomcat
[root@Git-Client fz]# git branch
  master
  nginx
* tomcat
4.2.5 git branch -m <old> <new>重命名分支
bash 复制代码 
[root@Git-Client fz]# git branch -m tomcat nginx-2
[root@Git-Client fz]# git branch
  master
  nginx
* nginx-2
4.2.6 git merge <name>合并分支(前提：master分支操作)
bash 复制代码 
# nginx分支存在1.tml
[root@Git-Client fz]# git branch
  master
* nginx
  nginx-2
[root@Git-Client fz]# ls
1.html  README.md
[root@Git-Client fz]# cat 1.html
<<nginx>>


# 切换到master分支，只有README.md
[root@Git-Client fz]# git checkout master
[root@Git-Client fz]# git branch
* master
  nginx
  nginx-2
[root@Git-Client fz]# ls
README.md

# 合并nginx分支，再次查看发现，1.html已存在
[root@Git-Client fz]# git merge nginx
[root@Git-Client fz]# ls
1.html  README.md
[root@Git-Client fz]# cat 1.html
<<nginx>>
4.2.7 git -d/D <name>删除分支(安全/强制)
bash 复制代码 
# 安全删除：只能删除已合并的分支
git branch -d <name>

# 强制删除：删除任何分支（包括未合并的分支）
git branch -D <name>
bash 复制代码 
[root@Git-Client fz]# git branch
* master
  nginx
  nginx-2
  
# nginx分支已经被merege合并了，因此-d可以直接删除
[root@Git-Client fz]# git branch -d nginx


# 这里删除不了说明nginx-2为未合并
# 如果很意外的删除了，那是说明这个分支你没有做任何的动作，只是创建下来了
[root@Git-Client fz]# git branch -d nginx-2
error: The branch 'nginx-2' is not fully merged.
If you are sure you want to delete it, run 'git branch -D nginx-2'.


# 因此需要-D来强制删除
[root@Git-Client fz]# git branch -D nginx-2
相关推荐
数据雕塑家2 小时前
Linux磁盘性能测试完全指南：使用FIO深入评估存储系统
linux·运维·服务器
csdn_aspnet2 小时前
告别重复造轮子：Codex写脚本，运维/DevOps场景下，用Codex批量生成Shell/Python自动化脚本
运维·python·ai·自动化·devops·codex·辅助编程
.柒宇.2 小时前
CICD基础概述
ci/cd·运维开发·devops
木心术12 小时前
DevOps全流程实践：从CI/CD到自动化测试的最佳实践
运维·ci/cd·devops
一直会游泳的小猫2 小时前
Homebrew - macOS 与 Linux 的包管理器
linux·运维·macos·brew·包管理工具
开开心心_Every2 小时前
文件强制删除工具,单文件拖入解锁删除简单
运维·edge·pdf·计算机外设·逻辑回归·散列表·启发式算法
halazi1002 小时前
WSL 安装与 Ubuntu 24.04 配置使用指南
linux·运维·ubuntu·wsl
MDIOT旗舰2 小时前
4G低功耗边缘计算网关：让智能抄表与远程运维从未如此简单
运维·人工智能·边缘计算·modbus·红外抄表·plc智能网关
2302_803132252 小时前
ensp中关于交换机S3700不被识别的错误列举以及vlan 绑定acl后无法删除问题
运维·服务器·网络
热门推荐
012026年4月技术前沿：AI大模型爆发、智能体革命与量子安全新纪元02GitHub 镜像站点032026年4月AI大事件深度解读：大模型竞争进入“深水区“04近期有什么ai的新消息，新动态？ 2026.4月052026 年 AI 编程助手全面对比评测：Cursor vs Copilot vs Claude Code vs GitHub Copilot Free06AI Weekly | 2026年4月第二周 · GitHub热门项目与AI发展趋势深度解析07CC-Switch & Claude 基于 Linux 服务器安装使用指南08从限购到畅通：GLM-5.1 Coding Plan接入攻略09Claude Code Windows 兼容性问题：指定版本 2.1.112 可解决10UBUNTU Claude Code 报错 claude native binary not installed