Git 原理与使用进阶：远程协作、标签管理及企业级模型

到这里我们已经将内容提交至本地仓库中，如何将本地仓库的内容推送至远程仓库呢，需要使用 git push 命令，该命令用于将本地的分支版本上传到远程并合并命令格式如下：

git push origin master

此时我们要将本地的 master 分支推送到 origin 主机的 master 分支，则可以像上面那张图里面写的。推送成功！这里由于我们使用的是 SSH 协议，是不用每一次推送都输入密码的，方便了我们的推送操作。如果你使用的是 HTTPS 协议，有个麻烦的地方就是每次推送都必须输入口令。接下来，看看码云远端：

代码已经被推送至远端了。

1.6 拉取远程仓库

在 gitee 上点击 file.txt 文件并在线修改它（我不建议这样做，最好还是在本地仓库修改代码，然后在推送到远端仓库，只是为了演示效果才这样操作）：修改内容：增加一个 hello world。

此时，远程仓库是要领先于本地仓库一个版本，为了使本地仓库保持最新的版本，我们需要拉取下远端代码，并合并到本地。Git 提供了 git pull 命令，该命令用于从远程获取代码并合并本地的版本。格式如下：

git pull

我们发现，拉取成功了！

1.7 忽略特殊文件

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

不需要从头写.gitignore 文件，gitee 在创建仓库时就可以为我们生成，不过需要我们主动勾选一下。如果当时没有选择这个选择，在工作区创建一个也是可以的。无论哪种方式，最终都可以得到一个完整的 .gitignore 文件，例如我们想忽略以.so 和.ini 结尾所有文件，.gitignore 的内容如下：

*.so
*.ini

接着我们就来验证一下.gitignore 文件的能力，在工作区新增两个文件 a.so b.ini：检验.gitignore 的标准就是 git status 命令是不是说 working tree clean。我们发现 Git 并没有提示在工作区中有文件新增，果然.gitignore 生效了！但有些时候，你就是想添加一个文件到 Git，但由于这个文件被.gitignore 忽略了，根本添加不了，那么可以用 -f 强制添加；或者你发现可能是.gitignore 写得有问题，需要找出来到底哪个规则写错了，比如说 d.so 文件是要被添加的，可以用 git check-ignore 命令检查：

Git 会告诉我们，.gitignore 的第 3 行规则忽略了该文件，于是我们就可以知道应该修订哪个规则。还有些时候，当我们编写了规则排除了部分文件时，但是我们发现 .* 这个规则把 .gitignore 也排除了。虽然可以用 git add -f 强制添加进去。但有强迫症的童鞋还是希望不要破坏.gitignore 规则。这个时候，可以添加一条例外规则；把指定文件排除在.gitignore 规则外的写法就是 ! + 文件名，所以，只需把例外文件添加进去即可。

最后一步就是把 .gitignore 和相关创建的文件也提交到远端就完成了！

1.8 给命令配置别名

在我们使用 Git 期间，有些命令敲的时候着实让人头疼（太长了…）幸运的是 Git 支持对命令行简化！举个例子，将 git status 简化为 git st，对应的命令为：

git config --global alias.st status

–global 参数是全局参数，也就是这些命令在这台电脑的所有 Git 仓库下都有用。如果不加，那只针对当前的仓库起作用。好了，现在敲 git st 看看效果：

不过，我个人还是不推荐大家现在去使用命令简化等大家工作了，再去简化自己的工作吧，目前所有的命令都要手动完成，让大家尽快适应 Git！

2. 标签管理

2.1 理解标签

标签 tag，可以简单的理解为是对某次 commit 的一个标识，相当于起了一个别名。例如，在项目发布某个版本的时候，针对最后一次 commit 起一个 v1.0 这样的标签来标识里程碑的意义。这有什么用呢？相较于难以记住的 commit id，tag 很好的解决这个问题，因为 tag 一定要给一个让人容易记住，且有意义的名字。当我们需要回退到某个重要版本时，直接使用标签就能很快定位到。

2.2 创建标签

在 Git 中打标签非常简单首先切换到需要打标签的分支上然后，敲命令 git tag [name] 就可以打一个新标签：可以用命令 git tag 查看所有标签：默认标签是打在最新提交的 commit 上的。

那如何在指定的 commit 上打标签呢？方法是找到历史提交的 commit id，然后打上就可以了，示例如下：

git tag v1.0 <commit_id>

