多人协作

模拟配置多人协作环境

• 基本完成 Git 的所有本地库的相关操作，git基本操作，分支理解，版本回退，冲突解决等等
• 申请 gitee/github 账号，将远端信息克隆（clone）到本地，以及推送和拉取

但是这些都是个人的操作，我们如何去实现多人协作开发呢？我们来使用在Linux 系统和Windows系统下的本地仓库来模拟实现多人协作开发

我们来做一个简单的小实验

为了模拟实现多人协作开发，我们需要先做⼀些准备工作：

1. 我们之前已经将项目仓库克隆（clone）到了Windows系统下，我们再在 Linux 环境下，再克隆（clone） 同⼀个项目仓库，来模拟和我们⼀起协作开发的另⼀名同事

在 Linux 环境下，再克隆（clone） 同一个项目仓库

​​​​​​​

我们在拉取（pull）后使用 git branch 查看所有分支，但是发现查找不到拉取（pull）下来的分支 dev

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

git branch    // 只能查看本地分支git branch -r    // 远端git branch -a    // 本地 + 远端

现在我们只是把远程仓库拉取到了到了本地，但是我们本地还没有分支，接下来我们还需要做两个事：

1. 创建一个本地分支 dev
2. 并且使用本地分支 dev 和 远程分支 dev 关联

git checkout -b dev origin/dev 和 git checkout -b dev 有啥区别 

1. git checkout -b dev
   • 创建本地分支 + 切换到该分支 
   • 没有指定远程分支与之关联，新创建的dev分支只是一个独立的本地分支，它的初始内容和创建它时所在分支（如master）的内容相同。如果后续需要和远程仓库的某个分支进行关联和同步，需要额外的配置步骤，比如通过git branch -u origin/dev来设置dev分支跟踪远程仓库的dev分支。
2. git checkout -b dev origin/dev
   • 创建本地分支 + 切换到该分支 + 连接远程仓库
   • 但是，它会让新创建的dev分支跟踪远程仓库（通常origin代表远程仓库）中的dev分支。也就是说，新分支dev的起点是远程仓库origin中的dev分支的当前状态。
   • 这样在后续开发过程中，你可以方便地使用git pull从远程dev分支拉取更新到本地dev分支，也可以使用git push将本地dev分支的修改推送到远程dev分支，使得本地和远程分支的协作更加方便和紧密，一开始就建立了本地分支和远程分支之间的关联关系。

Windows：

多人同一分支开发

1. 在Linux系统下，我们在 dev 分支上进行⼀次开发，并推送（push）到远程仓库
2. 查看 Gitee/GitHub 上远程仓库的状态
3. 在Windows系统下，也要在 dev 分支上进行⼀次开发，并试图推送

 在Linux系统下，我们在 dev 分支上进行⼀次开发，并推送（push）到远程仓库

查看 Gitee/GitHub 上远程仓库的状态

 在Windows系统下，也要在 dev 分支上进行⼀次开发，并试图推送，这时推送失败

1. 拉取（ git pull） 把最新的提交从 origin/dev 抓下来
2. 在Windows系统下本地进行合并，并解决冲突，再推送

我们发现文件内提示了冲突 

 我们去解决冲突，重新推送（push）

查看远端仓库的 Gitee/GitHub 已经能看到我们的新提交了！ 

1. 拉取（git pull）
2. 推送（add/commit/push） ，遇到了冲突，就解决掉冲突
3. 要想看到别人的代码，只需要拉取（git pull）⼀下即可

1. 在Linux系统下，切换到  master分支, 拉取（git pull） ⼀下，保证本地的主分支（master） 是最新内容
2. 切换到 dev 分支 , 并且 合并 master 分支，这么做是因为如果有冲突，可以在dev 分支上进行处理，而不是在主分支（master）上解决冲突
3. 切换回到 master 分支 ，合并 dev 分支
4. 将 master 分支推送到远端仓库

切换回到 master 分支 ，合并 dev 分支

将 master 分支推送到远端仓库

查看 Gitee/GitHub 远端仓库，master已经是最新代码了 

此时，dev 分支对于我们来说就没用了， 那么 dev 分支就可以被删除掉。我们可以直接在远程仓库中将dev分支删除掉

总结

1. 在dev 分支下，可以试图推送自己的修改 （git push origin 分支名）
2. 如果推送失败，则因为远程dev分支比你的本地更新，需要先拉取（git pull）试图合并
3. 如果合并有冲突，则解决冲突，并在本地提交
4. 没有冲突或者解决掉冲突后，再推送自己的修改（git push origin 分支名）
5. 功能开发完毕，将dev分支 merge 进 master，最后删除dev分支

