萌系学 Git：从提交规范到团队协作，工具喵教你玩转企业级工具

前言：

在上篇博客中，我们跟着 “工具喵” 掌握了 Git 本地仓库的核心操作 —— 从文件的 add/commit、版本回退，到分支创建与冲突解决，搞定了单人开发时的版本管理需求。但实际企业开发中，光有本地仓库远远不够，多人协作时如何同步代码、避免冲突？远程仓库该怎么和本地链接？主流的开发模型又该如何落地？

本篇就聚焦这些问题，一边手把手教你用 HTTPS/SSH 链接本地与远程仓库，实操git push/git pull等交互指令；一边拆解 Git Flow、GiteeHub Flow 等企业级开发模型，帮你打通 “本地开发→远程协作” 的全流程，为团队协同打下基础

正文：

远程操作

我们⽬前所说的所有内容（⼯作区，暂存区，版本库等等），都是在本地！也就是在你的笔记本或者计算机上。⽽我们的 Git 其实是分布式版本控制系统！什么意思呢？

可以简单理解为，我们每个⼈的电脑上都是⼀个完整的版本库，这样你⼯作的时候，就不需要联⽹了，因为版本库就在你⾃⼰的电脑上。既然每个⼈电脑上都有⼀个完整的版本库，那多个⼈如何协作呢？⽐⽅说你在⾃⼰电脑上改了⽂件A，你的同事也在他的电脑上改了⽂件A，这时，你们俩之间只需把各⾃的修改推送给对⽅，就可以互相看到对⽅的修改了

分布式版本控制系统的安全性要⾼很多，因为每个⼈电脑⾥都有完整的版本库，某⼀个⼈的电脑坏掉了不要紧，随便从其他⼈那⾥复制⼀个就可以了

在实际使⽤分布式版本控制系统的时候，其实很少在两⼈之间的电脑上推送版本库的修改，因为可能你们俩不在⼀个局域⽹内，两台电脑互相访问不了。也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有⼀台充当“中央服务器”的电脑，但这个服务器的作⽤仅仅是⽤来⽅便“交换”⼤家的修改，没有它⼤家也⼀样⼲活，只是交换修改不⽅便⽽已。有了这个“中央服务器”的电脑，这样就不怕本地出现什么故障了（⽐如运⽓差，硬盘坏了，上⾯的所有东西全部丢失，包括git的所有内容）

新建远程仓库

搭建Gitee 平台下的远程仓库

新建远程项⽬仓库

填写基本信息

创建成功

从创建好的远程仓库中我们便能看到，之前在本地学习过的分⽀，也存在于远程仓库中并被管理起来了。刚创建的仓库有且只有⼀个默认的master分⽀

克隆远程仓库

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

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

1. 使⽤ HTTPS ⽅式：

1. 使⽤ SSH ⽅式

使⽤ SSH ⽅式克隆仓库，由于我们没有添加公钥到远端库中，服务器拒绝了我们的 clone 链接。需要我们设置⼀下

第⼀步：创建SSH Key。在⽤⼾主⽬录下，看看有没有.ssh⽬录，如果有，再看看这个⽬录下有没有id_rsa 和 id_rsa.pub 这两个⽂件，如果已经有了，可直接跳到下⼀步。如果没有，需要创建SSH Key：

此时有 .ssh 但是.ssh 里没有id_rsa 和id_rsa.pub

顺利的话，可以在⽤⼾主⽬录⾥找到 .ssh ⽬录，⾥⾯有 id_rsa 和 id_rsa.pub 两个⽂件，这两个就是SSH Key的秘钥对， id_rsa 是私钥，不能泄露出去， id_rsa.pub 是公钥，可以放⼼地告诉任何⼈

点击确认后，需要对你进⾏认证，输⼊你的账号密码即可。⾄此，我们的准备⼯作全部做完，欢快的clone吧

配置完公钥后 一定不要忘记 完成我们的目标 克隆远程仓库

done, 成功！如果有多个⼈协作开发，GitHub/Gitee 允许添加多个公钥，只要把每个⼈的电脑上的Key 都添加到 GitHub/Gitee，就可以在每台电脑上往 GitHub/Gitee 上提交推送了。当我们从远程仓库克隆后，实际上 Git 会⾃动把本地的 master 分⽀和远程的 master 分⽀对应起来，并且，远程仓库的默认名称是 origin 。在本地我们可以使⽤ git remote 命令，来查看远程库的信息，

或者，⽤ git remote -v 显⽰更详细的信息

上⾯显⽰了可以抓取和推送的origin的地址。如果没有推送权限，就看不到 push 的地址。推送是什么意思呢，我们继续往下看

向远程仓库推送