注意，标签不是按时间顺序列出，而是按字母排序的。可以用 git show [tagname] 查看标签信息。

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

git tag -a v1.0 -m "Version 1.0 release"

另外，打完标签之后，使用 tree .git 命令查看一下你的本地库有什么变化，肯定能帮助你理解！

2.3 操作标签

如果标签打错了，也可以删除。

因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。

如果要推送某个标签到远程，使用命令 git push origin <tagname>。

此时，查看远端码云，看到了标签已经被更新！当然，如果你本地有很多标签，也可以一次性的全部推送到远端。

如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：然后，从远程删除。删除命令也是 push，但是格式如下：

git push origin :refs/tags/<tagname>

在码云上查看确实删除成功！

3. Git 实战场景—多人协作一

3.1 完成准备工作

目前，我们所完成的工作如下：

1. 基本完成 Git 的所有本地库的相关操作，git 基本操作，分支理解，版本回退，冲突解决等等。
2. 申请码云账号，将远端信息 clone 到本地，以及推送和拉取。

是时候干最重要的一件事情了，实现多人协作开发！为了做这件事情，我们需要先做一些准备工作。我们之前已经将项目 clone 到了指定目录。

我们在 mac 环境下（如果你的是 windows 环境就在 windows 下进行操作），再 clone 同一个项目仓库，来模拟和你一起协作开发的另一名小伙伴：

这样我就把我 gitee 里面的项目文件 Clone 成功到我的 mac 电脑的 git 文件夹中了！

3.2 协助开发

目前，我们的仓库中只有一个 master 主分支，但在实际的项目开发中，在任何情况下其实都是不允许直接在 master 分支上修改代码的，这是为了保证主分支的稳定。所以在开发新功能时，常常会新建其他分支，供开发时进行迭代使用。那么接下来，就让我们在 gitee 上新建 dev 远程分支供我们使用，并将它拿到本地仓库。

在 dev 分支下向 file.txt 里面增加"aaa"的内容，并把它 push 到远端仓库的 dev 分支下，至此开发者 1 的任务已经完成了！

开发者 2 将自己电脑本地的仓库代码分支与远端分支匹配一致。

我们向 file.txt 文件里面增加"bbb"的内容，并把它推送到远端仓库。

但是我们会发现有合并冲突因为开发者 1 添加的"aaa"内容和开发者 2 添加的"bbb"内容不一致，而我们最终想要的是"aaa、bbb"的文件内容，所以我们需要进行修改！

解决完冲突后，我们再次进行代码提交，我们就会发现成功了！

此时，我们看到远端的码云已经能看到我们的新提交了！由此，两名开发者已经开始可以进行协同开发了，不断的 git pull/add/commit/push，遇到了冲突就使用我们之前讲的冲突处理解决掉冲突。对于开发者 1 来说，要想看到开发者 2 的代码只需要 pull 一下即可。最后不要忘记，虽然我们是在分支上进行多人协作开发，但最终的目的是要将开发后的代码合并到 master 上去，让我们的项目运行最新的代码。

3.3 将内容合并进 master

我们查看 master 分支时会发现里面的代码并不是我们设想的那样，重要原因是缺少了 merge 操作！

方法一：我们可以使用 Pull Requests 进行 merge 操作，来合并分支。

方法二：在本地仓库中进行 master 和 dev 到 merge 操作。 切换至 master 分支，pull 一下，保证本地的 master 是最新内容。合并前这么做是一个好习惯。 切换至 dev 分支，合并 master 分支这么做是因为如果有冲突，可以在 dev 分支上进行处理，而不是在 master 上解决冲突。这么做是一个好习惯。 切换至 master 分支，合并 dev 分支，将 master 分支推送至远端。

此时，查看远端仓库，master 已经是最新代码了：

此时，dev 分支对于我们来说就没用了，那么 dev 分支就可以被删除掉。我们可以直接在远程仓库中将 dev 分支删除掉：

总结在同一分支下进行多人协作的工作模式通常是这样：

1. 首先，可以尝试用 git push origin branch-name 推送自己的修改；
2. 如果推送失败，则因为远程分支比你的本地更新，需要先使用 git pull 试图合并；
3. 如果合并有冲突，则解决冲突，并在本地提交；
4. 没有冲突或者解决掉冲突后，再用 git push origin branch-name 推送就能成功！
5. 功能开发完毕，将分支 merge 进 master，最后删除分支。

4. Git 实战场景—多人协作二

4.1 协助开发 1

