版本控制器 Git 的原理与使用（哇！这也太全了）

本文链接：https://blog.csdn.net/q322359/article/details/138962283

根据 commit ID 获取这次提交的详细信息

第三种情况（撤销工作区，暂存区以及版本库的代码）

Git 是什么？

我们在工作时，进行代码开发时，肯定会对工作的文件进行一次又一次的更新，迭代一个又一个的版本，那么经历多次更新以后，就很难去管理每个版本的文件，也很难清楚每个版本分别更新了什么内容。

因此为了能够更⽅便我们管理这些不同版本的⽂件，便有了版本控制器。版本控制器是⼀个可以记录⼯程的每⼀次改动和版本迭代的⼀个管理系统，同时也⽅便多⼈协同作业

⽬前最主流的版本控制器就是 Git 。Git 可以控制电脑上所有格式的⽂件，例如 doc、excel、dwg、 dgn、rvt 等等。对于我们开发⼈员来说，Git 最重要的就是可以帮助我们管理软件开发项⽬中的源代码⽂件！

Git 安装

Linux-centos 平台

查看我们是否已经安装 git

git --version

没有查找到该命令说明我们的 Linux 服务器上还没有安装 git

输入以下命令安装 git

sudo yum install git -y

末尾出现 Complete！表示安装完成

Linux-ubuntu 平台

查看我们是否已经安装 git

$ git --version

安装 Git：

$ sudo apt-get install git -y

创建 Git 本地仓库

Git 只能管理存储在仓库中的文件，所以我们要创建一个 Git 本地仓库

我们要在一个文件中创建 Git 本地仓库，所以先创建一个目录 gitcode

mkdir gitcode

在 gitcode 目录中执行以下命令创建仓库

git init

通过以下命令查看目录中的隐藏文件

ls -a

可以看到 gitcode 文件夹中多了一个 .git 目录，.git ⽬录是 Git 来跟踪管理仓库的，不要⼿动修改这个⽬录⾥⾯的⽂件

通过以下命令查看 .git 目录中的详细内容

 tree .git

在本地的 git 仓库中，有⼏个⽂件和目录很特殊

• index:暂存区， git add 后会更新该内容。

• HEAD:默认指向 master 分⽀的⼀个指针。

• refs/heads/master: ⽂件⾥保存当前 master 分⽀的最新 commit id 。

• objects: 包含了创建的各种版本库对象及内容，可以简单理解为放了 git 维护的所有修改。

配置本地仓库

当安装 Git 后⾸先要做的事情是设置你的用户名称和 e-mail 地址，这是⾮常重要的。

Your Name 处设置你的用户名称，email@example.com 处设置你的邮箱地址

其中 --global 是⼀个可选项。如果使⽤了该选项，表⽰这台机器上所有的 Git 仓库都会使⽤这个配置。

要注意，执⾏命令时必须要在仓库⾥。

git config [--global] user.name "Your Name" 
git config [--global] user.email "email@example.com"

查看配置命令：

git config -l

删除对应的配置命令为：

当配置时加上了 --global ，那么删除时也要加上 --global

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

添加文件

将⽂件添加到暂存区

• 添加⼀个或多个⽂件到暂存区：

git add [file1] [file2] ...

• 添加指定⽬录到暂存区，包括⼦⽬录：

git add [dir]

• 添加当前⽬录下的所有⽂件改动到暂存区：

git add .

将暂存区内容添加到本地仓库中

• 提交暂存区全部内容到本地仓库中:

message 表示本次提交的描述信息

git commit -m "message"

• 提交暂存区的指定⽂件到仓库区：

git commit [file1] [file2] ... -m "message"

查看当前仓库状态

git status

查看提交记录

git log

该命令显⽰从最近到最远的提交⽇志，并且可以看到我们 commit 时的⽇志消息

如果嫌输出信息太多，看得眼花缭乱的，可以试试加上 --pretty=oneline 参数

git log --pretty=oneline

我们也可以通过下面的命令用图来更清晰的查看提交记录

git log --graph --abbrev-commit

获取最新一次提交的 commit ID

cat .git/refs/heads/master

根据 commit ID 获取这次提交的详细信息

git cat-file -p commitID

分析文件是否被修改以及获取修改内容