本地已经 clone 成功远程仓库后，我们便可以向仓库中提交内容，例如新增⼀个 file.txt ⽂件：

提交时要注意，如果我们之前设置过全局的 name 和 e-mail，这两项配置需要和 gitee 上配置的⽤⼾名和邮箱⼀致，否则会出错。或者从来没有设置过全局的 name 和 e-mail，那么我们第⼀次提交时也会报错。这就需要我们重新配置下了，同样要注意需要和 gitee 上配置的⽤⼾名和邮箱⼀致。如何配置已讲过，在这⾥就不再赘述。到这⾥我们已经将内容提交⾄本地仓库中，如何将本地仓库的内容推送⾄远程仓库呢，需要使⽤ git push 命令，该命令⽤于将本地的分⽀版本上传到远程并合并，命令格式如下：

此时我们要将本地的 master 分⽀推送到 origin 主机的 master 分⽀，则可以:

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

HTTP 虽然克隆方便 不需要公钥 但是每次 push都要输入 用户名和密码

代码已经被推送⾄远端了

拉取远程仓库

为了更好的演示该操作 我直接在远程仓库更改文件 但是这种做法不推荐

在 gitee 上点击 README.md ⽂件并在线修改它

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

配置 Git

忽略特殊⽂件

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

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

如果当时没有选择这个选择，在⼯作区创建⼀个也是可以的。⽆论哪种⽅式，最终都可以得到⼀个完整的 .gitignore ⽂件，例如我们想忽略以 .so 和 .ini 结尾所有⽂件， .gitignore 的内容如下：

在 .gitignore ⽂件中也可以指定某个确定的⽂件。

最后⼀步就是把 .gitignore 也提交到远端，就完成了

检验 .gitignore 的标准就是 git status 命令是不是说 working tree clean 。我们发现Git 并没有提⽰在⼯作区中有⽂件新增，果然 .gitignore ⽣效了！

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

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

Git 会告诉我们， .gitignore 的第3⾏规则忽略了该⽂件，于是我们就可以知道应该修订哪个规则。还有些时候，当我们编写了规则排除了部分⽂件时，例如：

但是我们发现 .* 这个规则把 .gitignore 也排除了。虽然可以⽤ git add -f 强制添加进去，但有强迫症的童鞋还是希望不要破坏 .gitignore 规则，这个时候，可以添加⼀条例外规则

把指定⽂件排除在 .gitignore 规则外的写法就是 ! +⽂件名，所以，只需把例外⽂件添加进去即可

给命令配置别名

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

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

--global 参数是全局参数，也就是这些命令在这台电脑的所有Git仓库下都有⽤。如果不加，那只针对当前的仓库起作⽤。

标签管理

理解标签

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

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

创建标签

1. 在Git中打标签⾮常简单，⾸先，切换到需要打标签的分⽀上
2. 然后，敲命令 git tag [name] 就可以打⼀个新标签

默认标签是打在最新提交的 commit 上的。那如何在指定的commit上打标签呢？⽅法是找到历史提交的commit id，然后打上就可以了，⽰例如下

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

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

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

操作标签

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

因为创建的标签都只存储在本地，不会⾃动推送到远程。所以，打错的标签可以在本地安全删除。如果要推送某个标签到远程，使⽤命令 git push origin <tagname>

此时，查看远端码云，看到了标签已经被更新！完美！

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

如果标签已经推送到远程，要删除远程标签就⿇烦⼀点，先从本地删除：

然后，从远程删除。删除命令也是push，但是格式如下：

注意 这句命令 有个 :

删除 本身也是一种修改 所以可以更新 git维护的文件

码云看已经删除了

多⼈协作

多⼈协作⼀

⽬前，我们所完成的⼯作如下：

1. 基本完成 Git 的所有本地库的相关操作，git基本操作，分⽀理解，版本回退，冲突解决等等
2. 申请码云账号，将远端信息clone到本地，以及推送和拉取。是时候⼲最重要的⼀件事情了，实现多⼈协作开发！为了做这件事情，我们需要先做⼀些准备⼯作。我们之前已经将项⽬ clone 到了指定⽬录，如

我们在 windows 环境下，再 clone 同⼀个项⽬仓库，来模拟和你⼀起协作开发的另⼀名⼩伙伴：Clone 成功~！

注意，课件中是模拟了两个⽤⼾，实际开发中，每个⽤⼾都有⾃⼰的gitee/github账号，如果要多⼈进⾏协同开发，必须要将⽤⼾添加进开发者，⽤⼾才有权限进⾏代码提交：