一般情况下，如果有多个需求需要多人同时进行开发，是不会在一个分支上进行多人开发，而是一个需求或一个功能点就要创建一个 feature 分支。现在同时有两个需求需要开发者 1 和开发者 2 进行开发，那么你们俩便可以各自创建一个分支来完成自己的工作。在上个部分我们已经了解了可以从码云上直接创建远程分支，其实在本地创建的分支也可以通过推送的方式发送到远端。在这个部分我们就来用一下这种方式。

任务目标：

对于开发者 1 来说可以进行以下操作：新增本地分支 feature-1 并切换新增需求内容 - 创建 function1 文件将 feature-1 分支推送到远端。

对于开发者 2 来说，可以进行以下操作：创建并切换到 feature-2 分支，在分支下为需求新增 function2 文档，将 feature-2 分支推送至远端。

此时，在本地，开发者 1 看不见开发者 2 新建的文档，开发者 2 看不见开发者 1 新建的文档。并且推送各自的分支时，并没有任何冲突，开发者俩互不影响，用起来很舒服！！！再来看下远端码云上此时的状态：

对于开发者 feature-1 分支，对于开发者 2 feature-2 分支，正常情况下，开发者就可以在自己的分支上进行专业的开发了！但天有不测风云，开发者 2 突然生病了，但需求还没开发完，需要开发者 1 帮他继续开发，于是他便把 feature-2 分支名告诉你了。这时开发者 1 就需要在自己的机器上切换到 feature-2 分支帮忙继续开发，要做的下面的操作。

4.2 协助开发 2

必须先拉取远端仓库内容，可以看到远程已经有了 feature-2，切换到 feature-2 分支上，可以和远程的 feature-2 分支关联起来，否则将来只使用 git push 推送内容会失败。开发者 1 向 function2.txt 文件里面增加"i am coding"的内容！

切换成功后，便可见 feature-2 分支中的 function2.txt 文件了，接着就可以帮开发者 2 进行开发：查看远程状态，推送成功了！这时，开发者 2 已经修养的差不多，可以继续进行自己的开发工作，那么他首先要获取到开发者 1 帮他开发的内容，然后接着开发者 1 的代码继续开发。或者开发者 1 已经帮开发者 2 开发完了，那开发者 2 也需要在自己电脑上看看开发者 1 帮他写的代码：

Pull 无效的原因是开发者 2 没有指定本地 feature-2 分支与远程 origin/feature-2 分支的链接，根据提示，设置 feature-2 和 origin/feature-2 的链接即可：目前，开发者 2 的本地代码和远端保持严格一致。开发者 1 和开发者 2 可以在不同的分支下进行协同开发了。各自功能开发完毕后，不要忘记我们需要将代码合并到 master 中才算真正意义上的开发完毕！

4.3 将内容合并进 master

由于开发者 2 率先开发完毕，于是开始 merge，切换 master，pull 一下，保证本地 master 是最新的内容。切换至 feature-2 分支，合并 master 分支，切换至 master 分支，合并 feature-2 分支。将 master 分支推送至远端，此时远程仓库的状态：

当开发者 2 将其代码 merge 到 master 后，这时开发者 1 也开发完成了，也需要进行 merge 到 master 操作：切换至 master 分支，pull 一下，保证本地的 master 是最新内容。合并前这么做是一个好习惯。切换至 feature-1 分支，合并 master 分支这么做是因为如果有冲突，可以在 feature-1 分支上进行处理，而不是在 master 上解决冲突。这么做是一个好习惯。由于 feature-1 分支已经 merge 进来了新内容，为了保证远程分支最新，所以最好 push 一下。要 push 的另一个原因因为在实际的开发中，master 的 merge 操作一般不是由我们自己在本地进行操作，其他人员或某些平台 merge 时，操作的肯定是远程分支，所以就要保证远程分支的最新。如果 merge 出现冲突，不要忘记需要 commit 才可以 push！！切换至 master 分支，合并 feature-1 分支，将 master 分支推送至远端：

此时，feature-1 和 feature-2 分支对于我们来说就没用了，那么我们可以直接在远程仓库中将 dev 分支删除掉。这就是多人协作的工作模式，一旦熟悉了，就非常简单！

5. 解决 branch -a 打印已被删除的远程分支的办法

