当前位置：首页 > news >正文

Git多人协作与企业级开发模型

news 来源：原创 2025/6/29 9:02:16

1.多人协作一

2.多人协作二

3.远程分⽀删除后，本地gitbranch-a依然能看到的解决办法

4.企业级开发模型

4.1.Git的重要性

4.2.系统开发环境

4.3.Git 分⽀设计规范

1.多人协作一

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

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

是时候⼲最重要的⼀件事情了，实现多⼈协作开发！为了做这件事情，我们需要先做⼀些准备⼯作。

我们之前已经将项⽬clone到了指定⽬录，如：

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

我们打开电脑自带的powershell这个软件

我们切换好目录来

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

三种邀请用户的方式任选其一

到此，相当于有了两个⽤⼾，分别在linux和windows上针对于同项⽬进⾏协作开发，我们的准备⼯作到此结束。

⽬前，我们的仓库中只有⼀个master主分⽀，但在实际的项⽬开发中，在任何情况下其实都是不允许直接在master分⽀上修改代码的，这是为了保证主分⽀的稳定。

所以在开发新功能时，常常会新建其他分⽀，供开发时进⾏迭代使⽤。

那么接下来，就让我们在gitee上新建dev远程分⽀供我们使⽤：

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

接下来让我们和另⼀名开发的⼩伙伴都将远程仓库进⾏⼀次拉取操作，并观察结果：

对于我们要操作的是：

之前讲的 git branch 其实只能查看本地分⽀，要查看远程分⽀需要加上-r 选项。但前提是要 pull ⼀下拉取最新的远端仓库，才能看到最新的内容。

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

对于⼩伙伴要操作的是：

现在，你和你的⼩伙伴就可以在 dev 上完成开发。

⾸先，让我们在 dev 分⽀上进⾏⼀次开发，并 push 到远程。例如：

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

⾄此，我们已经将代码成功推送⾄码云，接下来假如你的⼩伙伴要和你协同开发，碰巧也要对file.txt ⽂件作修改，并试图推送，例如：

我们打开那个file.txt，修改成下面这样子

我们发现不能推送到远程仓库里面去

这时推送失败，因为你的小伙伴的最新提交和你推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用 git pull把最新的提交从 origin/dev 抓下来，然后，在本地进行合并，并解决冲突，再推送。

小伙伴的操作如下:

这个时候我们就发现file.txt文件里面发生冲突了，我们编辑一下这个文件

解决冲突，重新推送：

期间会出现下面这个，我们输入gitee的账号和密码就ok了

此时，我们看到远端的码云已经能看到我们的新提交了！

由此，两名开发者已经开始可以进⾏协同开发了，不断的 git pull/add/commit/push ,遇到了冲突，就使⽤我们之前讲的冲突处理解决掉冲突。

对于你来说，要想看到⼩伙伴的代码，只需要 pull ⼀下即可，例如：

最后不要忘记，虽然我们是在分⽀上进⾏多⼈协作开发，但最终的⽬的是要将开发后的代码合并到 master上去，让我们的项⽬运⾏最新的代码。接下来我们就需要做这件事情了：

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

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

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

将 master 分⽀推送⾄远端

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

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

我们可以直接在远程仓库中将dev分⽀删除掉：

总结⼀下，在同⼀分⽀下进⾏多⼈协作的⼯作模式通常是这样：

• ⾸先，可以试图⽤git push origin branch-name推送⾃⼰的修改；
• 如果推送失败，则因为远程分⽀⽐你的本地更新，需要先⽤git pull试图合并；
• 如果合并有冲突，则解决冲突，并在本地提交；
• 没有冲突或者解决掉冲突后，再⽤git push origin branch-name推送就能成功！
• 功能开发完毕，将分⽀merge进master，最后删除分⽀。

2.多人协作二

⼀般情况下，如果有多需求需要多⼈同时进⾏开发，是不会在⼀个分⽀上进⾏多⼈开发，⽽是⼀个需求或⼀个功能点就要创建⼀个 feature 分⽀。

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

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

新增本地分⽀ feature-1 并切换

新增需求内容创建 function1 ⽂件