到此，相当于有了两个⽤⼾，分别在 linux 和 windows 上针对于同项⽬进⾏协作开发，我们的准备⼯作到此结束。⽬前，我们的仓库中只有⼀个 master 主分⽀，但在实际的项⽬开发中，在任何情况下其实都是不允许直接在 master 分⽀上修改代码的，这是为了保证主分⽀的稳定。所以在开发新功能时，常常会新建其他分⽀，供开发时进⾏迭代使⽤。那么接下来，就让我们在 gitee 上新建 dev 远程分⽀供我们使⽤

创建成功的远程分⽀是可以通过 Git 拉取到本地来，以实现完成本地开发⼯作。接下来让我们和另⼀名开发的⼩伙伴都将远程仓库进⾏⼀次拉取操作，并观察结果：

1. 对于我们要操作的是:

拉取后便可以看到远程的 dev 分⽀，接着切换到 dev 分⽀供我们进⾏本地开发。要说明的是，我们切换到的是本地的 dev 分⽀，根据⽰例中的操作，会将本地分⽀和远程分⽀的进⾏关系链接。

git pull 的作用

1,拉取远程仓库与本地仓库关联的当前分支的所有改变文件2.拉取远程仓库的内容 即 各个新的分支 但是不建立联系 想要建立链接还要手动操作

现在，你和你的⼩伙伴就可以在 dev 上完成开发。⾸先，让我们在 dev 分⽀上进⾏⼀次开发，并 push 到远程例如：

让我们来看看码云上⽬前仓库的状态：

dev 分支上⾄此，我们已经将代码成功推送⾄码云，接下来假如你的⼩伙伴要和你协同开发，碰巧也要对 file.txt⽂件作修改，并试图推送，例如：这时推送失败，因为你的⼩伙伴的最新提交和你推送的提交有冲突，解决办法也很简单，Git已经提⽰我们，先⽤ git pull 把最新的提交从 origin/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，最后删除分⽀

多⼈协作⼆

⼀般情况下，如果有多需求需要多⼈同时进⾏开发，是不会在⼀个分⽀上进⾏多⼈开发，⽽是⼀个需求或⼀个功能点就要创建⼀个 feature 分⽀。现在同时有两个需求需要你和你的⼩伙伴进⾏开发，那么你们俩便可以各⾃创建⼀个分⽀来完成⾃⼰的⼯作。在上个部分我们已经了解了可以从码云上直接创建远程分⽀，其实在本地创建的分⽀也可以通过推送的⽅式发送到远端。在这个部分我们就来⽤⼀下这种⽅式。

1. 对于你来说，可以进⾏以下操作：

1. 对于⼩伙伴来说，可以进⾏以下操作：此时，在本地，你看不⻅他新建的⽂档，他看不⻅你新建的⽂档。并且推送各⾃的分⽀时，并没有任何冲突，你俩互不影响，⽤起来很舒服!!

企业级开发模型

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

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

1. 开发团队（尤其是敏捷团队）注重变化
2. 运维团队追求稳定双⽅往往存在利益的冲突。⽐如，精益和敏捷的团队把持续交付作为⽬标，⽽运维团队则为了线上的稳定⽽强调变更控制。部⻔墙由此建⽴起来,这当然不利于 IT 价值的最⼤化。为了弥合开发和运维之间的鸿沟，需要在⽂化、⼯具和实践⽅⾯的系列变⾰⸺DevOps正式登上舞台。DevOps（Development和Operations的组合词）是⼀种重视“软件开发⼈员（Dev）”和“IT运维技术⼈员（Ops）”之间沟通合作的⽂化、运动或惯例。透过⾃动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在DevOps的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控，由此可⻅DevOps的强⼤。讲了这么多，这个故事到底和我们课程的主题 Git 有什么关系呢？举⼀个很简单的例⼦就能说明这个问题。⼀个软件的迭代，在我们开发⼈员看来，说⽩了就是对代码进⾏迭代，那么就需要对代码进⾏管理。如何管理我们的代码呢，那不就是 Git（分布式版本控制系统） ！所以 Git 对于我们开发⼈员来说其重要性就不⾔⽽喻了。

系统开发环境

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

1. 开发环境：开发环境是程序猿们专⻔⽤于⽇常开发的服务器。为了开发调试⽅便，⼀般打开全部错误报告和测试⼯具，是最基础的环境。
2. 测试环境：⼀个程序在测试环境⼯作不正常，那么肯定不能把它发布到⽣产机上。该环境是开发环境到⽣产环境的过渡环境
3. 预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测⽽设⽴的⼀套环境。其配置等基本和⽣产环境⼀致，⽬的是能让我们发正式环境时更有把握！所以预发布环境是你的产品质量最后⼀道防线，因为下⼀步你的项⽬就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内，为单独的⼀些机器。
4. ⽣产环境：是指正式提供对外服务的线上环境，例如我们⽬前在移动端或PC端能访问到的APP都是⽣产环境对于规模稍微⼤点的公司来说，可不⽌这么⼏个环境，⽐如项⽬正式上线前还存在仿真/灰度环境，再⽐如还存在多套测试环境，以满⾜不同版本上线前测试的需要。⼀个项⽬的开始从设计开始，⽽⼀个项⽬的成功则从测试开始。⼀套良好的测试体系可以将系统中绝⼤部分的致命Bug 解决在系统上线之前。测试系统的完善和成熟也是衡量⼀个软件企业整体⽔平的重要指标之⼀，测试往往被忽视，因为它对可以的隐性、对软件开发企业不产⽣直接的效益，但是它却是软件质量的最终保障，乃⾄项⽬能否成功的重要因素！