当前我们已经删除了远程的几个分支，使用 git branch -a 命令可以查看所有本地分支和远程分支，但发现很多在远程仓库已经删除的分支在本地依然可以看到。例如下面，使用命令 git remote show origin，可以查看 remote 地址，远程分支，还有本地分支与之相对应关系等信息。此时我们可以看到那些远程仓库已经不存在的分支，根据提示，使用 git remote prune origin 命令：这样就删除了那些远程仓库不存在的分支。对于本地仓库的删除。之前已经介绍过了，大家可以自行从操作。

6. 企业级开发模型

6.1 企业级开发流程

我们知道，一个软件从零开始到最终交付，大概包括以下几个阶段：规划、编码、构建、测试、发布、部署和维护。最初，程序比较简单，工作量不大，程序员一个人可以完成所有阶段的工作。但随着软件产业的日益发展壮大，软件的规模也在逐渐变得庞大。软件的复杂度不断攀升，一个人已经 hold 不住了，就开始出现了精细化分工。

但在传统的 IT 组织下，开发团队 (Dev) 和运维团队 (Ops) 之间诉求不同：

1. 开发团队 (尤其是敏捷团队) 追求变化
2. 运维团队追求稳定

双方往往存在利益的冲突。比如，精益和敏捷的团队把持续交付作为目标，而运维团队则为了线上的稳定而强调变更控制。部门墙由此建立起来，这当然不利于 IT 价值的最大化。为了弥合开发和运维之间的鸿沟，需要在文化、工具和实践方面的系列变革——DevOps 正式登上舞台。

DevOps(Development 和 Operations 的组合词) 是一种重视'软件开发人员 (Dev)'和'IT 运维技术人员 (Ops)'之间沟通合作的文化、运动或惯例。透过自动化'软件交付'和'架构变更'的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在 DevOps 的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控，由此可见 DevOps 的强大。

讲了这么多，这个到底和我们的主题 Git 有什么关系呢？举一个很简单的例子就能说明这个问题。一个软件的迭代，在我们开发人员看来，说白了就是对代码进行迭代，那么就需要对代码进行管理。如何管理我们的代码呢，那不就是 Git(分布式版本控制系统)! 所以对于开发人员来说其重要性就不言而喻了。

6.2 系统开发环境

对于开发人员来说，在系统开发过程中最常用的几个环境必须要了解一下：

1. 开发环境：开发环境是程序员们专门用于日常开发的服务器。为了开发调试方便，一般打开全部错误报告和测试工具，是最基础的环境。
2. 测试环境：一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。该环境是开发环境到生产环境的过渡环境。
3. 预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测而设立的一套环境。其配置等基本和生产环境一致，目的是能让我们发正式环境时更有把握！所以预发布环境是你的产品质量最后一道防线，因为下一步你的项目就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内，为单独的一些机器。
4. 生产环境：是指正式提供对外服务的线上环境，例如我们目前在移动端或 PC 端能访问到的 APP 都是生产环境。

这几个环境也可以说是系统开发的三个重要阶段：开发->测试->上线。

对于规模稍微大点的公司来说，可不止这么几个环境，比如项目正式上线前还存在仿真/灰度环境，再比如还存在多套测试环境，以满足不同版本上线前测试的需要。一个项目的开始从设计开始，而一个项目的成功则从测试开始。一套良好的测试体系可以将系统中绝大部分的致命 Bug 解决在系统上线之前。测试系统的完善和成熟也是衡量一个软件企业整体水平的重要指标之一，测试往往被忽视，因为它对可以的隐性、对软件开发企业不产生直接的效益，但是它却是软件质量的最终保障，乃至项目能否成功的重要因素！

6.3 Git 分支设计规范

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

注：以上表格中的分支和环境的搭配仅是常用的一种，可视情况而定不同的策略。