分析文件与上一次提交的差别

该命令只能知道哪些文件发生了修改，但并不知道具体修改的内容

 git status

分析文件在暂存区和工作区的区别

得到具体修改的内容

git diff 文件名

红色的数据是改动前的内容，绿色的数据是改动后的内容

分析文件在版本库和工作区的区别

得到具体修改的内容

注意：HEAD 只能是大写

git diff HEAD -- [文件名]

版本回退

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

命令：

git reset [--soft | --mixed | --hard] HEAD 文件名

通过 commitID 指定要回退的版本

• --mixed 为默认选项，使⽤时可以不⽤带该参数。该参数将暂存区和版本库的内容退回为指定提交版本内容，⼯作区⽂件保持不变。

• --soft 参数对于⼯作区和暂存区的内容都不变，只是将版本库回退到某个指定版本。

• --hard 参数将暂存区,⼯作区和版本库都退回到指定版本。切记⼯作区有未提交的代码时不要⽤这个命令，因为⼯作区会回滚，你没有提交的代码就再也找不回了，所以使⽤该参数前⼀定要慎重。

• HEAD 说明：

◦ 可直接写成 commit id，表⽰指定退回的版本

◦ HEAD 表⽰当前版本

◦ HEAD^ 上⼀个版本

◦ HEAD^^ 上上⼀个版本

后悔回退了

人是多变的，我们回退到了之前的版本，但发现回退太多了，此时我们反悔了怎么办？可以再根据 commitID 回退回去

首先我们要知道要回退版本的 commitID ，命令：

git reflog

通过该命令可以获取到所有版本的 commitID ，我们找到想回退的版本，用 git reset 命令回退即可

撤销修改

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

此时分为 3 种情况：

我们修改的代码没有经过 add 和 commit 操作，所以只有工作区的代码需要撤销
我们修改的代码经过了 add 的操作但没有经过 commit 操作，所以工作区和暂存区的代码需要撤销
我们修改的代码经过了 add 和 commit 操作，所以工作区，暂存区以及版本库中的代码都需要撤销

第一种情况（只撤销工作区的代码）

根据下述命令，将工作区的代码撤销成最近一次 commit 的样子

命令：

git checkout -- 文件名

第二种情况（撤销工作区和暂存区的代码）

首先我们通过版本回退命令 git reset 回退暂存区中的内容为当前版本（版本库中最新的版本）

git reset HEAD 文件名

此时就回到了第一种情况，需要撤销工作区的代码

git checkout -- 文件名

第三种情况（撤销工作区，暂存区以及版本库的代码）

由于版本库中的代码也需要撤销，说明我们要将工作区，暂存区以及版本库中的代码都回退到上一个版本

git reset --hard HEAD^

删除文件

第一种方式：

删除文件

rm -rf 文件名

将修改添加到暂存区

git add 文件名

将暂存区的内容提交到版本库

git commit -m "描述信息"

第二种方式：

删除文件并将修改提交到暂存区

git rm 文件名

将暂存区的内容提交到版本库

git commit -m "描述信息"

分支管理

查看分支

git branch

在查看分支时，前面带 * 号，绿色的分支是当前的工作分支

查看本地及其远程仓库的分支

git branch -a

如图绿色的 master 表示本地的分支，红色的 dev 和 master 分支是远程仓库的分支

创建分支

git branch 分支名称

新创建分支的起点是最新的一次提交

切换分支

git checkout 分支名称

如图，工作分支已经切换为了 yulin

相对于我们将指向工作分支的指针 HEAD 指向了新建的分支

创建并切换分支

一步到位

git checkout -b 分支名称

合并分支

 git merge 要合并的分支

注意：如果我们想在 master 分支中合并 dev 分支，我们需要先将分支切换到 master，再在 master 分支中调用命令合并 dev 分支

当我们切换到新的分支 dev 后，在新分支 dev 下提交了某些操作，此时 master 分支中没有 dev 分支中所做的新操作

进行合并，让 master 分支中包含 dev 分支中所做的操作，实际上就是 master 指针移动

删除分支

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

git branch -d 分支名称