将 feature-1 分⽀推送到远端

对于⼩伙伴来说，可以进⾏以下操作：

创建并切换到feature-2分支下

创建新文件function2

将feature-2分支推送到远程仓库

此时，在本地，你看不⻅他新建的⽂档，他看不⻅你新建的⽂档。并且推送各⾃的分⽀时，并没有任何冲突，你俩互不影响，⽤起来很舒服！！

再来看下远端码云上此时的状态：

对于你的feature-1分⽀：

对于⼩伙伴的feature-2分⽀：

正常情况下，你俩就可以在⾃⼰的分⽀上进⾏专业的开发了！

但天有不测⻛云，你的⼩伙伴突然⽣病了，但需求还没开发完，需要你帮他继续开发，于是他便把 feature-2 分⽀名告诉你了。

这时你就需要在⾃⼰的机器上切换到feature-2分⽀帮忙继续开发，要做的操作如下：

必须先拉取远端仓库内容

可以看到远程已经有了 feature-2

切换到 feature-2 分⽀上，可以和远程的 feature-2 分⽀关联起来，否则将来只使⽤ git push 推送内容会失败

切换成功后，便可以看⻅feature-2分⽀中的function2⽂件了，接着就可以帮⼩伙伴进⾏开发：

继续开发

推送内容

查看远程状态，推送成功了：

这时，你的⼩伙伴已经修养的差不多，可以继续进⾏⾃⼰的开发⼯作，那么他⾸先要获取到你帮他开发的内容，然后接着你的代码继续开发。或者你已经帮他开发完了，那他也需要在⾃⼰的电脑上看看你帮他写的代码：

我们发现代码没有pull下来

Pull ⽆效的原因是⼩伙伴没有指定本地feature-2分⽀与远程origin/feature-2分⽀的链接，根据提⽰，设置feature-2和origin/feature-2的链接即可：

现在总算是拉取成功了

⽬前，⼩伙伴的本地代码和远端保持严格⼀致。你和你的⼩伙伴可以继续在不同的分⽀下进⾏协同开发了。

各⾃功能开发完毕后，不要忘记我们需要将代码合并到master中才算真正意义上的开发完毕。

由于你的⼩伙伴率先开发完毕，于是开始 merge ：

1.切换master分支pull一下，保证本地master是最新内容

2.切换至feature-2分支，合并master分支

3.切换至master分支，合并feature-2分支

4.将master分支推送至远程仓库

此时远程仓库的状态：

当你的⼩伙伴将其代码 merge 到 master后，你也完成开发了，也需要进行merge到master 操作，于是你：

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

切换⾄ feature-1 分⽀ , 合并 master 分⽀

这么做是因为如果有冲突，可以在 feature-1 分⽀上进⾏处理，⽽不是在 master 上解决冲突。

这么做是⼀个好习惯

期间可能会遇到下面这个，直接ctrl+o保存，输入文件名，然后ctrl+x退出

1 、由于 feature-1 分⽀已经 merge 进来了新内容，为了保证远程分⽀最新，所以最好 push ⼀下。

2 、要 push 的另⼀个原因是因为在实际的开发中， master 的 merge 操作⼀般不是由我们⾃⼰在本地进行

其他⼈员或某些平台 merge 时，操作的肯定是远程分⽀，所以就要保证远程分⽀的最新。

3 、如果 merge 出现冲突，不要忘记需要 commit 才可以 push!!

切换⾄ master 分⽀，合并 feature-1 分⽀

将 master 分⽀推送⾄远端

此时远程仓库的状态：

此时， feature-1 和 feature-2 分⽀对于我们来说就没⽤了，那么我们可以直接在远程仓库中将dev分⽀删除掉：

这就是多⼈协作的⼯作模式，⼀旦熟悉了，就⾮常简单。

3.远程分⽀删除后，本地gitbranch-a依然能看到的解决办法

当前我们已经删除了远程的⼏个分⽀，使⽤ git branch -a 命令可以查看所有本地分⽀和远程分⽀，但发现很多在远程仓库已经删除的分⽀在本地依然可以看到。例如：

