---

---

正文：

本篇文章目标：

• 技术目标：

• : 掌握 Git 企业级应⽤，深刻理解Git操作过程与操作原理，理解⼯作区，暂存区，版本库的含义
• 掌握 Git 版本管理，⾃由进⾏版本回退、撤销、修改等Git操作⽅式与背后操作原理
• 掌握 Git 分⽀管理，从分⽀创建，切换，合并，删除的整个⽣命周期，灵活进⾏各种场景下的分⽀管理，学习常⻅分⽀管理策略
• 掌握 Git 远程仓库与本地仓库，结合版本管理与分⽀管理，做到基于分⽀级的个⼈级开发

不同公司的DevOps 平台可能不一样 其不同环境下的分支模型也可能不一样 后续文章只是以Gitee 企业级开发为例

Git 初识

提出问题

不知道你⼯作或学习时，有没有遇到这样的情况：我们在编写各种⽂档时，为了防⽌⽂档丢失，更改失误，失误后能恢复到原来的版本，不得不复制出⼀个副本，⽐如：
“报告-v1”
“报告-v2”
“报告-v3”
“报告-确定版”
“报告-最终版”
“报告-究极进化版”

每个版本有各⾃的内容，但最终会只有⼀份报告需要被我们使⽤
但在此之前的⼯作都需要这些不同版本的报告，于是每次都是复制粘贴副本，产出的⽂件就越来越
多，⽂件多不是问题，问题是：随着版本数量的不断增多，你还记得这些版本各⾃都是修改了什么吗？
⽂档如此，我们写的项⽬代码，也是存在这个问题的！！

引出Git–分布式版本控制器

为了能够更⽅便我们管理这些不同版本的⽂件，便有了版本控制器。所谓的版本控制器，就是能让你了解到⼀个⽂件的历史，以及它的发展过程的系统。***通******俗的讲就是⼀个可以记录⼯程的每⼀次改动和版本迭代的⼀个管理系统，同时也⽅便多⼈协同作业***。⽬前最主流的版本控制器就是 Git 。Git 可以控制电脑上所有格式的⽂件，例如 doc、excel、dwg、dgn、rvt等等。对于我们开发⼈员来说，***Git 最重要的就是可以帮助我们管理软件开发项⽬中的源代码⽂件！***

注意事项：
还需要再明确⼀点，所有的版本控制系统，Git 也不例外，其实只能跟踪⽂本⽂件的改动，⽐如 TXT ⽂件，⽹⻚，所有的程序代码等等。版本控制系统可以告诉你每次的改动，⽐如在第5⾏加了⼀个单词“Linux”，在第8⾏删了⼀个单词 “Windows”。
⽽图⽚、视频这些⼆进制⽂件，虽然也能由版本控制系统管理，但没法跟踪⽂件的变化，只能把⼆进制⽂件每次改动串起来，也就是只知道图⽚从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。

Git 安装

Git 是开放源代码的代码托管⼯具，最早是在Linux下开发的。开始也只能应⽤于Linux平台，后⾯慢慢的被移植到windows下，现在，Git可以在Linux、Unix、Mac和Windows这⼏⼤平台上正常运⾏了。

Linux-centos

如果你的的平台是centos，安装git相当简单，以我的centos7.6为例：
⾸先，你可以试着输⼊Git，看看系统有没有安装Git：

$ git
-bash : git: command not found

出现像上⾯的结果，Linux会友好地告诉你Git没有安装。

安装Git:

sudo yum -y install git

查看 git 安装的版本：

$ git --version

Linux-ubuntu

如果你的的平台是ubuntu，安装git相当简单，以我的ubuntu20.04为例：
⾸先，你可以试着输⼊git，看看系统有没有安装Git：

$ git
Command 'git' not found, but can be installed with:
sudo apt install git

出现像上⾯的结果，Linux会友好地告诉你Git没有安装，还会告诉你如何安装Git。

安装Git:

$ sudo apt-get install git -y

查看 git 安装的版本：

$ git --version

以下所有操作均在Linux-Centos 平台下的实现

Windows

参考链接：Git-Windows

Git 基本操作

创建 Git 本地仓库

要提前说的是，仓库是进⾏版本控制的⼀个⽂件⽬录。我们要想对⽂件进⾏版本控制，就必须先创建⼀个仓库出来。
创建⼀个 Git 本地仓库对应的命令为 git init ，注意命令要在⽂件⽬录下执⾏，例如

[tmp@VM-24-16-centos ~]$ mkdir gitcode
[tmp@VM-24-16-centos ~]$ ll
total 4
drwxrwxr-x 2 tmp tmp 4096 Oct 12 16:05 gitcode
[tmp@VM-24-16-centos ~]$ cd gitcode
[tmp@VM-24-16-centos gitcode]$ git init
Initialized empty Git repository in /home/tmp/gitcode/.git/
[tmp@VM-24-16-centos gitcode]$ ls -a
.  ..  .git

我们发现，当前⽬录下多了⼀个 .git 的隐藏⽂件， .git ⽬录是 Git 来跟踪管理仓库的，***不要⼿动修改这个⽬录⾥⾯的⽂件，不然改乱了，就把 Git 仓库给破坏了***。
其中包含 Git 仓库的诸多细节，有兴趣的同学可以进⼊看看

