Git实战|协作开发|分支设计规范|Git实践

协作开发1

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

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

⽬前，我们的仓库中只有⼀个master主分⽀，但在实际的项⽬开发中，在任何情况下其实都是不允许直接在master分⽀上修改代码的，这是为了保证主分⽀的稳定。所以在开发新功能时，常常会新建其他分⽀，供开发时进⾏迭代使⽤。
那么接下来，就让我们在gitee上新建dev远程分⽀供我们使⽤：

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

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

在 dev 分⽀上进⾏⼀次开发，并 push 到远程

另一人要对file.txt⽂件作修改，并试图推送

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

解决冲突，重新推送

将所有内容合并进master

是在分⽀上进⾏多⼈协作开发，但最终的⽬的是要将开发后的代码合并到master上去，让我们的项⽬运⾏最新的代码
切换⾄ master分⽀, pull ⼀下，保证本地的master是最新内容
切换⾄ dev 分⽀, 合并 master 分⽀
这么做是因为如果有冲突，可以在dev分⽀上进⾏处理，⽽不是在在master上解决冲突。

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

将 master 分⽀推送⾄远端

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

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

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

协作开发2

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

新增本地分⽀ feature-1 并切换
新增需求内容-创建func1⽂件

将 feature-1 分⽀推送到远端

创建并切换到feature-2分支
新建func2文档
将feature-2分支推送到远端

此时，在本地，你看不⻅他新建的⽂档，他看不⻅你新建的⽂档。并且推送各⾃的分⽀时，并没有任何冲突

协作开发3

⼩伙伴突然⽣病了，但需求还没开发完，需要你帮他继续开发，于是他便把feature-2分⽀名告诉你了。这时你就需要在⾃⼰的机器上切换到feature-2分⽀帮忙继续开发

必须先拉取远端仓库内容

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

继续开发
推送内容

⼩伙伴可以继续进⾏⾃⼰的开发⼯作，那么他⾸先要获取到你帮他开发的内容，然后接着你的代码继续开发
Pull⽆效的原因是⼩伙伴没有指定本地feature-2分⽀与远程origin/feature-2分⽀的链接，根据提⽰，设置feature-2和origin/feature-2的链接即可

将内容合并至master

切换⾄ master分⽀, pull ⼀下，保证本地的master是最新内容

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

由于feature-1分⽀已经merge进来了新内容，为了保证远程分⽀最新，所以最好push⼀下。
要 push 的另⼀个原因是因为在实际的开发中，master的merge操作⼀般不是由我们⾃⼰在本地进⾏操作
其他⼈员或某些平台merge时，操作的肯定是远程分⽀，所以就要保证远程分⽀的最新
如果 merge 出现冲突，不要忘记需要commit才可以push

远程分支删除后，本地git branch -a依然能看到

当前我们已经删除了远程的⼏个分⽀，使⽤ git branch -a 命令可以查看所有本地分⽀和远程分⽀，但发现很多在远程仓库已经删除的分⽀在本地依然可以看到
使⽤命令 git remote show origin ，可以查看remote地址，远程分⽀，还有本地分⽀与之相
对应关系等信息

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

这样就删除了那些远程仓库不存在的分⽀

企业开发

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

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

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

系统开发环境

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

1. 开发环境：开发环境是程序猿们专⻔⽤于⽇常开发的服务器。为了开发调试⽅便，⼀般打开全部错误报告和测试⼯具，是最基础的环境。
2. 测试环境：⼀个程序在测试环境⼯作不正常，那么肯定不能把它发布到⽣产机上。该环境是开发环境到⽣产环境的过渡环境。
3. 预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测⽽设⽴的⼀套环境。其配置等基本和⽣产环境⼀致，⽬的是能让我们发正式环境时更有把握！所以预发布环境是你的产品质量最后⼀道防线，因为下⼀步你的项⽬就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内，为单独的⼀些机器。
4. ⽣产环境：是指正式提供对外服务的线上环境，例如我们⽬前在移动端或PC端能访问到的APP都是⽣产环境。
   这⼏个环境也可以说是系统开发的三个重要阶段：开发->测试->上线。
   

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

Git分⽀设计规范

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

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

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分⽀

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

Git分支设计

DevOps研发平台

Gitee 企业版 - 企业级 DevOps 研发效能平台

创建项目

创建仓库

基于git flow模型的实践

新需求加⼊

现有⼀个订单管理的新需求需要开发，⾸先可以基于 develop 分⽀创建⼀个feature分支

开发者在 feature 分⽀下发起请求评审

测试 release 通过后（包含测试环境和预发布环境的测试），就可将代码合并⼊master