因为创建、合并和删除分⽀⾮常快，所以 Git ⿎励你使⽤分⽀完成某个任务，合并后再删掉分⽀，这和直接在 master 分⽀上⼯作效果是⼀样的，但过程更安全。（因为在分支上写的代码要是出现什么问题就可以选择不合并，这样就不会影响原来的代码）

强制删除分支

可能会有这样的场景：我们正在某个 yulin 分⽀上开发了⼀半，已经提交到版本库中了，被产品经理突然叫停，说是要取消该功能的开发。虽然⽩⼲了，但是这个 yulin 分⽀还是必须就地销毁，留着⽆⽤了。这时使⽤传统的 git branch -d 命令删除分⽀的⽅法是不⾏的。

因为我们在 yulin 分⽀上已经提交了修改到版本库中，git 会认为这个分支是有用的，所以在没有合并到 master 分支之前，不允许随便删除该分支，我们通过强制删除才能删除该分支

git branch -D 分支名称

合并冲突

在实际分⽀合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题，比如在 yulin 分支中我们修改了 helloGit 文件中的内容，在 master 分支中我们也修改了 helloGit 文件中的内容，此时 Git 就不清楚要用哪个分支的内容作为最终合并的内容，就出现了合并冲突

在进行合并时，出现如下图的报错。代表在文件 helloGit 中出现了合并冲突，需要解决冲突并提交结果

此时我们打开出现冲突的 helloGit 文件：

可以看到，被 HEAD 标签包裹的是当前分支中的代码，被 yulin 标签包裹的是 yulin 分支中的代码，这两段代码就是出现冲突的代码，我们需要删掉一个，此时我们留下 master 分支中的代码：

此时我们⼿动调整了冲突代码，并需要再次提交修正后的结果！！（再次提交很重要，切勿忘记），提交完成后将 yulin 分支重新合并

合并模式

当我们的合并没有出现冲突正常合并时，我们得到的日志图为：

我们创建了 yullin 分支，并在 yulin 分支上编写代码，最后合并 yulin 分支，但在日志图上完全看不出代码是创建了一个分支来写的还是直接在 master 主分支上写的。

而合并分支时出现了合并冲突，我们得到的日志图为：

通过这个日志图我们可以很好的看出，代码是创建了一个 yulin 分支，并在 yulin 分支上编写代码，最后合并 yulin 分支得到的，不是直接在 master 分支上写的。

为什么会有这两种差别呢？因为当我们正常合并分支时，合并模式为：Fast forward 模式，这种模式下查看分⽀历史时，会丢掉分⽀信息，看不出来最新提交到底是 merge 进来的还是正常提交的。

而我们合并出现冲突后，解决了冲突再进行合并时用到的就是非 Fast forward 模式，在分⽀历史上就可以看出分⽀信息。

那么我们可不可以在正常提交时修改合并模式为非 Fast forward 模式，以便在以后得到分⽀信息呢？答案当然是可以的

在合并分支时使用以下命令：

git merge --no-ff -m "合并描述" 分支名称

正常合并分支后查看日志图：

此时虽然我们是正常合并分支，但在日志图依然能够看到详细的分支信息，说明合并模式用的是非 Fast forward 模式

分支策略

在实际开发中，我们应该按照⼏个基本原则进⾏分⽀管理：

⾸先，master分⽀应该是⾮常稳定的，也就是仅⽤来发布新版本，平时不能在上⾯⼲活；那在哪⼲活呢？⼲活都在 dev 分⽀上，也就是说，dev 分⽀是不稳定的，到某个时候，⽐如1.0版本发布时，dev 分支上的代码通过了测试，再把dev分⽀合并到master上，在master分⽀发布1.0版本；

你和你的⼩伙伴们每个⼈都在 dev 分⽀上⼲活，每个⼈都有⾃⼰的分⽀，时不时地往 dev 分⽀上合并就可以了。

bug 分支

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

此时就面临一个问题，dev 分支上的代码才开发了一半，还不能提交，但我们又需要马上去新的分支上解决 bug，如果直接切换的话，在 dev 分支上工作区修改的代码会同步到 master 分支的工作区中，但 master 分支是稳定的分支，我们不希望未测试的代码同步到 master 分支的工作区。

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

储藏当前分支工作区的内容

git stash

储藏以后查看当前分支状态，可以看到工作区为空