[tmp@VM-24-16-centos gitcode]$ tree .git/
.git/
|-- branches
|-- config
|-- description
|-- HEAD
|-- hooks
|   |-- applypatch-msg.sample
|   |-- commit-msg.sample
|   |-- post-update.sample
|   |-- pre-applypatch.sample
|   |-- pre-commit.sample
|   |-- prepare-commit-msg.sample
|   |-- pre-push.sample
|   |-- pre-rebase.sample
|   `-- update.sample
|-- info
|   `-- exclude
|-- objects
|   |-- info
|   `-- pack
`-- refs
    |-- heads
    `-- tags

9 directories, 13 files

配置 Git

当安装 Git 后⾸先要做的事情是设置你的 ⽤⼾名称 和 e-mail 地址，这是⾮常重要的。配置命令为：

git config [--global] user.name "Your Name" 
git config [--global] user.email "email@example.com" 
# 把 Your Name 改成你的昵称
# 把 email@example.com 改成邮箱的格式，只要格式正确即可。

参考：

[tmp@VM-24-16-centos gitcode]$ git config --global user.name "twg"
[tmp@VM-24-16-centos gitcode]$ git config --global user.email "2248706487@qq.com"
[tmp@VM-24-16-centos gitcode]$ git config -l
user.name=twg
user.email=2248706487@qq.com
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true

其中 --global 是⼀个可选项。如果使⽤了该选项，表⽰这台机器当前账户上（普通用户）所有的 Git 仓库都会使⽤这个
配置。如果你希望在不同仓库中使⽤不同的 name 或 e-mail ，可以不要 --global 选项，但要注意的是，***执⾏命令时必须要在仓库⾥***。

查看配置命令为：

git config -l

删除对应的配置命令为：

git config --global  --unset user.name 
git config --global  --unset user.email

参考：

[tmp@VM-24-16-centos gitcode]$ git config -l
user.name=twg
user.email=2248706487@qq.com
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
[tmp@VM-24-16-centos gitcode]$ git config --global --unset user.name
[tmp@VM-24-16-centos gitcode]$ git config --global --unset user.email
[tmp@VM-24-16-centos gitcode]$ git config -l
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true

认识⼯作区、暂存区、版本库

重点理解这三个区

• ⼯作区：是在电脑上你要写代码或⽂件的⽬录
• 暂存区：英⽂叫 stage 或 index。⼀般存放在 .git ⽬录下的 index ⽂件（.git/index）中，我们把暂存区有时也叫作索引（index）
• 版本库：⼜名仓库，英⽂名 repository 。⼯作区有⼀个隐藏⽬录 .git ，它不算⼯作区，⽽是 Git 的版本库。这个版本库⾥⾯的所有⽂件都可以被 Git 管理起来，每个⽂件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。

这里可以查看下.git 的构成

下⾯这个图展⽰了⼯作区、暂存区和版本库之间的关系

• 图中左侧为⼯作区，右侧为版本库。Git 的版本库⾥存了很多东西，其中最重要的就是暂存区
• 在创建 Git 版本库时，Git 会为我们⾃动创建⼀个唯⼀的 master 分⽀，以及指向 master 的⼀个指针叫 HEAD。（分⽀和HEAD的概念后⾯再说）(本地目录git init 后创建.git版本库)
• 当对⼯作区修改（或新增）的⽂件执⾏ git add 命令时，暂存区⽬录树的⽂件索引会被更新。
• 当执⾏提交操作 git commit 时，master 分⽀会做相应的更新，可以简单理解为暂存区的⽬录树才会被真正写到版本库中。

• 注意add commit后 push前 都是对本地git仓库的操作 对远程仓库不影响
• 由上述描述我们便能得知：通过新建或粘贴进⽬录的⽂件，并不能称之为向仓库中新增⽂件，⽽只是在⼯作区新增了⽂件。必须要通过使⽤ git add 和 git commit 命令才能将⽂件添加到仓库中进⾏管理！！！

添加⽂件

场景一：
在包含 .git 的⽬录下新建⼀个 ReadMe ⽂件，我们可以使⽤ git add 命令可以将⽂件添加到暂存区：

• 添加⼀个或多个⽂件到暂存区： git add [file1] [file2] …
• 添加指定⽬录到暂存区，包括⼦⽬录： git add [dir]
• 添加当前⽬录下的所有⽂件改动到暂存区： git add .

再使⽤ git commit 命令将暂存区内容添加到本地仓库中：

• 提交暂存区全部内容到本地仓库中: git commit -m "message“

• 提交暂存区的指定⽂件到仓库区： git commit [file1] [file2] … -m “message”

注意 git commit 后⾯的 -m 选项，要跟上描述本次提交的 message，由⽤⼾⾃⼰完成，这部分内容绝对不能省略，并要好好描述，是⽤来记录你的提交细节，是给我们⼈看的。

[tmp@VM-24-16-centos gitcode]$ vim ReadMe
[tmp@VM-24-16-centos gitcode]$ cat ReadMe 
hello bit
hello bit
[tmp@VM-24-16-centos gitcode]$ git add .
[tmp@VM-24-16-centos gitcode]$ git commit -m "commit my first file"
[master (root-commit) 33f3016] commit my first file
 1 file changed, 2 insertions(+)
 create mode 100644 ReadMe

git commit 命令执⾏成功后会告诉我们，1个⽂件被改动（就是我们新添加的ReadMe⽂件），插⼊了两⾏内容（ReadMe有两⾏内容）。

我们还可以多次 add 不同的⽂件，⽽只 commit ⼀次便可以提交所有⽂件，是因为需要提交的⽂件是通通被 add 到暂存区中，然后⼀次性 commit 暂存区的所有修改。如：

[tmp@VM-24-16-centos gitcode]$ touch file1
[tmp@VM-24-16-centos gitcode]$ touch file2
[tmp@VM-24-16-centos gitcode]$ touch file3
[tmp@VM-24-16-centos gitcode]$ git add file1
[tmp@VM-24-16-centos gitcode]$ git add file2
[tmp@VM-24-16-centos gitcode]$ git add fil3
fatal: pathspec 'fil3' did not match any files
[tmp@VM-24-16-centos gitcode]$ git add file3
[tmp@VM-24-16-centos gitcode]$ git commit -m "add 3 files"
[master 3020d2a] add 3 files
 3 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file1
 create mode 100644 file2
 create mode 100644 file3

截⾄⽬前为⽌，我们已经更够将代码直接提交⾄***本地仓库***了。我们可以使⽤ git log 命令，来查看下历史提交记录

[tmp@VM-24-16-centos gitcode]$ git log
commit 3020d2aaf9f77218126773d2ffd8ce410366caae
Author: twg <2248706487@qq.com>
Date:   Sun Oct 12 16:38:14 2025 +0800

    add 3 files

commit 33f3016613a22e70f5cf7ea845ffdcf12c587e6d
Author: twg <2248706487@qq.com>
Date:   Sun Oct 12 16:35:16 2025 +0800

    commit my first file

该命令显⽰从最近到最远的提交⽇志，并且可以看到我们 commit 时的⽇志消息
如果嫌输出信息太多，看得眼花缭乱的，可以试试加上 --pretty=oneline 参数：

[tmp@VM-24-16-centos gitcode]$ git log --pretty=oneline
3020d2aaf9f77218126773d2ffd8ce410366caae add 3 files
33f3016613a22e70f5cf7ea845ffdcf12c587e6d commit my first file

需要说明的是，我们看到的⼀⼤串类似 3020d2…66caae 的是每次提交的 commit id （版本号），Git 的 commit id 不是1，2，3……递增的数字，⽽是⼀个 SHA1 计算出来的⼀个⾮常⼤的数字，⽤⼗六进制表⽰（你看到的 commit id 和我的肯定不⼀样，以
你自己的为准）

查看 .git ⽂件

先来看看我们的 .git 的⽬录结构:

[tmp@VM-24-16-centos gitcode]$ tree .git
.git
|-- branches
|-- COMMIT_EDITMSG
|-- config
|-- description
|-- HEAD
|-- hooks
|   |-- applypatch-msg.sample
|   |-- commit-msg.sample
|   |-- post-update.sample
|   |-- pre-applypatch.sample
|   |-- pre-commit.sample
|   |-- prepare-commit-msg.sample
|   |-- pre-push.sample
|   |-- pre-rebase.sample
|   `-- update.sample
|-- index
|-- info
|   `-- exclude
|-- logs
|   |-- HEAD
|   `-- refs
|       `-- heads
|           `-- master
|-- objects
|   |-- 30
|   |   `-- 20d2aaf9f77218126773d2ffd8ce410366caae
|   |-- 33
|   |   `-- f3016613a22e70f5cf7ea845ffdcf12c587e6d
|   |-- 83
|   |   `-- 0a8c9feefbdc098bbae2cdc25e5034ce1920d7
|   |-- 8f
|   |   `-- add50161b6fafa53ce7e79d278dc490240c946
|   |-- 9c
|   |   `-- 9e1f0f6bff3015df71a0963004476f5e6cfd54
|   |-- e6
|   |   `-- 9de29bb2d1d6434b8b29ae775ad8c2e48c5391
|   |-- info
|   `-- pack
`-- refs
    |-- heads
    |   `-- master
    `-- tags

