Git多人协作

使用windows和linux分别模拟开发者：

多人协作情况一

在windows环境下，模拟另外一个人来开发，将仓库clone下来

windows下：

Linux下：

在实际开发中，如果要多人进行协同开发，必须要将用户添加进开发者，用户才有权限进行代码提交

邀请用户：

现在相当于在我的linux机器上一个用户，windows上一个用户。

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

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

使用git branch -r来查看远程分支

但是到这一步的话还需要进行本地分支和远程分支的关系链接

git checkout -b dev origin/dev

拉取后便可以看到远程的 dev 分支，接着切换到 dev 分支供我们进行本地开发。

---

首先让linux机器上进行第一次开发，并且推送到远程

在码云上可以看到dev分支上已经有了记录了

那么同时在windows上也要进行开发，也要对file.txt文件进行修改，并push，就会提示冲突

解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后在本地进行合并，并解决冲突，再推送。

在解决后，重新push

在码云上就也可以看到了

所以两名开发者已经开始可以进行协同开发了，不断的git pull/add/commit/push。

最终的目的是要将开发后的代码合并到master上去，让我们的项目运行最新的代码。

---

在linux机器上进行拉去windows下写的代码，然后可以进行合并到master

切换至master分支, pull一下，保证本地的master是最新内容。

再次切换至dev分支, 合并master分支，这么做是因为如果有冲突，可以在dev分支上进行处理，而不是在master上解决冲突，要不然就乱了。

就可以看到master分支上就能看到file文件了

此时dev分支的任务就完成了，可以直接在远程仓库中的dev分支进行删除

在本地可以使用git branch -a来查看远程分支，发现还是有dev的

清除<font style="color:rgb(77, 77, 77);">remote</font>分支（清除 origin 已经不存在，但是<font style="color:rgb(77, 77, 77);">remote</font>还存在的分支）

git remote prune origin

那么我不想在远程上删除分支，可以使用下面命令进行删除远程分支

git push origin --delete [branchName]

或者这个

git push origin :[branchName]

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

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

多人协作情况二

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

在linux创建分支，再推送到远端

在windows创建分支，再推送到远端

此时，在本地，你看不见他新建的文档，他看不见你新建的文档。并且推送各自的分支时，并没有任何冲突，互不影响。

码云上就有那两个分支了，各个分支上有着自己管理的文件

如果windows上的机器突然坏了，不能进行开发了，就需要切换到linux机器上进行继续开发

可以看到就有windows上创建的分支了

然后切换到windows上创建的分支，与远程的feature-2进行关联起来，否则将来使用git push推送内容会失败

使用git branch -vv查看关联情况

git checkout -b feature-2 origin/feature-2

对windows机器上面写的代码继续进行开发

查看码云

这个时候，当windows机器修好后，那么windows机器就需要先拉去我开发的代码

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

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

目前，小伙伴的本地代码和远端保持严格一致。你和你的小伙伴可以继续在不同的分支下进行协同开发了。

各自功能开发完毕后，不要忘记我们需要将代码合并到master中才算真正意义上的开发完毕。由于你的小伙伴率先开发完毕，于是开始 merge ：

此时查看码云

那么我也可以将linux机器上开发的代码也合并到master分支上，进行推送到远端，步骤和上面一样

查看远端仓库

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

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

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

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

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

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

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 分支设计规范：Git Flow 模型