Git分支设计规范

环境有了概念后，那么对于开发⼈员来说，⼀般会针对不同的环境来设计分⽀，例如：注：以上表格中的分⽀和环境的搭配仅是常⽤的⼀种，可视情况⽽定不同的策略。

master 分⽀：

1. master 为主分⽀，该分⽀为只读且唯⼀分⽀。⽤于部署到正式发布环境，⼀般由合并release 分⽀得到。
2. 主分⽀作为稳定的唯⼀代码库,任何情况下不允许直接在 master 分⽀上修改代码
3. 产品的功能全部实现后，最终在master分⽀对外发布，另外所有在master分⽀的推送应该打标签（tag）做记录，⽅便追溯。
4. master 分⽀不可删除

release 分⽀

1. release 为预发布分⽀，基于本次上线所有的 feature 分⽀合并到 develop 分⽀之后，基于 develop 分⽀创建。可以部署到测试或预发布集群
2. 命名以 release/ 开头，建议的命名规则: release/version_publishtime 。
3. release 分⽀主要⽤于提交给测试⼈员进⾏功能测试。发布提测阶段，会以 release 分⽀代码为基准进⾏提测
4. 如果在 release 分⽀测试出问题，需要回归验证 develop 分⽀看否存在此问题。
5. release 分⽀属于临时分⽀，产品上线后可选删除

develop 分⽀

1. develop 为开发分⽀，基于master分⽀创建的只读且唯⼀分⽀，始终保持最新完成以及bug 修复后的代码。可部署到开发环境对应集群。
2. 可根据需求⼤⼩程度确定是由 feature 分⽀合并，还是直接在上⾯开发（⾮常不建议）

feature 分⽀

1. feature 分⽀通常为新功能或新特性开发分⽀，以 develop 分⽀为基础创建 feature 分支
2. 命名。以 feature/ 开头，建议的命名规则： feature/user_createtime_feature 。
3. 新特性或新功能开发完成后，开发⼈员需合到 develop 分⽀
4. ⼀旦该需求发布上线，便将其删除。

hotfix 分⽀

1. hotfix 分⽀为线上 bug 修复分⽀或叫补丁分⽀，主要⽤于对线上的版本进⾏ bug 修复。当线上出现紧急问题需要⻢上修复时，需要基于 master 分⽀创建 hotfix 分⽀。
2. 命名以 hotfix/ 开头，建议的命名规则: hotfix/user_createtime_hotfix
3. 当问题修复完成后，需要合并到 master 分⽀和 develop 分⽀并推送远程。⼀旦修复上线，便将其删除

⼀张图总结：

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

企业级项⽬管理实战

Gitee企业版免费

名称可随意填写⼀个测试名称，只要能通过即可。注意，多⼈协作开发，需要将多⼈账号拉⼊⼀个企业下才⾏。如何添加成员后⾯会跟⼤家讲解。

创建项⽬

创建仓库

创建的仓库可以关联到某个项⽬中被管理

添加成员

1. 添加企业成员

申请后需要负责⼈审批通过

1. 添加项⽬成员
2. 添加仓库开发人员

拓展阅读

其他DevOps研发平台腾讯coding阿里云效拓展实践

阿⾥⻜流flow分⽀模型，及项⽬版本管理实践:

结语：

看到这里，你已经掌握了 Git 远程协作的关键技能 —— 从链接远程仓库、同步代码，到用标签管理版本、靠分支规范支撑多人开发，这些操作正是企业级项目中 “代码协同” 的核心环节。比如 SSH 免密配置让推送更高效，.gitignore 规避敏感文件提交，而 Git Flow 分支模型则像 “交通规则”，让多需求并行开发时既有序又安全。

如果在实操中遇到 “远程分支删除后本地仍显示”“push 时权限被拒” 等问题，不妨回头再梳理本文的git remote prune或公钥配置步骤。也欢迎在评论区分享你的协作故事，我们一起把 Git 从 “能用” 变成 “用得顺手”，让它成为团队开发的 “润滑剂”～