git团队开发使用流程概述和注意点

重新温习了一下git，这篇文章主要总结一下使用git做开发的整体流程，所以不会做过多的git指令的详细说明。

整体流程

这里我在本地进行模拟，我希望模拟达到的效果是，一共有4个端。project是一个仓库，manager是项目负责人、zs和ls是开发人员，他们3个都参与项目，都是项目贡献者，分别在他们各自的电脑上进行开发，这是我本地的目录结构：

| project // 路径是   D:\桌面\project 
| zs      // 路径是   D:\桌面\zs 
| ls      // 路径是   D:\桌面\ls
| manager // 路径是   D:\桌面\manager 

首先manager创建这个项目，创建了一个project文件夹，然后使用git init --bare，创建一个裸仓库。然后manager返回自己的电脑（也就是上面提到的manager目录），执行git clone D:\桌面\project ，然后manager创建README.md文件，简单初始完毕master分支之后执行。

git add README.md
git commit -m '初始化项目，添加README文件'
git push
// 上面这两句就是简单初始化一个master分支然后push上去
git branch dev
git switch dev
// 上面这两句就是基与master分支创建dev分支，然后manager切换到dev去初始化项目框架啥的

manager在dev分支建立好框架之后告诉zs和ls，我项目初始化完毕了，你们拉取代码开发。这个时候zs和ls应该基与dev分支创建属于自己的分支。比如说zs这个人进入到自己的电脑（也就是上面提到的zs目录），进行一下的操作：

git clone D:\桌面\project // 这个时候默认本地只有master分支
git switch dev // 这句指令是切换到dev分支，因为本地没有dev分支，所以会看远程有没有，如果有，就会创建本地dev分支，并且拉取远程dev分支内容

git brnach zs // 这个时候是在dev分支创建的zs分支
git switch zs // 切换到zs这个分支，进行对应的代码开发

zs代码如果开发完毕了就可以执行

git push // 这个时候本地实在zs分支，所以这样就会pushdao远程的zs分支

ls这个人也会和zs有着相同的操作，就不赘述了。
如果zs和ls都开发完毕了。manager就可以把zs和ls分支的代码合并到dev了，manager再次进入到他的电脑，执行一下操作：

git switch zs // 切换到zs分支
git pull // 拉取zs分支的代码

git switch dev // 切换到dev分支
git merge zs // 那zs的代码合并到dev分支

git switch ls // 切换到ls分支
git pull // 拉取ls分支的代码

git switch dev // 切换到dev分支
git merge ls // 那ls的代码合并到dev分支

基本这样就ok了，然后进行测试，测试的话可能会有bug，bug修复的话，可以基与dev分支创建bugfix分支，然后再用dev分支去合并bugfix分支，bug修复完毕之后，切换进入master分支，基本master分支合并dev分支，master分支的代码就是线上环境的代码了。然后可以再master上打tag，相当于是一个里程碑：

git tag -a v0.1.0 -m '第一个版本' // 打标签
git tag // 查看标记
git push origin 'v1.0' // 把tag推送到远程服务器

当然可能还有一些其他的场景。

场景一

zs这个时候正在在他自己的分支上开发，但是manager告诉在dev分支上有一个bug，很紧急，必须停下手上现有的活去修复bug。这个时候你可能会想，很简单嘛。直接切换到dev分支，然后拉一下最新代码，在基与dev分支切出一个bugfix分支进行修复bug，开发完毕在切回dev，合并bugfix不就ok了吗？确实是这样，但是还有一个细节，当你切换到dev的时候，你在zs这个分支上可能还有一些代码仍在工作区或者暂缓区，那应该怎么把这些东西处理完毕呢？直接执行git commit吗？，感觉不是太好。我们可以先执行git add .，然后执行git stash

git stash // 将暂缓区的内容保存起来，方便我们切换分支做其他分支的事情（注意是暂缓区不是工作区）

然后修复完bug之后切回zs分支，执行git stash apply恢复之前的代码，继续开发

git stash pop // 会变更stash里面的栈
git stash apply // 不会变更stash里面的栈

场景二

manager在dev分支上合并zs分支，发现合并完毕之后有一些冲突，然后manager尝试解决这些冲突，但是发现有些冲突好像搞不定，需要zs自己搞，然后manager执行git merge --abort，也就是我不合并了，恢复合并zs这个分支之前的样子，然后通知zs，让他自己解决冲突，这个时候zs该如何操作呢？

zs切换到dev分支，然后拉取最新代码，然后再切换回zs分支，执行git merge dev，然后解决冲突完毕，在zs分支执行git push，然后通知manager冲突解决完毕了，现在可以合并zs分支了。然后manager切换到zs分支，拉取最新代码，然后再切回dev分支，然后基于dev分支，继续merge zs这个分支。