1.储藏 dev ⼯作区之后，由于我们要基于 master 的分⽀ fix_bug 修复 bug，所以需要切回 master 分⽀，再新建临时分⽀ fix_bug 来修复 bug

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

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

4.现在要将之前储藏的 dev 分支工作区的内容进行恢复

查看储藏的内容

⽤ git stash list 命令可以查看储藏的内容

git stash list

可以看到，储藏区中有我们刚刚储藏的内容

恢复储藏的内容

我们可以使⽤ git stash pop 命令恢复储藏的内容，恢复的同时会把储藏的记录也删了

git stash pop

另外，恢复现场也可以采⽤ git stash apply 恢复，但是恢复后，stash 记录并不删除，你需要⽤ git stash drop 来删除

你可以多次 stash（储藏），恢复的时候，先⽤ git stash list 查看，然后恢复指定的 stash，⽤命令 git stash apply stash@{0}

注意：后面合并 dev 分支到 master 分支上时可能会出现合并冲突，因为 bug 只是在 master 分支上修改了，dev 分支上还没有改变，所以 dev 分支和 master 分支的一些代码可能不同，从而导致合并冲突。

我们可以先将 master 分支合并到 dev 分支上，这样合并冲突就是在 dev 分支上解决，在 dev 分支上解决了合并冲突后，再将 dev 分支合并给 master 分支，这样做比较保险，保证 master 分支的稳定性

远程仓库

Git 是分布式版本控制系统，同⼀个 Git 仓库，可以分布到不同的机器上。怎么分布呢？实际情况往往是这样，找⼀台电脑充当中央服务器的⻆⾊，每天24⼩时开机，其他每个⼈都从这个“服务器”仓库克隆⼀份到自己的电脑上，并且各⾃把各⾃的提交推送到服务器仓库⾥，也从服务器仓库中拉取别⼈的提交。

我们可以⾃⼰搭建⼀台运⾏ Git 的中央服务器，来帮助开放人员推送代码和拉取代码，但没这个必要，因为有大佬已经将服务器做好了，通过码云网站就可以做到中央服务器的效果

Issues 模块

Issues 模块是用于管理 bug 的，在这里可以描述 bug 的详细信息，并设置负责这个 bug 的负责人，以及发现 bug 的分支，解决 bug 的时间范围，bug 的优先级等等，开发人员

发布 bug 以后，在 ”开启的“ 这里就可以看到刚刚发布的 bug

在解决这个 bug 以后，可以设置状态为 ”已完成“

Pull Requests 模块

Pull Requests 模块用于向管理员或者专门管理合并分支的人员发起合并分支的请求，输入要求合并的源分支以及目标分支，在管理员批准后便能合并分支

克隆远程仓库

克隆/下载远端仓库到本地，需要使⽤ git clone 命令，后⾯跟上我们的远端仓库的链接，远端仓库的链接可以从仓库中找到，选择“克隆/下载”获取远程仓库链接：

SSH 协议和 HTTPS 协议是 Git 最常使⽤的两种数据传输协议。SSH 协议使⽤了公钥加密和公钥登陆机制，体现了其实⽤性和安全性，使⽤此协议需要将我们的公钥放上服务器，由 Git 服务器进⾏管理。使⽤ HTTPS ⽅式时，没有要求，可以直接克隆下来。

HTTPS 方式

git clone 仓库HTTPS路径

SSH 方式

git clone 仓库ssh路径

由于SSH 协议使⽤了公钥加密和公钥登陆机制所以使⽤此协议需要将我们的公钥放上服务器，由 Git 服务器进⾏管理

当我们没有在码云上设置公钥，直接就执行 git clone 命令就会报错

在码云上设置公钥之前，我们首先要知道自己服务器的公钥是什么：

获取服务器公钥

1.在用户主目录下，看看有没有 .ssh ⽬录，如果有，再看看这个⽬录下有没有 id_rsa （私钥）和 id_rsa.pub （公钥）这两个⽂件，如果已经有了，可直接在 id_rsa.pub 文件中获取公钥。如果没有，需要创建 SSH Key

ssh-keygen -t rsa -C "邮箱"

注意：命令中所填邮箱必须是码云上所绑定的邮箱