18 directories, 24 files

1. index 就是我们的暂存区，所有工作区add的文件或者目录均在此处
2. HEAD 就是我们的默认指向 master 分⽀的指针.

后面如果有分支的话HEAD 是指向某一分支的指针

打印的3020d2aaf9f77218126773d2ffd8ce410366caae是什么东西呢？保存的就是当前最新的 commit id 。

3. objects 为 Git 的对象库，⾥⾯包含了创建的各种版本库对象及内容。当执⾏ git add 命令
   时，暂存区的⽬录树被更新，同时⼯作区修改（或新增）的⽂件内容被写⼊到对象库中的⼀个新的对象中，就位于 “.git/objects” ⽬录下，让我们来看看这些对象有何⽤处：

查找 object 时要将 commit id 分成2部分，其前2位是⽂件夹名称，后38位是⽂件名称。
找到这个⽂件之后，⼀般不能直接看到⾥⾯是什么，该类⽂件是经过 sha （安全哈希算法）加密过的
⽂件，好在我们可以使⽤ git cat-file 命令来查看版本库对象的内容：

tmp@VM-24-16-centos gitcode$ git cat-file -p
3020d2aaf9f77218126773d2ffd8ce410366caae
tree 830a8c9feefbdc098bbae2cdc25e5034ce1920d7
parent 33f3016613a22e70f5cf7ea845ffdcf12c587e6d
author twg <2248706487@qq.com> 1683343652 +0800
committer twg <2248706487@qq.com> 1683343652 +0800
add 3 files
# 这就是我们最近⼀次的提交！

总结⼀下，在本地的 git 仓库中，有⼏个⽂件或者⽬录很特殊

• index: 暂存区， git add 后会更新该内容。
• HEAD: 默认指向 master 分⽀的⼀个指针。
• refs/heads/master: ⽂件⾥保存当前 master 分⽀的最新 commit id
• objects: 包含了创建的各种版本库对象及内容，可以简单理解为放了 git 维护的所有修改

后⾯再学习过程中，最好能将常⻅的 git 操作与 .git ⽬录当中的结构内容变化对应起来，这样有利于我们理解git 细节流程。我们后⾯还会学习什么分⽀，标签什么的,希望大家也可以自己对应着研究

场景二：

学习到这⾥，我们已经清楚了如何向仓库中添加⽂件，并且对于⼯作区、暂存区、版本库也有了⼀定的认识。那么我们再展⽰⼀种添加⽂件的场景，能加深对⼯作区、暂存区、版本库的理解，⽰例如
下：

[tmp@VM-24-16-centos gitcode]$ ll
total 4
-rw-rw-r-- 1 tmp tmp  0 Oct 12 16:37 file1
-rw-rw-r-- 1 tmp tmp  0 Oct 12 16:37 file2
-rw-rw-r-- 1 tmp tmp  0 Oct 12 16:37 file3
-rw-rw-r-- 1 tmp tmp 20 Oct 12 16:34 ReadMe
[tmp@VM-24-16-centos gitcode]$ touch file4
[tmp@VM-24-16-centos gitcode]$ git add file4
[tmp@VM-24-16-centos gitcode]$ touch file5
[tmp@VM-24-16-centos gitcode]$ git commit -m "new commit"
[master 9970029] new commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file4

提交后发现打印了 1 file changed, 0 insertions(+), 0 deletions(-) ，意思是只有⼀个⽂件改变了，这时我们提出了疑问，不是新增了两个⽂件吗？
再来回忆下， git add 是将⽂件添加到暂存区， git commit 是将暂存区的内容添加到本地仓库中。由于我们并没有使⽤ git add file5 ，file5 就不在暂存区中维护，所以我们 commit 的时候
其实只是把已经在暂存区的 file4 提交了，⽽遗漏了⼯作区的 file5。如何提交 file5 呢？很简单，再次add , commit 即可

修改⽂件

Git ⽐其他版本控制系统设计得优秀，因为 Git 跟踪并管理的是修改，⽽⾮⽂件。
什么是修改？⽐如你新增了⼀⾏，这就是⼀个修改，删除了⼀⾏，也是⼀个修改，更改了某些字符，也是⼀个修改，删了⼀些⼜加了⼀些，也是⼀个修改，甚⾄创建⼀个新⽂件，也算⼀个修改。
让我们将 ReadMe ⽂件进⾏⼀次修改：

