【Git原理与使用】多人协作与开发模型（2）

一、多人协作

(一)多人协作一

1、情景

2、 origin/master

3、git branch

4、远程链接

5、总结

(二)多人协作二

1、引言

2、情景

3、流程

4、解决方法

二、企业级开发模型

1、DevOps背景

2、DevOps是什么

3、DevCps与git的关系

4、系统开发环境

5、Git分支设计规范

6、企业级项目管理一般流程

7、开发场景一基于gitflow模型的实战

一、多人协作

(一)多人协作一

1、情景

目标：master分支下file.txt文件新增代码“aaa”、“bbb”

实现：由开发者1新增“aaa”，由开发者2新增“bbb”

条件：在一个分支下协作完成

2、 origin/master

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

3、git branch

只能查看本地分支，要查看远程分支需要加上-r选项。但前提是要pull一下拉取最新的远程仓库，才能看到最新的内容

4、远程链接

切换到本地dev分支，将本地的dev与远程dev进行关系链接

//在切换到dev分支就与远程dev连接

git checkout -b dev origin/dev

//在创建本地dev后忘记连接远程dev可以使用

git branch --set-upstream -to=origin/der dev

5、总结

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

①首先，可以试图用git push origin [branch-name]推送自己的修改

②如果推送失败，则因为远程分支比本地内容新，需要先用git pull试图合并

③如果合并冲突，则解决冲突，并在本地提交

④解决后，再用git push origin dev推送就能成功

⑤功能开发完毕，将分支git merge dev进master，最后删除分支

(二)多人协作二

1、引言

一般情况下，如果有需求需要多人同时进行开发，是不会在一个分支上进行多人开发，而是一个需或一个功能点就要创建一个feature分支。

2、情景

目标：远程master分支下新增func1和func2文件

实现：由开发者1新增func1，由开发者2新增func2

条件：在不同分支下协作完成

3、流程

(1)开发者1

git branch

git checkout -b feature-1 #新增本地分支fecature-1并切换

vim func1 #新增需求内容

cat func1 #查看

git add func1 #添加到暂存区

git commit -m " add func1" #添加版本库

git push origin feature-1 #将feature-1分支推送到远端

(2)开发者2同理在 feature-2进行专业的开发了

(3)某天开发者2生病，需要你帮助他继续开发，这时你就需要切换到 feature-2分支帮忙开发了

git pull #必须先拉取远端仓库内容

git branch -a #可以看到远程已经有了feature-2

git checkout -b feature-2 origin/feature-2 #切换到 feature-2分支上，可以和远程的feature-2分支关联起来，否则将来只使用git push推送内容会失败

vim func2

cat func2

git add func2

ait commit -m "modify func2"

git push origin feature-2

(4)这时，你的小伙伴开发2修养好了，可以继续他自己的开发工作了，那么他首先要获取到你帮他开发的内容，接着继续开发。

git pull #失败了，并未pull下来开发/帮忙写的代码，是因为开发2没有指定本地feature-2分支与远程 origin/featnre-2分支的链接。

git branch--set-upstream -to=origin/freature-2 fenture-2

(5)各自开发完毕后，需要合并到master才算完成

(6)开发2开始merge.

git checkout master

git pull #保证本地masler是最新的内容.

git checkout feature-2 #切到 feature-2分支合并master

git merger master #无冲突就继续

git checkout master

git merge feature-2

git push origin master #将本地master推到远程

(7)开发者1同理，完成后featnre-1可直接在远程仓库删除

4、解决方法

远程分支删除后，本地git branch -a仍能看到的解决方法

git remote show origin #查看remote 地址远程分支，还有本地分支与之相对应关系等

git remote prune origin #删除远程仓库不存在的分支

二、企业级开发模型

1、DevOps背景

一个软件从0开始到最终交付，大概包括以下几个阶段：规划编码、构建、测试、发布、部署和维护软开测运维但在传统的IT组织下，开发团队(Dev)和运维团队(Ops)之间的诉求不同，双方利益冲突，不利于实现IT价值的最大化

开发团队：追求变化

运维团队：追求稳定

2、DevOps是什么

（1）为了保障开发和运维之间的鸿沟，需要在文化工具和实践方面的系统变革——DevOps就出现了

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

3、DevOps与git的关系

一个软件的迭代，在我们开发人员看来，说白了就是对代码进行迭代，那么就需要对代码进行管理。如何管理我们的代码呢，那不就是git(分布式版本控制系统)——所以git对于我们开发人员来说其重要性就不言而喻了。著名的gitee码云就是一种DevOps平台

4、系统开发环境

（1）开发环境：开发环境是程序员专门用于日常开发的服务器。为了开发调试方便，一般打开全部错误报告和测试工具是最基础的环境

（2）测试环境：一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上，该环境是开发环境到生产环境的过渡环境

（3）预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测而设立的一套环境。其配置等基本和生产环境一致，目的是能让我们发正式环境更有把握

（4）生产环境：是指正式提供对外服务的线上环境

5、Git分支设计规范

（1)

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