输入命令后，一直回车即可创建 SSH Key

此时再查看 .ssh 文件就能发现有了 id_rsa 和 id_rsa.pub 文件，这两个就是 SSH Key 的秘钥对， id_rsa 是私钥，不能泄露出去， id_rsa.pub 是公钥，可以放⼼地告诉任何⼈

设置服务器公钥

1.点击头像，选择设置

2.在设置中找到 SSH 公钥

3.将服务器公钥粘贴到对应位置

添加公钥后，我们再通过 SSH 方式从码云上克隆项目：

此时克隆成功！！

向远程仓库推送

在推送前要注意，如果我们之前设置过全局的 name 和 e-mail，这两项配置需要和 gitee 上配置的⽤户名和邮箱⼀致，否则会出错。或者从来没有设置过全局的 name 和 e-mail，那么我们第⼀次提交时也会报错。这就需要我们重新配置下了

@ 后的便是用户名

修改配置完成以后，便可以向远程仓库推送：

git push origin master:master

格式：

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

上述命令表示我们要将本地的 master 分⽀推送到 origin 主机的 master 分⽀。第一个 master 是本机的 master 分支，第二个 master 是远程仓库的 master 分支

推送成功！这⾥由于我们使⽤的是 SSH 协议，是不⽤每⼀次推送都输⼊密码的，⽅便了我们的推送操作。如果你使⽤的是 HTTPS 协议，有个⿇烦地⽅就是每次推送都必须输⼊⼝令。

拉取远程仓库

当远程仓库领先于本地仓库⼀个版本时，为了使本地仓库保持最新的版本，我们需要拉取远程仓库中的代码，并合并到本地。Git 提供了 git pull 命令，该命令⽤于从远程获取代码并合并到本地

git pull origin master:master

格式：

git pull <远程主机名> <远程分⽀名>:<本地分⽀名>

成功拉取远程仓库中的代码与本地代码进行合并

忽略特殊文件

在⽇常开发中，我们有些⽂件不想或者不应该提交到远端，⽐如保存了数据库密码的配置⽂件，那怎么让 Git 知道呢？在 Git ⼯作区的根⽬录下创建⼀个特殊的 .gitignore ⽂件，然后把要忽略的⽂件名填进去，Git 就会⾃动忽略这些⽂件了。

我们不需要从头写 .gitignore ⽂件，码云在创建仓库时就可以为我们⽣成，不过需要我们主动勾选⼀下：

我们在 .gitignore 文件中写入如下配置，Git 会忽视 hello.txt 文件，所有以 .ini .so 结尾的文件，不忽视 a.so 文件

当我们对 hello.txt 文件以及所有以 .ini .so 结尾的文件进行操作后， Git 不会进行追踪。

强制添加

但有些时候，你就是想添加⼀个⽂件到 Git，但由于这个⽂件被 .gitignore 忽略了，根本添加不了，那么可以⽤ -f 强制添加：

git add -f [filename]

查找导致文件被忽视的规则

或者你发现，可能是 .gitignore 写得有问题，需要找出来到底哪个规则写错了，⽐如说 a.ini ⽂件是要被添加的，可以⽤ git check-ignore 命令检查：

git check-ignore -v 被忽视的文件

下述结果就表明，a.ini 文件被忽视是因为 .ignore 文件中的第二条规则 *.ini

给命令配置别名

在我们使⽤ Git 期间，有些命令敲的时候着实让⼈头疼（太⻓了。。），幸运的是，git ⽀持对命令进⾏简化！

举个例⼦，将 git status 简化为 git st ，对应的命令为：

git config --global alias.st status

--global 表示该配置作用于全局，alias 表示别名，st 便是为 status 设置的别名，后面的命令会将 st 转换成 status

标签管理

标签 tag ，可以简单的理解为是对某次 commit 的⼀个标识，相当于起了⼀个别名。例如，在项⽬发布某个版本的时候，针对最后⼀次 commit 起⼀个 v1.0 这样的标签来标识⾥程碑的意义。

这有什么⽤呢？相较于难以记住的 commit id ， tag 很好的解决这个问题，因为 tag ⼀定要给⼀个让⼈容易记住，且有意义的名字。当我们需要回退到某个重要版本时，直接使⽤标签就能很快定位到。