![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/6575222395c1401196100313f81d6965.png

[tmp@VM-24-16-centos gitcode]$ ll
total 4
-rw-rw-r-- 1 tmp tmp  0 Oct 12 16:37 file1
-rw-rw-r-- 1 tmp tmp  0 Oct 12 16:37 file2
-rw-rw-r-- 1 tmp tmp  0 Oct 12 16:37 file3
-rw-rw-r-- 1 tmp tmp  0 Oct 12 17:09 file4
-rw-rw-r-- 1 tmp tmp  0 Oct 12 17:09 file5
-rw-rw-r-- 1 tmp tmp 20 Oct 12 16:34 ReadMe
[tmp@VM-24-16-centos gitcode]$ vim ReadMe 
[tmp@VM-24-16-centos gitcode]$ cat ReadMe 
hello bit
hello bit
xxx code

此时，仓库中的 ReadMe 和我们⼯作区的 ReadMe 是不同的，如何查看当前仓库的状态呢？ git status 命令⽤于查看在你上次提交之后是否有对⽂件进⾏再次修改。

[tmp@VM-24-16-centos gitcode]$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   ReadMe
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	file5
no changes added to commit (use "git add" and/or "git commit -a")

上⾯的结果告诉我们，ReadMe 被修改过了，但还没有完成添加与提交
⽬前，我们只知道⽂件被修改了，如果能知道具体哪些地⽅被修改了，就更好了。有人会说，我刚改的我知道呀！可是，你还记得你三天前写了什么代码吗？或者没写

[tmp@VM-24-16-centos gitcode]$ git diff ReadMe
diff --git a/ReadMe b/ReadMe
index 9c9e1f0..c23debd 100644
--- a/ReadMe
+++ b/ReadMe
@@ -1,2 +1,3 @@
 hello bit
 hello bit
+xxx code

git diff [file] 命令⽤来显⽰暂存区和⼯作区⽂件的差异，显⽰的格式正是Unix通⽤的diff格式。也可以使⽤ git diff HEAD – [file] 命令来查看版本库和⼯作区⽂件的区别。
知道了对 ReadMe 做了什么修改后，再把它提交到本地仓库就放⼼多了

[tmp@VM-24-16-centos gitcode]$ git add ReadMe
[tmp@VM-24-16-centos gitcode]$ git commit -m "md ReadMe"
[master 5befc7f] md ReadMe
 1 file changed, 1 insertion(+)

版本回退

之前我们也提到过，Git 能够管理⽂件的历史版本，这也是版本控制器重要的能⼒。如果有⼀天你发现之前的⼯作出现了很⼤的问题，需要在某个特定的历史版本重新开始，这个时候，就需要版本回退的功能了。

执⾏ git reset 命令⽤于回退版本，可以指定退回某⼀次提交的版本。要解释⼀下“回退”本质是要将版本库中的内容进⾏回退，⼯作区或暂存区是否回退由命令参数决定

git reset 命令语法格式为： git reset [–soft | --mixed | --hard] [HEAD]

• –mixed 为默认选项，使⽤时可以不⽤带该参数。该参数将暂存区和版本库的内容退回为指定提交版本内容，⼯作区⽂件保持不变。
• –soft 参数对于⼯作区和暂存区的内容都不变，只是将版本库回退到某个指定版本。
• –hard 参数将暂存区,版本库与⼯作区都退回到指定版本。切记⼯作区有未提交的代码时不要⽤这个命令，因为⼯作区会回滚，你没有提交的代码就再也找不回了，所以使⽤该参数前⼀定***要慎重***
• HEAD 说明:

• 可直接写成 commit id，表⽰指定退回的版本
• HEAD 表示当前版本
• HEAD^ 表示上一版本
• HEAD^^ 表示上上个版本
• 以此类推

注意：这里所说的版本指的是 commit提交过的版本

为了便于表述，⽅便测试回退功能，我们先做⼀些准备⼯作：更新3个版本的 ReadMe，并分别进⾏3次提交，如下所⽰

现在，如果我们在提交完 version3 后， 发现 version 3 编写错误，想回退到 version2，重新基于version 2 开始编写。由于我们在这⾥希望的是将⼯作区的内容也回退到 version 2 版本，所以需
要⽤到 --hard 参数，⽰例如下：

我们惊奇的发现，此时 ReadMe ⽂件的内容，已经回退到 version2 了！，当前，我们再次⽤ git log 查看⼀下提交⽇志，发现HEAD也指向了version2，如下所示:

到这⾥⼀般回退功能就演⽰完了，但现在如果我后悔了，想再回到 version 3 怎么办？我们可以继续使⽤ git reset 命令，回退到 version 3 版本，但我们必须要拿到 version 3 的 commit
id 去指定回退的版本

但我们看到了 git log 并不能打印出 version 3 的 commit id ，运⽓好的话我们可以从终端上去找找之前的记录，运⽓不好的话 commit id 已经被我们搞丢了=。=
Git 还提供了⼀个 git reflog 命令能补救⼀下，该命令⽤来记录本地的每⼀次命令

可往往是理想很丰满，现实很⻣感。在实际开发中，由于⻓时间的开发了，导致 commit id 早就找不到了，可突然某⼀天，我⼜想回退到 version3，那该如何操作呢？貌似现在不可能了。。。

值得说的是，Git 的版本回退速度⾮常快，因为 Git 在内部有个指向当前分⽀（此处是master）的HEAD 指针， refs/heads/master ⽂件⾥保存当前 master 分⽀的最新 commit id 。当我们在回退版本的时候，Git 仅仅是给 refs/heads/master 中存储⼀个特定的version，可以简单理解
成如下⽰意图：

撤销修改

如果我们在我们的⼯作区写了很⻓时间代码，越写越写不下去，觉得⾃⼰写的实在是垃圾，想恢复到上⼀个版本。

情况⼀：对于⼯作区的代码，还没有 add

你当然可以直接删掉你⽬前在⼯作区新增的代码，像这样：

⾟亏我们⼯作效率不⾼，才写了⼀⾏代码就发现不⾏了，要是你写了3天，⼀直都没有提交，该怎么删掉呢？你⾃⼰都忘了⾃⼰新增过哪些，有同学说，我可以 git diff xxx ⼀下，看看差别在删啊，那你肯定⼜要花3天时间删代码了，并且很⼤的概率还会改出bug。⼀周过去了，你怎么向你的⽼板交代呢？

Git 其实还为我们提供了更好的⽅式，我们可以使⽤ git checkout – [file] 命令让⼯作区的⽂件回到最近⼀次 add 或 commit 时的状态。 要注意 git checkout -- [file] 命令中的-- 很重要，切记不要省略，⼀旦省略，该命令就变为其他意思了，后⾯我们再说。⽰例如下：

[tmp@VM-24-16-centos gitcode]$ vim ReadMe 
[tmp@VM-24-16-centos gitcode]$ cat ReadMe 
hello bit
hello bit
xxx code
version1
version2
nihao
version3
[tmp@VM-24-16-centos gitcode]$ git checkout -- ReadMe
[tmp@VM-24-16-centos gitcode]$ cat ReadMe 
hello bit
hello bit
xxx code
version1
version2
version3

情况⼆：已经 add ，但没有 commit

add 后还是保存到了暂存区呢？怎么撤销呢？

[tmp@VM-24-16-centos gitcode]$ vim ReadMe 
[tmp@VM-24-16-centos gitcode]$ cat ReadMe 
hello bit
hello bit
xxx code
version1
version2
version3
This piece of code is like shit *新增代码
[tmp@VM-24-16-centos gitcode]$ git add .

让我们来回忆⼀下学过的 git reset 回退命令，该命令如果使⽤ --mixed 参数，可以将暂存区的内容退回为指定的版本内容，但⼯作区⽂件保持不变。那我们就可以回退下暂存区的内容了！！！
⽰例如下：

[tmp@VM-24-16-centos gitcode]$ git reset --mixed 
Unstaged changes after reset:
M	ReadMe
[tmp@VM-24-16-centos gitcode]$ git checkout -- ReadMe
[tmp@VM-24-16-centos gitcode]$ cat ReadMe 
hello bit
hello bit
xxx code
version1
version2
version3

情况三：已经 add ，并且也 commit 了

不要担⼼，我们可以 git reset --hard HEAD^ 回退到上⼀个版本！不过，这是有条件的，就是你还没有把⾃⼰的本地版本库推送到远程。还记得Git是分布式版本控制系统吗？我们后⾯会讲到远程
版本库，⼀旦你推送到远程版本库，你就真的惨了……

因为远程版本库一般都是稳定有效的

[tmp@VM-24-16-centos gitcode]$ vim ReadMe 
[tmp@VM-24-16-centos gitcode]$ git add .
[tmp@VM-24-16-centos gitcode]$ git commit -m "md ReadMe"
[master 64743f3] md ReadMe
 1 file changed, 1 insertion(+)
[tmp@VM-24-16-centos gitcode]$ cat ReadMe 
hello bit
hello bit
xxx code
version1
version2
version3
This piece of code is like shit #新增代码
[tmp@VM-24-16-centos gitcode]$ git reset --hard HEAD^
HEAD is now at b02878d version3
[tmp@VM-24-16-centos gitcode]$ cat ReadMe 
hello bit
hello bit
xxx code
version1
version2
version3

删除⽂件

在 Git 中，删除也是⼀个修改操作，我们实战⼀下, 如果要删除 file5 ⽂件，怎么搞呢？如果你这样做了:

tmp@VM-24-16-centos gitcode]$ ls 
file1  file2  file3  file4  file5  ReadMe
[tmp@VM-24-16-centos gitcode]$ rm file5