1. master 分支 ① master 为主分支，该分支为只读且唯一分支。用于部署到正式发布环境，一般由合并 release 分支得到。 ② 主分支作为稳定的唯一代码库，任何情况下不允许直接在 master 分支上修改代码。 ③ 产品的功能全部实现后，最终在 master 分支对外发布，另外所有在 master 分支的推送应该打标签 (tag) 做记录，方便追溯。 ④ master 分支不可删除。
2. release 分支 ① release 为预发布分支，基于本次上线所有的 feature 分支合并到 develop 分支之后，基于 develop 分支创建。可以部署到测试或预发布集群。 ② 命名以 release/开头，建议的命名规则：release/version_publishtime。 ③ release 分支主要用于提交给测试人员进行功能测试。发布提测阶段，会以 release 分支代码为基准进行提测。 ④ 如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。 ⑤ release 分支属于临时分支，产品上线后可选删除。
3. develop 分支 ① develop 为开发分支，基于 master 分支创建的只读且唯一分支，始终保持最新完成以及 bug 修复后的代码。可部署到开发环境对应集群。 ② 可根据需求大小程度确定是由 feature 分支合并，还是直接在上面开发 (非常不建议)。
4. feature 分支 ① feature 分支通常为新功能或新特性开发分支，以 develop 分支为基础创建 feature 分支。 ② 命名支。以 feature/开头，建议的命名规则：feature/user_createtime_feature。 ③ 新特性或新功能开发完成后，开发人员需合到 develop 分支。 ④ 一旦该需求发布上线，便将其删除。
5. hotfix 分支 ① hotfix 分支为线上 bug 修复分支或叫补丁分支，主要用于对线上的版本进行 bug 修复。当线上出现紧急问题需要马上修复时，需要基于 master 分支创建 hotfix 分支。 ② 命名以 hotfix/开头，建议的命名规则：hotfix/user_createtime_hotfix。 ③ 当问题修复完成后，需要合并到 master 分支和 develop 分支并推送远程。一旦修复上线，便将其删除。

其实，以上跟大家讲解的是企业级常用的一种 Git 分支设计规范：Git Flow 模型。但要说的是，该模型并不是适用于所有的团队、所有的环境和所有的文化。如果你采用了持续交付，你会想要一些能够尽可能简化交付过程的东西。有些人喜欢基于主干的开发模式，喜欢使用特性标志。然而，从测试的角度来看，这些反而会把吓一跳。关键在于站在你的团队或项目的角度思考：这种分支模型可以帮助你们解决哪些问题？它会带来哪些问题？这种模式为哪种开发提供更好的支持？你们想要鼓励这种行为吗？你选择的分支模型最终都是为了让人们更容易地进行软件协作开发。因此，分支模型需要考虑到使用者的需求，而不是盲目听信某些所谓的'成功的分支模型'。所以对于不同公司，规范是会有些许差异，但万变不离其宗，是为了效率与稳定。

6.4 企业级项目管理实战—准备工作

创建项目，创建仓库，添加成员。

1. 添加企业成员
2. 添加项目成员
3. 添加仓库开发人员

6.5 开发场景—基于 git flow 模型的实践

现有有一个订单管理的新需求需要开发，首先可以基于 develop 分支创建一个 feature/yb_20231010_pay 分支。

1. 需求在 feature/yb_20231010_pay，分支开发完毕，这时研发人员可以将代码合并到 develop 分支，将其部署在开发环境的服务器中，方便开发人员进行测试和调试。 a. 开发者在 feature 分支下发起请求评审比。 b. 审查员审查代码。 c. 审查通过，合并分支。 d. 合并成功，查看结果。
2. 在 develop 下开发人员自测通过后，先确定下 develop 不存在未测试完毕的需求，然后研发人员可基于 develop 分支创建一个 release/xxx 分支出来，可交由测试人员进行测试。
3. 测试人员测试 release 通过后 (包含测试环境和预发布环境的测试)，就可将代码合并入 master。
4. 测试人员在 master(正式环境) 测试通过后，便可删除 feature/xxx 分支。

❶ 修复测试环境 Bug 在 develop 测试出现了 Bug，建议大家直接在 feature 分支上进行修复。修复后的提测上线流程与新需求加入的流程一致。

❷ 修改预发布环境 Bug 在 release 测试出现了 Bug，首先要回归下 develop 分支是否同样存在这个问题。如果存在，修复流程与修复测试环境 Bug 流程一致。如果不存在，这种可能性比较少，大部分是数据兼容问题，环境配置问题等。

❸ 修改正式环境 Bug 在 master 测试出现了 Bug，首先要回归下 release 和 develop 分支是否同样存在这个问题。如果存在，修复流程与修复测试环境 Bug 流程一致。如果不存在，这种可能性也比较少，大部分是数据兼容问题，环境配置问题等。

❹ 紧急修复正式环境 Bug 需求在测试环节未测试出 Bug，上线运行一段时候后出现了 Bug，需要紧急修复的。有的企业面对紧急修复时，支持不进行测试环境的验证，但还是建议验证下预发布环境。可基于 master 创建 hotfix/xxx 分支，修复完毕后发布到 master 验证，验证完毕后，将 master 代码合并到 develop 分支，同时删掉 hotfix/xxx 分支。