创建标签

切换到需要打标签的分⽀上（如 master 分支），然后，敲命令 git tag [name] 就可以打⼀个新标签，默认标签是打在最新提交的 commit 上的

git tag 标签名称

在指定的 commit 上打标签

git tag 标签内容 commitID

创建带有说明的标签

Git 还提供可以创建带有说明的标签，⽤ -a 指定标签名，-m 指定说明⽂字，格式为：

git tag -a [name] -m "XXX" [commit_id]

在查看标签内容时可以看到说明⽂字

查看所有标签

可以⽤命令 git tag 查看所有标签：

git tag

得到标签的顺序不是按时间顺序列出，⽽是按字⺟排序的，如下图，先 v0.5 在 v1.0

查看标签信息

可以⽤ git show [tagname] 查看标签信息

git show [tagname]

推送标签

我们可以看到在仓库中有一个位置存放了标签

如果要推送某个标签到远程仓库，使⽤命令 git push origin

git push origin <tagname>

推送成功后，可以看到，码云上已经多了刚刚推送的标签

当然，如果你本地有很多标签，也可以⼀次性的全部推送到远端:

git push origin --tags

可以看到所有的标签都一次性推送到了远程仓库中

删除标签

如果标签已经推送到了远程仓库，那么删除标签时就需要先将本地的标签删除，再将对标签的修改推送到远程仓库（虽然也可以在码云上直接删除，但不建议直接修改远程仓库中的内容）

通过 git tag -d 删除本地标签：

git tag -d 标签名称

通过 git push origin 将对标签的修改推送到远程仓库

git push origin :删除的标签名

如图，成功在远程仓库中删除了标签 v0.5

多人协作

为了实现多人协作开发的效果，分别在 linux 和 windows 上针对于同项⽬进⾏协作开发。

⽬前，我们的仓库中只有⼀个 master 主分⽀，但在实际的项⽬开发中，在任何情况下其实都是不允许直接在 master 分⽀上修改代码的，这是为了保证主分⽀的稳定。所以在开发新功能时，常常会新建其他分⽀，供开发时进⾏迭代使⽤。

在码云上新建分支

在项目仓库中点击如图位置，选择新建分支

填写分支属性，新建分支（分支起点表示基于哪个分支来新建分支）

创建成功的远程分⽀是可以通过 Git 拉取到本地来，以实现完成本地开发⼯作。

推送代码时在码云上创建分支

假设此时我们处于 yulin 分支上，我们想推送本地 yulin 分支的代码到码云上的 yulin 分支，但此时码云上并没有创建 yulin 分支，以下命令可以在推送代码的同时为我们在码云上创建一个 yulin 分支

git push -u origin 分支名称

拉取码云上的分支

创建成功的远程分⽀是可以通过 Git 拉取到本地来，以实现完成本地开发⼯作。

注意：要本地分支和远程分支建立连接了以后，才可以通过 git pull 来拉取远程分支

通过 git pull 来实现远程分支的拉取操作

git pull

如图，成功将远程的 dev 分支拉取到本地

注意在本地对某个分支中的内容进行修改前，记得先通过 git pull 拉取一下远程仓库中的信息合并到本地仓库，保证分支上的信息是最新的

查看本地分支以及远程仓库分支

通过 git branch -a 来查看本地分支以及远程仓库分支（但前提是要 pull ⼀下拉取最新的远端仓库，才能看到最新的内容）

git branch -a

远程分支删除后，本地依然能看到的解决办法

当我们将远程分支 dev 删除以后，通过 git branch -a 命令依然能够看到远程分支 dev，该怎么办呢？远程分支删除后，git branch -a 命令中的分支记录需要我们自己更新，通过命令：

git remote prune origin

输入上述命令进行更新后，通过git branch -a 命令查看远程分支就没有已经被删除的分支了

创建分支并与远程仓库建立连接

git checkout -b 命令是用于创建并切换分支的，也可以通过该命令在创建并切换分支的过程中与远程仓库建立连接

命令：

git checkout -b 本地分支 origin/远程分支

如图，将本地的 dev 分支与远程仓库的 dev 分支建立了连接