但这样直接删除是没有⽤的，反⽽徒增烦恼， git status 命令会⽴刻告诉你哪些⽂件被删除了

[tmp@VM-24-16-centos gitcode]$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	deleted:    file5
#
no changes added to commit (use "git add" and/or "git commit -a")

此时，⼯作区和版本库就不⼀致了，要删⽂件，⽬前除了要删⼯作区的⽂件，还要清除版本库的⽂件。
⼀般⾛到这⾥，有两种可能

• 确实要从版本库中删除该⽂件
• 不⼩⼼删错了

对第⼆种情况，很明显误删，需要使⽤ git 来进⾏恢复，很简单,我们刚学过（删除也是修改）:

tmp@VM-24-16-centos gitcode]$ git checkout -- file5
[tmp@VM-24-16-centos gitcode]$ ls
file1  file2  file3  file4  file5  ReadMe

对于第⼀种情况，很明显是没有删完，我们只删除了⼯作区的⽂件。这时就需要使⽤ git rm 将⽂件从暂存区和⼯作区中删除，并且 commit ：

[tmp@VM-24-16-centos gitcode]$ git rm file5
rm 'file5'
[tmp@VM-24-16-centos gitcode]$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	deleted:    file5
#
[tmp@VM-24-16-centos gitcode]$ git commit -m "delete file5"
[master e78a59d] delete file5
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 file5

现在文件就从版本库中删除了

分⽀管理

理解分支

本章开始介绍 Git 的杀⼿级功能之⼀（注意是之⼀，也就是后⾯还有之⼆，之三……）：分⽀。分⽀就是科幻电影⾥⾯的平⾏宇宙，当你正在电脑前努⼒学习 C++ 的时候，另⼀个你正在另⼀个平⾏宇宙⾥努⼒学习 JAVA。
如果两个平⾏宇宙互不⼲扰，那对现在的你也没啥影响。不过，在某个时间点，两个平⾏宇宙合并了，结果，你既学会了 C++ ⼜学会了 JAVA！

在版本回退⾥，你已经知道，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是⼀个分⽀。截⽌到⽬前，只有⼀条时间线(master)，在Git⾥，这个分⽀叫主分⽀，即 master 分⽀。

再来理解⼀下HEAD，HEAD 严格来说不是指向提交，⽽是指向master，master才是指向提交的，所以，HEAD 指向的就是当前分⽀。

每次提交，master分⽀都会向前移动⼀步，这样，随着你不断提交，master分⽀的线也越来越⻓,⽽HEAD只要⼀直指向master分⽀即可指向当前分⽀
通过查看当前的版本库，我们也能清晰的理出思路:

[tmp@VM-24-16-centos gitcode]$ cat .git/HEAD
ref: refs/heads/master
[tmp@VM-24-16-centos gitcode]$ cat .git/refs/heads/master 
e78a59dbefc4e607f96778588d9ebb8c6ab2ec3c

创建分⽀

Git ⽀持我们查看或创建其他分⽀，在这⾥我们来创建第⼀个⾃⼰的分⽀ dev ，对应的命令为

[tmp@VM-24-16-centos gitcode]$ git branch dev
[tmp@VM-24-16-centos gitcode]$ git branch
  dev
* master

当我们创建新的分⽀后，Git 新建了⼀个指针叫 dev， * 表⽰当前 HEAD 指向的分⽀是 master 分⽀。另外，可以通过⽬录结构发现，新的 dev 分⽀：

[tmp@VM-24-16-centos gitcode]$ git branch
  dev