多人不同分支开发

• ⼀般情况下，如果有多需求需要多人同时进行开发，是不会在⼀个分支上进行多人开发，而是⼀个需求或⼀个功能点就要创建⼀个 feature 分支
• 现在同时有两个需求需要我们在Linux 和 Window下开发，那么你们俩便可以各自创建⼀个分支来完成自己的工作。
• 我们可以从 Gitee/GitHub 上直接创建远程分支，其实在本地创建的分支也可以通过推送的方法发送到远端仓库

 在 Linux 环境下

1. 新增本地分支 feature-1 并切换
2. 新增需求内容，创建 function1文件​​​​​​​​​​​​​​
3. 将 feature-1 分支 推送到远端

在 Windows 环境下 

1. 新增本地分支 feature-2 并切换
2. 新增需求内容，创建 function2文件​​​​​​​​​​​​​​
3. 将 feature-2 分支 推送到远端

查看远程仓库

 此时，在本地，Linux 环境 看不见Windows 环境 新建的文档，Windows 环境 看不见 Linux 环境 新建的文档。并且推送各自的分支时，并没有任何冲突，互不影响，用起来起来很舒服

正常情况下，我们就可以在自己的分支上进行专业的开发了！

但天有不测风云， Windows 环境下开发的 突然⽣病了，但需求还没开发完，需要你帮他继续开发，于是他便把 feature-2 分支名告诉你了。这时你就需要在自己的机器上切换到 feature-2 分支帮忙继续开发，要做的操作如下

1. 在Linux 环境 下，先拉取（git pull）远端仓库内容，可以看到远程已经有了feature-2
2. 切换到  feature-2 分支 上，可以和远程的feature-2 分支关联起来，（否则将来推送（git push）内容会失败）
3. 此时便可以 继续开发了

 此时我们便可以继续开发了

查看远程仓库

Windows 环境下开发的生病好了，那我们如何在window系统下继续开发或者查看

git branch --set-upstream-to=origin/feature-2 feature-2

各自功能（function1 和 function2）开发完毕后，我们需要将代码合并到 主分支（master）中才算真正意义上的开发完毕 

在Windows系统下进行合并到远程仓库的主分支（master）：

1. 切换到  master分支, 拉取（git pull） ⼀下，保证本地的主分支（master） 是最新内容
2. 切换到 feature-2 分支 , 并且 合并 master 分支，这么做是因为如果有冲突，可以在 feature-2 分支上进行处理，而不是在主分支（master）上解决冲突
3. 切换回到 master 分支 ，合并 feature-2 分支
4. 将 master 分支推送到远端仓库

查看远程仓库

 在 Linux 系统下进行合并到远程仓库的主分支（master）：

1. 切换到 master分支, 拉取（git pull）⼀下，保证本地的主分支（master）是最新内容
2. 切换到 feature-1 分支, 并且合并 master 分支，这么做是因为如果有冲突，可以在feature-1 分支上进行处理，而不是在主分支（master）上解决冲突
3. 由于feature-1 分支已经合并（merge）进来了新内容，如果合并（merge）出现冲突，不要忘记需要 commit 才可以 push，为了保证远程 feature-1分支最新，所以最好推送（push）⼀下​​​​​​​​​​​​​​
4. 要推送（push）的另⼀个原因是因为在实际的开发中，master的合并（merge）操作⼀般不是由我们自己在本地进行的，其他人员或某些平台merge时，操作的肯定是远程分支，所以就要保证远程分支的最新。
5. 切换回到 master 分支，合并feature-1 分支
6. 将 master 分支推送到远端仓库

查看 Gitee/GitHub 远程仓库

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

远程分支删除后的问题

git remote show origin

git remote prune origin

企业级开发模型

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

最初，程序比较简单，工作量不大，程序员一个人可以完成所有阶段的工作。但随着软件产业的日益发展壮大，软件的规模也在逐渐变得庞大。软件的复杂度不断攀升，一个人已经管理不住了，就开始出现了精细化分工。如下图：

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

系统开发环境

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

这四个环境也可以说是系统开发的三个重要阶段：开发->测试->上线，如图：
 

对于规模稍微大点的公司来说，可不止这么四个环境，比如项目正式上线前还存在 仿真/灰度环境，再比如还存在多套测试环境，以满足不同版本上线前测试的需要。

分支设计规范

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

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

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

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 分支。以 feature/ 开头，建议的命名规则： feature/user_createtime_feature （用户+创建时间+功能）
2. 新特性或新功能开发完成后，开发人员需合到 develop 分支。
3. ⼀旦该需求发布上线，便将其删除。

hotfix 分支

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

总结 

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