上述方法是在创建分支的时候为分支建立连接，那要是分支已经创建，该如何建立连接呢？

通过以下命令建立连接：

git branch --set-upstream-to=origin/远程分支 本地分支

可以看到远程分支 yulin 与本地分支 yulin 已经建立了连接

查看本地分支和远程分支的连接关系

通过 git branch -vv 命令查看本地分支和远程分支的连接关系

git branch -vv

如图，可以看到本地的 dev，master 分支和远程的 dev ，master 分支之间有连接关系

将修改内容发送到远程分支

当我们在分支上开发完毕后，将修改添加进暂存区（add），再将修改提交到版本库（commit）后，就需要将该分支版本库中的代码发送到远程分支

若当前本地分支和远程分支没有建立连接，则使用完整的 git push 命令发送版本库中的代码：

git push origin 分支名称

如图，成功推送 dev 分支版本库中的代码到远程仓库中的 dev 分支

若当前本地分支和远程分支建立连接，则使用简约的 git push 命令发送版本库中的代码：

git push

如图，成功推送 dev 分支版本库中的代码到远程仓库中的 dev 分支

推送修改到远程分支出现合并冲突

当我们推送修改到远程分支时，如果其他的同事与我们修改了同一个文件，那么大概率会发生冲突，发生冲突后我们就要在本地解决冲突

要想解决冲突，首先⽤ git pull 把最新的提交从远程仓库抓下来，然后，在本地进⾏合并，并解决冲突，再推送（记得将修改提交到本地的版本库中再推送）

将开发好的代码合并到 master 分支

代码合并

我们在 dev 这种临时分支上开发完毕后，要将临时分支合并到 master 分支上。

1.切换⾄ master 分⽀, pull ⼀下，保证本地的 master 是最新内容。合并前这么做是⼀个好习惯

git checkout master 
git pull

2.切换⾄ dev 分⽀, 合并 master 分⽀，这么做是因为如果有冲突，可以在 dev 分⽀上进⾏处理，⽽不是在 master 上解决冲突。这么做是⼀个好习惯

git checkout dev 
git merge master

3.切换⾄ master 分⽀，合并 dev 分⽀

git checkout master
git merge dev

4.将 master 分⽀推送⾄远端

git push origin master

此时，dev 分⽀对于我们来说就没⽤了，那么 dev 分⽀就可以被删除掉。

在码云上申请合并(推荐)

比较推荐大家在码云上申请合并分支，因为在码云上申请需要经过审查员和测试员的批准后才会合并分支。

这样能大大确保代码不会出现问题。因为经过了多个人的审查。

我们在码云仓库页面的 Pull Request 处来发起合并分支的申请。

企业级开发模型

系统开发环境

对于开发⼈员来说，在系统开发过程中最常⽤的⼏个环境必须要了解⼀下：

1. 开发环境：开发环境是程序猿们专⻔⽤于⽇常开发的服务器。为了开发调试⽅便，⼀般打开全部错误报告和测试⼯具，是最基础的环境。

2. 测试环境：⼀个程序在测试环境⼯作不正常，那么肯定不能把它发布到⽣产机上。该环境是开发环境到⽣产环境的过渡环境。

3. 预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测⽽设⽴的⼀套环境。其配置等基本和⽣产环境⼀致，⽬的是能让我们发正式环境时更有把握！所以预发布环境是你的产品质量最后⼀道防线，因为下⼀步你的项⽬就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内，为单独的⼀些机器。

4. ⽣产环境：是指正式提供对外服务的线上环境，例如我们⽬前在移动端或PC端能访问到的APP都是⽣产环境。

Git 分支设计规范

以下的 Git 分支设计规范仅仅是比较常用的规范，并不是所有公司都遵守的规范

环境有了概念后，那么对于开发⼈员来说，⼀般会针对不同的环境来设计分⽀，例如：

注：以上表格中的分⽀和环境的搭配仅是常⽤的⼀种，可视情况⽽定不同的策略。

master 分⽀

• master 为主分⽀，该分⽀为只读且唯⼀分⽀。⽤于部署到正式发布环境，⼀般由合并 release 分⽀得到。

• 主分⽀作为稳定的唯⼀代码库,任何情况下不允许直接在 master 分⽀上修改代码。