* master
[tmp@VM-24-16-centos gitcode]$ cat .git/refs/heads/*
e78a59dbefc4e607f96778588d9ebb8c6ab2ec3c
e78a59dbefc4e607f96778588d9ebb8c6ab2ec3c

发现⽬前 dev 和 master 指向同⼀个修改。并且也可以验证下 HEAD ⽬前是指向 master 的。

[tmp@VM-24-16-centos gitcode]$ cat .git/HEAD
ref: refs/heads/master

一张图总结：

切换分⽀

那如何切换到 dev 分⽀下进⾏开发呢？使⽤ git checkout 命令即可完成切换，⽰例如下：

[tmp@VM-24-16-centos gitcode]$ git checkout dev
Switched to branch 'dev'
[tmp@VM-24-16-centos gitcode]$ git branch
* dev
  master

回答了 之前撤销命令场景一 为什么checkout 后面一定要跟 - -

我们发现 HEAD 已经指向了 dev，就表⽰我们已经成功的切换到了 dev 上！
接下来，在 dev 分⽀下修改 ReadMe ⽂件，新增⼀⾏内容，并进⾏⼀次提交操作：

[tmp@VM-24-16-centos gitcode]$ vim ReadMe 
[tmp@VM-24-16-centos gitcode]$ cat ReadMe 
hello bit
hello bit
xxx code
version1
version2
version3
write aaa on new branch
[tmp@VM-24-16-centos gitcode]$ git add .
[tmp@VM-24-16-centos gitcode]$ git commit -m "md ReadMe on dev branch"
[dev 215c360] md ReadMe on dev branch
 1 file changed, 1 insertion(+)

现在，dev 分⽀的⼯作完成，我们就可以切换回 master 分⽀：

[tmp@VM-24-16-centos gitcode]$ git checkout master 
Switched to branch 'master'
[tmp@VM-24-16-centos gitcode]$ git branch 
  dev
* master
[tmp@VM-24-16-centos gitcode]$ cat ReadMe 
hello bit
hello bit
xxx code
version1
version2
version3

• 看到这⾥就能明⽩了，因为我们是在dev分⽀上提交的，⽽master分⽀此刻的提交点并没有变。
• 当切换到 master 分⽀之时，HEAD 就指向了 master，当然看不到提交了！

合并分⽀

为了能在master分支上看到dev分支做出的改变 我们需要将dev分支合并到master分支上

hyb@139-159-150-152:~/gitcode$ git branch 
* dev
 master
hyb@139-159-150-152:~/gitcode$ git checkout master # 切换到 master 上进⾏合并
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git merge dev # 合并 dev 分⽀
Updating 16623e1..3740dce
Fast-forward
 ReadMe | 1 +
 1 file changed, 1 insertion(+)
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch

git merge 命令⽤于合并指定分⽀到当前分⽀。合并后，master 就能看到 dev 分⽀提交的内容了。此时的状态如图如下所⽰

Fast-forward 代表“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度⾮常快。当然，也不是每次合并都能 Fast-forward，我们后⾯会讲其他⽅式的合并。

删除分⽀

合并完成后, dev 分⽀对于我们来说就没⽤了， 那么dev分⽀就可以被删除掉，注意如果当前正处于某分⽀下，就不能删除当前分⽀，如：

[tmp@VM-24-16-centos gitcode]$ git checkout dev
Switched to branch 'dev'
[tmp@VM-24-16-centos gitcode]$ git branch -D dev
error: Cannot delete the branch 'dev' which you are currently on.

而可以在其他分支上删除当前分支

[twg@VM-24-16-centos test]$ git branch 
  dev
* master
[twg@VM-24-16-centos test]$ git branch -D dev
Deleted branch dev (was c28dddd).
[twg@VM-24-16-centos test]$ git branch 
* master

此时的状态如图如下所⽰。

因为创建、合并和删除分⽀⾮常快，所以Git⿎励你使⽤分⽀完成某个任务，合并后再删掉分⽀，这和直接在master分⽀上⼯作效果是⼀样的，但过程更安全 ,这也是分支的意义所在

合并冲突

可是，在实际分⽀合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。为了演⽰这问题，创建⼀个新的分⽀ dev1 ，并切换⾄⽬标分⽀，我们可以使⽤ git checkout -
b dev1 ⼀步完成创建并切换的动作，⽰例如下

[twg@VM-24-16-centos test]$ git checkout -b dev1
Switched to a new branch 'dev1'
[twg@VM-24-16-centos test]$ git branch 
* dev1
  master

在 dev1 分⽀下修改 ReadMe ⽂件，更改⽂件内容如下，并进⾏⼀次提交，如

hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch # 将 aaa 该为 bbb
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[dev1 0854245] modify ReadMe
 1 file changed, 1 insertion(+), 1 deletion(-)

切换⾄ master 分⽀，观察 ReadMe ⽂件内容:

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch

我们发现，切回来之后，⽂件内容由变成了⽼的版本，这种现象很正常，我们现在也完全能理解。此时在 master 分⽀上，我们对 ReadMe ⽂件再进⾏⼀次修改，并进⾏提交，如下：

hyb@139-159-150-152:~/gitcode$ git branch 
 dev1
* master
hyb@139-159-150-152:~/gitcode$ vim ReadMe 
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write ccc for new branch 
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[master c10f6d0] modify ReadMe
 1 file changed, 1 insertion(+), 1 deletion(-)

现在， master 分⽀和 dev1 分⽀各⾃都分别有新的提交，变成了这样：

这种情况下，Git 只能试图把各⾃的修改合并起来，但这种合并就可能会有冲突，如下所示：

下所⽰：
hyb@139-159-150-152:~/gitcode$ git merge dev1 
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
hyb@139-159-150-152:~/gitcode$ git status
On branch master
You have unmerged paths.
 (fix conflicts and run "git commit")
 (use "git merge --abort" to abort the merge)
Unmerged paths:
 (use "git add <file>..." to mark resolution)
 both modified: ReadMe
no changes added to commit (use "git add" and/or "git commit -a")

发现 ReadMe ⽂件有冲突后，可以直接查看⽂件内容，要说的是 Git 会⽤<<<<<<<，=======，
.>>>>>>>来标记出不同分⽀的冲突内容，如下所⽰：

hyb@139-159-150-152:~/gitcode$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
<<<<<<< HEAD
write ccc for new branch 
=======
write bbb for new branch 
>>>>>>> dev1

此时我们必须要⼿动调整冲突代码，并需要再次提交修正后的结果！！（再次提交很重要，切勿忘记）

hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch 
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"merge ReadMe"
[master 2976afc] merge ReadMe

到这⾥冲突就解决完成，此时的状态变成了

⽤带参数的 git log也可以看到分⽀的合并情况，具体⼤家可以⾃⾏搜索 git log 的⽤法

hyb@139-159-150-152:~/gitcode$ git log --graph --pretty=oneline --abbrev-commit
* 2976afc (HEAD -> master) merge ReadMe
|\ 
| * c594fd1 (dev1) modify ReadMe
* | c10f6d0 modify ReadMe
|/

最后，不要忘记 dev1 分⽀使⽤完毕后就可以删除了

分⽀管理策略

通常合并分⽀时，如果可能，Git 会采⽤ Fast forward 模式。还记得如果我们采⽤ Fast forward 模式之后，形成的合并结果是什么呢？回顾⼀下

在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提交到底是 merge 进来的还是正常提交的。

但在合并冲突部分，我们也看到通过解决冲突问题，会再进⾏⼀次新的提交，得到的最终状态为：

那么这就不是 Fast forward 模式了，这样的好处是，从分⽀历史上就可以看出分⽀信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分⽀，但依旧能看到 master 其实是由其他分⽀合并
得到：

hyb@139-159-150-152:~/gitcode$ git log --graph --pretty=oneline --abbrev-commit
* 2976afc (HEAD -> master) merge ReadMe
|\ 
| * c594fd1 modify ReadMe
* | c10f6d0 modify ReadMe
|/

Git ⽀持我们强制禁⽤ Fast forward 模式，那么就会在 merge 时⽣成⼀个新的 commit ，这样，从分⽀历史上就可以看出分⽀信息

下⾯我们实战⼀下 --no-ff ⽅式的 git merge 。⾸先，创建新的分⽀ dev2 ，并切换⾄新的分⽀:

hyb@139-159-150-152:~/gitcode$ git checkout -b dev2
Switched to a new branch 'dev2'

修改 ReadMe ⽂件，并提交⼀个新的 commit:

hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[dev2 41b082f] modify ReadMe
 1 file changed, 1 insertion(+)

切回master分支 并合并：

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git merge --no-ff -m "merge with no-ff" dev2
Merge made by the 'recursive' strategy.
 ReadMe | 1 +
 1 file changed, 1 insertion(+)
hyb@139-159-150-152:~/gitcode$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d

请注意 --no-ff 参数，表⽰禁⽤ Fast forward 模式。禁⽤ Fast forward 模式后合并会创⼀个新的 commit ，所以加上 -m 参数，把描述写进去。

合并后，查看分⽀历史：

hyb@139-159-150-152:~/gitcode$ git log --graph --pretty=oneline --abbrev-commit
* 5bd16b4 (HEAD -> master) merge with no-ff
|\ 
| * 41b082f (dev2) modify ReadMe
|/

可以看到，不使⽤ Fast forward 模式，merge后就像这样:

所以在合并分⽀时，加上 --no-ff 参数就可以⽤普通模式合并，合并后的历史有分⽀，能看出来曾经做过合并，⽽ fast forward 合并就看不出来曾经做过合并。

分⽀策略

在实际开发中，我们应该按照⼏个基本原则进⾏分⽀管理：
⾸先，master分⽀应该是⾮常稳定的，也就是仅⽤来发布新版本，平时不能在上⾯⼲活；

那在哪⼲活呢？⼲活都在dev分⽀上，也就是说，dev分⽀是不稳定的，到某个时候，⽐如1.0版本发布时，再把dev分⽀合并到master上，在master分⽀发布1.0版本；你和你的⼩伙伴们每个⼈都在dev分⽀上⼲活，每个⼈都有⾃⼰的分⽀，时不时地往dev分⽀上合并就可以了。所以，团队合作的分⽀看起来就像这样

bug 分⽀

假如我们现在正在 dev2 分⽀上进⾏开发，开发到⼀半，突然发现 master 分⽀上⾯有 bug，需要解决。在Git中，每个 bug 都可以通过⼀个新的临时分⽀来修复，修复后，合并分⽀，然后将临时分⽀删除

可现在 dev2 的代码在⼯作区中开发了⼀半，还⽆法提交，怎么办？例如：

hyb@139-159-150-152:~/gitcode$ git branch 
* dev2
 master
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d
i am coding ...
hyb@139-159-150-152:~/gitcode$ git status
On branch dev2
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git restore <file>..." to discard changes in working directory)
 modified: ReadMe
no changes added to commit (use "git add" and/or "git commit -a")

Git 提供了 git stash 命令，可以将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时间恢复出来

hyb@139-159-150-152:~/gitcode$ git stash
Saved working directory and index state WIP on dev2: 41b082f modify ReadMe
hyb@139-159-150-152:~/gitcode$ git status
On branch dev2
nothing to commit, working tree clean

⽤ git status 查看⼯作区，就是⼲净的（除⾮有没有被 Git 管理的⽂件），因此可以放⼼地创建分⽀来修复bug
储藏 dev2 ⼯作区之后，由于我们要基于master分⽀修复 bug，所以需要切回 master 分⽀，再新建临时分⽀来修复 bug，⽰例如下：

hyb@139-159-150-152:~/gitcode$ git checkout master # 切回master
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git checkout -b fix_bug # 新建并切换到 fix_bug 分
⽀
Switched to a new branch 'fix_bug'
hyb@139-159-150-152:~/gitcode$ vim ReadMe 
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e # 修复bug--忘记写e
hyb@139-159-150-152:~/gitcode$ git add ReadMe # 重新add，commit
hyb@139-159-150-152:~/gitcode$ git commit -m"fix bug"
[fix_bug 4bbc0c4] fix bug
 1 file changed, 1 insertion(+), 1 deletion(-)

修复完成后，切换到 master 分⽀，并完成合并，最后删除 fix_bug 分⽀：

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git merge --no-ff -m"merge fix_bug branch" 
fix_bug 
Merge made by the 'recursive' strategy.
ReadMe | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e
hyb@139-159-150-152:~/gitcode$ git branch -d fix_bug 
Deleted branch fix_bug (was 4bbc0c4).

⾄此，bug 的修复⼯作已经做完了，我们还要继续回到 dev2 分⽀进⾏开发。切换回 dev2 分⽀：

hyb@139-159-150-152:~/gitcode$ git checkout dev2 
Switched to branch 'dev2'
hyb@139-159-150-152:~/gitcode$ git status
On branch dev2
nothing to commit, working tree clean

⼯作区是⼲净的，刚才的⼯作现场存到哪去了？⽤ git stash list 命令看看：

hyb@139-159-150-152:~/gitcode$ git stash list
stash@{0}: WIP on dev2: 41b082f modify ReadMe

⼯作现场还在，Git 把 stash 内容存在某个地⽅了，但是需要恢复⼀下，如何恢复现场呢？我们可以使⽤ git stash pop 命令，恢复的同时会把 stash 也删了，⽰例如下：

hyb@139-159-150-152:~/gitcode$ git stash pop
On branch dev2
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git restore <file>..." to discard changes in working directory)
 modified: ReadMe
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (4f873250b3503687b5efd26196776aee7e3724c2)

再次查看的时候，我们已经发现已经没有现场可以恢复了

hyb@139-159-150-152:~/gitcode$ git stash list
hyb@139-159-150-152:~/gitcode$

总结：
Master 分⽀⽬前最新的提交，是要领先于新建 dev2 时基于的 master 分⽀的提交的，所以我们在 dev2 中当然看不⻅修复 bug 的相关代码。
我们的最终⽬的是要让 master 合并 dev2 分⽀的，那么正常情况下我们切回 master 分⽀直接合并即可，但这样其实是有⼀定⻛险的。
是因为在合并分⽀时可能会有冲突，⽽代码冲突需要我们⼿动解决（在 master 上解决）。我们⽆保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项⽬中，代码冲突不只⼀两⾏那么简单，有可能⼏⼗上百⾏，甚⾄更多，解决的过程中难免⼿误出错，导致错误的代码被合并到 master 上。此时的状态为

解决这个问题的⼀个好的建议就是：最好在⾃⼰的分⽀上合并下 master ，再让 master 去合并dev ，这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试，⽽不影响 master 。此时的状态为：

对应的实操演⽰如下，要说明的是，以下演⽰的merge操作，没有使⽤ --no-ff ，但上述的图⽰是禁⽤ Fast forward 了模式后得出的，主要是为了⽅便解释问题

# dev 合并 master
hyb@139-159-150-152:~/gitcode$ git branch 
* dev2
 master
hyb@139-159-150-152:~/gitcode$ git merge master 
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
# 发⽣冲突
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
<<<<<<< HEAD
a,b,c,d
i am coding ... Done!
=======
a,b,c,d,e
>>>>>>> master
# 解决冲突并重新提交
hyb@139-159-150-152:~/gitcode$ vim ReadMe 
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e
i am coding ... Done!
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"merge master"
[dev2 447d29f] merge master
hyb@139-159-150-152:~/gitcode$ git status
On branch dev2
nothing to commit, working tree clean
# 切回master
hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
# master 合并 dev2---⽆需解决冲突！！
hyb@139-159-150-152:~/gitcode$ git merge dev2 
Updating 193421f..447d29f
Fast-forward
 ReadMe | 1 +
 1 file changed, 1 insertion(+)
 hyb@139-159-150-152:~/gitcode$ git status
On branch master
nothing to commit, working tree clean
# 删除 dev2 分⽀
hyb@139-159-150-152:~/gitcode$ git branch -d dev2 
Deleted branch dev2 (was 447d29f)

删除临时分⽀

软件开发中，总有⽆穷⽆尽的新的功能要不断添加进来。
添加⼀个新功能时，你肯定不希望因为⼀些实验性质的代码，把主分⽀搞乱了，所以，每添加⼀个新功能，最好新建⼀个分⽀，我们可以将其称之为 feature 分⽀，在上⾯开发，完成后，合并，最后，删除该 feature 分⽀。
可是，如果我们今天正在某个 feature 分⽀上开发了⼀半，被产品经理突然叫停，说是要停⽌新功能的开发。虽然⽩⼲了，但是这个 feature 分⽀还是必须就地销毁，留着⽆⽤了。这时使⽤传统的 git branch -d 命令删除分⽀的⽅法是不⾏的。演⽰如下：

# 新增并切换到 dev3 分⽀
hyb@139-159-150-152:~/gitcode$ git checkout -b dev3
Switched to a new branch 'dev3'
# 开始开发新功能并提交
hyb@139-159-150-152:~/gitcode$ vim ReadMe 
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e
i am coding ... Done!
i am writing new features ...
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe for new features"
[dev3 cd2f149] modify ReadMe for new features
 1 file changed, 1 insertion(+)
# 此时新功能叫停
# 切回master准备删除dev3
hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
# 常规删除dev3分⽀时失败
hyb@139-159-150-152:~/gitcode$ git branch -d dev3 
error: The branch 'dev3' is not fully merged.
If you are sure you want to delete it, run 'git branch -D dev3'.

直接使⽤传统的删除分⽀的⽅法不⾏，按照提⽰，有了如下⽅式

hyb@139-159-150-152:~/gitcode$ git branch -D dev3 
Deleted branch dev3 (was cd2f149).
hyb@139-159-150-152:~/gitcode$ git branch 
* master

done!

Git工具上篇小结

分⽀在实际中有什么⽤呢？假设你准备开发⼀个新功能，但是需要两周才能完成，第⼀周你写了50%的代码，如果⽴刻提交，由于代码还没写完，不完整的代码库会导致别⼈不能⼲活了。如果等代码全部写完再⼀次提交，⼜存在丢失每天进度的巨⼤⻛险。
现在有了分⽀，就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀，别⼈看不到，还继续在原来的分⽀上正常⼯作，⽽你在⾃⼰的分⽀上⼲活，想提交就提交，直到开发完毕后，再⼀次性合并到原来的分⽀上，这样，既安全，⼜不影响别⼈⼯作。并且 Git ⽆论创建、切换和删除分⽀，Git在1秒钟之内就能完成！⽆论你的版本库是1个⽂件还是1万个⽂件。

结语：

看到这里，相信你已经掌握了 Git 本地仓库的核心操作 —— 从初始化仓库、管理文件版本，到灵活运用分支解决开发场景中的实际问题。这些看似基础的指令与概念，正是企业级开发中版本控制的 “基石”：工作区、暂存区、版本库的分层设计，让代码修改更可控；分支的创建与合并，让多需求并行开发更高效；冲突解决与git stash等技巧，更是应对突发需求（如紧急 bug 修复）的关键。

当然，Git 的能力远不止于此 —— 下一篇我们将跳出 “本地”，探索远程仓库（以 Gitee 为例）的交互操作，学习代码推送、拉取、多人协作时的权限管理与流程规范，真正打通 “本地开发→远程协作” 的完整链路。

如果在实操中遇到问题（比如分支合并后找不到提交记录、git reset --hard误删代码），不妨回头再梳理本文中的案例，Git 的每一个操作都有其底层逻辑，理解/.git目录的结构变化（如 HEAD 指针、objects 对象库），能帮你更 “通透” 地用好这个工具。也欢迎在评论区分享你的学习心得或遇到的坑，我们一起把 Git 从 “会用” 变成 “用熟”，让它成为你开发路上的得力助手～