目次
多人协作一
1.要完成的任务
2.预备操纵
3.用户的开发操纵
4.merge操纵
多人协作二
1.要完成的任务
2.用户的开发操纵
3.merge操纵
4.办理远程分⽀删除后，本地git branch -a 依然能看到的问题
企业级开发模型
1.了解一些知识
2.系统开发环境
3.Git分⽀设计规范
多人协作一
1.要完成的任务
目标:在master分支下的file.txt文件中新增"aaa" 和 "bbb"
实现:由开发者1新增"aaa",开发者二新增"bbb"
条件:在同一个分支下协作完成
2.预备操纵
在这里我们在Linux中模拟用户1开发，在windows中模拟用户2开发，分别将远端仓库举行git clone操纵举行预备操纵，对于Linux中的操纵在前面已经先容了，这里重点先容用户2的开发环境
在windows中选择一个目次，右击鼠标
再执行 git clone命令
如许在目次中就会将远程仓库克隆到当前目次，在这个目次用终端中打开来模拟用户2的开发操纵
但在实际开发中，每个⽤⼾都有⾃⼰的gitee/github账号，如果要多⼈进⾏协同开发，必须要将⽤⼾添加进开发者，⽤⼾才有权限进⾏代码提交：
此时我们的仓库是只有一个master分支的，在实际开发中为了维护master分支的稳定性，是不能直接对master分支举行操纵的，因此我们还需要新建一个分支来供我们的开发需求
创建乐成的远程分⽀是可以通过Git拉取到本地来，以实现完成本地开发⼯作
3.用户的开发操纵
用户1的开发操纵
用户2的开发操纵
当举行push操纵时，会发现有报错，这是因为用户1和用户2的两次提交都是在file.txt文件中举行的，对这一个文件举行两次提交的话，此时就会发生辩论，git拒绝了推送操纵，办理办法就是先⽤ git pull 把最新的提交从 origin/dev 抓下来，然后，在本地进⾏合并，并办理辩论，再推送
整个过程的简图分析
4.merge操纵
对于merge操纵是有两种的，一种是通过填写Pull Requests 合并申请单的方式来合并
这种方式是要通过考核员考核的，具有保证性的
第二种就是在本地通过命令的方式来举行合并
详细操纵为:
最后删除dev分支
在同⼀分⽀下进⾏多⼈协作的⼯作模式通常是如许：
• ⾸先，可以试图⽤git push origin branch-name推送⾃⼰的修改；
• 如果推送失败，则因为远程分⽀⽐你的本地更新，需要先⽤ git pull试图合并；
• 如果合并有辩论，则办理辩论，并在本地提交；
• 没有辩论大概办理掉辩论后，再⽤git push origin branch-name推送就能乐成！
• 功能开发完毕，将分⽀ merge 进 master，最后删除分⽀
多人协作二
1.要完成的任务
目标:远程master分支下新增function1和function 2文件
实现:有开发者1新增function 1文件，开发者2新增function 2文件
条件:在差别分支下协作完成，让某一个功能各自私有一个分支
2.用户的开发操纵
用户1的开发操纵
用户2的开发操纵
但此时在用户2开发的过程中因一些原因不能继续完成开发的，将开发内容交给你，让你去资助完成开发于是他便把feature-2分⽀名告诉你了。这时你就需要在⾃⼰的机器上切换到 feature-2 分⽀帮忙继续开发，要做的操纵有:
这里说明下直接使用git pull 操纵的注意事项
1.若直接拉取的是某个分支下文件的内容，必须和远程创建链接
2.若直接拉取的是仓库的内容，在git clone时就已经创建好链接了，直接使用就行
3.创建链接的操纵(Linux): git checkout -b [新建分支名] [远端已经存在的分支]
如: git checkout -b dev origin/dev
4.创建链接操纵(Windows): git branch --set-upstream-to=origin/分支名 新建分支名
如:git branch --set-upstream-to=origin/dev dev
如果用户2返来后想接手，继续完成开发的话，需要的操纵
3.merge操纵
让master分支合并feature-1分支和feature-2分支
对于这里用户2开发完成的feature-2分支可以使用填写Pull Requests申请单的方式举行合并，上面的merge操纵时已经先容过了
对于用户1开发完成的feature-1分支如果直接合并到master分支的话，可能会发生辩论，影响master分支的稳定，因此可以在本地先让feature-1分支合并master分支，再push到远端仓库，用Pull Requests的方式让master分支合并feature-1分支,也可以在feature-1分支合并master分支后，切换到master分支，合并feature-1分支，再举行push操纵，最后删除两个分支
用户1所要做的操纵
一些注意:
1、由于feature-1分⽀已经merge进来了新内容，为了保证远程分⽀最新，所以最好push⼀下。
2、要 push 的另⼀个原因是因为在实际的开发中，master的merge操纵⼀般不是由我们⾃⼰在本 地进其他⼈员或某些平台merge时，操纵的肯定是远程分⽀，所以就要保证远程分⽀的最新。
3、如果 merge 出现辩论，不要忘记需要commit才可以push!!
4.办理远程分⽀删除后，本地git branch -a 依然能看到的问题
使用git remote prune origin 后，再查看分支的话，就查看不到了，最后在在本地删除本地分支
企业级开发模型
1.了解一些知识
⼀个软件从零开始到终极交付，⼤概包括以下⼏个阶段：规划、编码、构建、测试、发
布、部署和维护。
最初，程序⽐较简单，⼯作量不⼤，程序员⼀个⼈可以完玉成部阶段的⼯作。但随着软件产业的⽇益发展壮⼤，软件的规模也在渐渐变得庞⼤。软件的复杂度不断攀升，⼀个⼈已经hold不住了，就开始出现了精细化分⼯。如下图所⽰：
但在传统的?IT?构造下，开发团队(Dev)和运维团队(Ops)之间诉求差别：
• 开发团队(尤其是敏捷团队)追求变革
• 运维团队追求稳定
双⽅每每存在利益的辩论。⽐如，精益和敏捷的团队把持续交付作为⽬标，⽽运维团队则为了线上的稳定⽽夸大变更控制。部⻔墙由此建⽴起来,这固然不利于IT价值的最⼤化。为了弥合开发和运维之间的鸿沟，需要在⽂化、⼯具和实践⽅⾯的系列变⾰⸺DevOps正式登上舞台。
DevOps（Development和Operations的组合词）是⼀种重视“软件开发⼈员（Dev）”和“IT运维技
术⼈员（Ops）”之间沟通合作的⽂化、运动或惯例。透过⾃动化“软件交付”和“架构变更”的流
程，来使得构建、测试、发布软件可以大概更加地快捷、频繁和可靠。在DevOps的软件开发过程包罗筹划、编码、构建、测试、预发布、发布、运维、监控，由此可⻅DevOps的强⼤。
讲了这么多，这个到底和Git有什么关系呢
举⼀个很简单的例⼦就能说明这个问题。⼀个软件的迭代，在我们开发⼈员看来，说⽩了就是对代码进⾏迭代，那么就需要对代码进⾏管理。如何管理我们的代码呢，那不就是Git（分布式版本控制系统）！所以Git对于我们开发⼈员来说其重要性就不⾔⽽喻了
2.系统开发环境
对于开发⼈员来说，在系统开发过程中最常⽤的⼏个环境必须要了解⼀下：
1. 开发环境：开发环境是程序猿们专⻔⽤于⽇常开发的服务器。为了开发调试⽅便，⼀般打开全部错误陈诉和测试⼯具，是最基础的环境。
2. 测试环境：⼀个程序在测试环境⼯作不正常，那么肯定不能把它发布到⽣产机上。该环境是开发环境到⽣产环境的过渡环境。
3. 预发布环境：该环境是为制止因测试环境和线上环境的差别等带来的缺陷漏测⽽设⽴的⼀套环境。其配置等基本和⽣产环境⼀致，⽬的是能让我们发正式环境时更有把握！所以预发布环境是你的产物格量最后⼀道防线，因为下⼀步你的项⽬就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内，为单独的⼀些机器。
4. ⽣产环境：是指正式提供对外服务的线上环境，例如我们⽬前在移动端或PC端能访问到的APP都是⽣产环境。
这⼏个环境也可以说是系统开发的三个重要阶段：开发->测试->上线
对于规模轻微⼤点的公司来说，可不⽌这么⼏个环境，⽐如项⽬正式上线前还存在仿真/灰度环境，再⽐如还存在多套测试环境，以满⾜差别版本上线前测试的需要
3.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 分⽀为线上bug修复分⽀或叫补丁分⽀，重要⽤于对线上的版本进⾏bug修复。当线上
出现紧急问题需要⻢上修复时，需要基于 master 分⽀创建 hotfix 分⽀。
• 定名以 hotfix/ 开头，发起的定名规则:hotfix/user_createtime_hotfix
• 当问题修复完成后，需要合并到 master 分⽀和 develop 分⽀并推送远程。⼀旦修复上线，便
将其删除。
以上讲解的是企业级常⽤的⼀种Git分⽀设计规范：Git Flow模型
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