• 产品的功能全部实现后，最终在 master 分⽀对外发布，另外所有在 master 分⽀的推送应该打标签（tag）做记录，⽅便追溯。

• master 分⽀不可删除。

release 分⽀

• release 为预发布分⽀，基于本次上线所有的 feature 分⽀合并到 develop 分⽀之后，基于 develop 分⽀创建。可以部署到测试或预发布集群。

• 命名以 release/ 开头，建议的命名规则: release/version_publishtime 。

• release 分⽀主要⽤于提交给测试⼈员进⾏功能测试。发布提测阶段，会以 release 分⽀代码为基准进⾏提测。

• 如果在 release 分⽀测试出问题，需要回归验证 develop 分⽀看否存在此问题。

• release 分⽀属于临时分⽀，产品上线后可选删除。

develop 分⽀

• develop 为开发分⽀，基于 master 分⽀创建的只读且唯⼀分⽀，始终保持最新完成以及 bug 修复后的代码。可部署到开发环境对应集群。

• 可根据需求⼤⼩程度确定是由 feature 分⽀合并，还是直接在上⾯开发（⾮常不建议）。

feature 分⽀

• feature 分⽀通常为新功能或新特性开发分⽀，以 develop 分⽀为基础创建 feature 分⽀。

• 命名以 feature/ 开头，建议的命名规则： feature/user_createtime_feature 。

• 新特性或新功能开发完成后，开发⼈员需合到 develop 分⽀。

• ⼀旦该需求发布上线，便将其删除。

hotfix 分⽀

• hotfix 分⽀为线上 bug 修复分⽀或叫补丁分⽀，主要⽤于对线上的版本进⾏ bug 修复。当线上出现紧急问题需要⻢上修复时，需要基于 master 分⽀创建 hotfix 分⽀。

• 命名以 hotfix/ 开头，建议的命名规则: hotfix/user_createtime_hotfix

• 当问题修复完成后，需要合并到 master 分⽀和 develop 分⽀并推送远程。⼀旦修复上线，便将其删除。

⼀张图总结：

企业级项目管理

在这里介绍一个企业级项目管理的平台 Gitee 企业版

新建项目

登录平台后，我们可以新建项目：

输入项目的相关信息即可

创建仓库

在项目创建完毕后，一个项目下一般会包含多个仓库，为项目创建仓库

填写仓库相关信息完成创建

创建分支

在代码仓库中创建分支来对代码版本进行管理，并且方便开发，测试，运维人员操作对应的代码版本

输入分支内容即可创建分支

合并分支

开发人员要在代码评审 Pull Requests 处发起合并分支的请求，等管理人员或审查人员通过后，分支才会合并

发起合并分支请求

填写合并分支的相关信息，比如要合并的源分支和目标分支

审查合并请求

等管理人员或审查人员通过后，分支就会合并

一些业务情况

修复测试环境 Bug

在 develop 测试出现了Bug，建议⼤家直接通过 develop 分支创建一个 feature 分⽀进⾏修复。修复后将 feature 分⽀合并到 develop

修改预发布环境 Bug

在 release 测试出现了 Bug，⾸先要回归下 develop 分⽀是否同样存在这个问题。如果存在，修复流程与修复测试环境 Bug 流程⼀致。如果不存在，这种可能性⽐较少，⼤部分是数据兼容问题，环境配置问题等。

修改正式环境 Bug

在 master 测试出现了 Bug，⾸先要回归下 develop 分⽀是否同样存在这个问题。如果存在，修复流程与修复测试环境 Bug 流程⼀致。如果不存在，这种可能性也⽐较少，⼤部分是数据兼容问题，环境配置问题等。

紧急修复正式环境 Bug

需求在测试环节未测试出 Bug，上线运⾏⼀段时候后出现了 Bug，需要紧急修复的。有的企业⾯对紧急修复时，⽀持不进⾏测试环境的验证，但还是建议验证下预发布环境。可基于 master 创建 hotfix/xxx 分⽀，修复完毕后发布到 master 验证，验证完毕后，将 master 代码合并到 develop 分⽀（因为 develop 分支是开发分支，要保证最新的代码版本），同时删掉 hotfix/xxx 分⽀。