使⽤命令git remote show origin ，可以查看remote地址，远程分⽀，还有本地分⽀与之相对应关系等信息。

此时我们可以看到那些远程仓库已经不存在的分⽀，根据提⽰，使⽤git remote prune origin 命令：

这样就删除了那些远程仓库不存在的分⽀。对于本地仓库的删除，之前的课程已经学过了，⼤家可以⾃⾏从操作。

4.企业级开发模型

4.1.Git的重要性

我们知道，⼀个软件从零开始到最终交付，⼤概包括以下⼏个阶段：规划、编码、构建、测试、发布、部署和维护。

最初，程序⽐较简单，⼯作量不⼤，程序员⼀个⼈可以完成所有阶段的⼯作。但随着软件产业的⽇益发展壮⼤，软件的规模也在逐渐变得庞⼤。软件的复杂度不断攀升，⼀个⼈已经hold不住了，就开始出现了精细化分⼯。

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

• 开发团队(尤其是敏捷团队)追求变化

• 运维团队追求稳定双⽅往往存在利益的冲突。

⽐如，精益和敏捷的团队把持续交付作为⽬标，⽽运维团队则为了线上的稳定⽽强调变更控制。部⻔墙由此建⽴起来,这当然不利于IT价值的最⼤化。

为了弥合开发和运维之间的鸿沟，需要在⽂化、⼯具和实践⽅⾯的系列变⾰⸺DevOps正式登上舞台。

DevOps（Development和Operations的组合词）是⼀种重视“软件开发⼈员（Dev）”和“IT运维技术⼈员（Ops）”之间沟通合作的⽂化、运动或惯例。

透过⾃动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在DevOps的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控，由此可⻅DevOps的强⼤。

讲了这么多，这个故事到底和我们课程的主题Git有什么关系呢？

举⼀个很简单的例⼦就能说明这个问题。⼀个软件的迭代，在我们开发⼈员看来，说⽩了就是对代码进⾏迭代，那么就需要对代码进⾏管理。

如何管理我们的代码呢，那不就是Git（分布式版本控制系统）！所以Git对于我们开发⼈员来说其重要性就不⾔⽽喻了。

4.2.系统开发环境

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

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

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

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

4. ⽣产环境：是指正式提供对外服务的线上环境，例如我们⽬前在移动端或PC端能访问到的APP都是⽣产环境。这⼏个环境也可以说是系统开发的三个重要阶段：开发->测试->上线。

⼀张图总结：

4.3.Git 分⽀设计规范

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

分支名称	适用环境	名字
master	生产环境	主分支
release	预发布/测试环境	预发布分支
develop	开发环境	开发主分支
feature	本地（需求开发分支）	需求开发分支
hotfix	本地（紧急修复分支）	紧急修复分支

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

master 分支

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

release 分支

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

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 分支并推送远程。
一旦修复上线，便将其删除。

其实，以上跟⼤家讲解的是企业级常⽤的⼀种Git分⽀设计规范：GitFlow模型。

但要说的是，该模型并不是适⽤于所有的团队、所有的环境和所有的⽂化。

如果你采⽤了持续交付，你会想要⼀些能够尽可能简化交付过程的东西。

有些⼈喜欢基于主⼲的开发模式，喜欢使⽤特性标志。

然⽽，从测试的⻆度来看，这些反⽽会把他吓⼀跳。

关键在于站在你的团队或项⽬的⻆度思考：这种分⽀模型可以帮助你们解决哪些问题？它会带来哪些问题？这种模式为哪种开发提供更好的⽀持？你们想要⿎励这种⾏为吗？你选择的分⽀模型最终都是比特就业课为了让⼈们更容易地进⾏软件协作开发。

因此，分⽀模型需要考虑到使⽤者的需求，⽽不是盲⽬听信某些所谓的“成功的分⽀模型”。

所以对于不同公司，规范是会有些许差异，但万变不离其宗，是为了效率与稳定。

1.多人协作一

2.多人协作二

3.远程分⽀删除后，本地gitbranch-a依然能看到的解决办法

4.企业级开发模型

4.1.Git的重要性

4.2.系统开发环境

4.3.Git 分⽀设计规范

相关文章：