折腾了几天，看了无数大佬的文章，感觉终于对GitHub团队合作过程算是基本研就透了吧，本文就详细地总结一下我学到的东西吧，希望对大家有帮助。
在看本文时候，你应该是已经熟悉了git/github的一些基本操作了，如果没有的话，请先移步git简介。
项目管理员创建orgonization,repository。
我们首先需要在网页版的GitHub上创建一个组织，步骤如下：
简单的注册后就能看到组织的结构了
接着项目管理员创建一个仓库，刚创好的仓库是一个空仓库，如下
我们需要把本地的项目与刚创建的项目建立联系，在本地仓库的位置git bash使用命令：
git init
git add -A
git commit -m “first commit”
git remote add 远程仓库名（一般设置为origin，下文都用) 远程仓库的链接
git push -u origin master
说明
1.git add -A 提交所有的修改到缓存区，git add . 提交新文件和修改的文件到缓存区，git add -u 提交被修改，被删除的文件到缓存区。
2. 远程仓库名默认为origin,当然你也可以设置自己喜欢的名字。
3. git push -u origin master中的-u参数只用第一次推送时加上，后面可以直接省略。
4. 如果在github上创建仓库时自动加上了reademe.md文件，那么push是会出错的，解决方法，git pull --rebase origin master 将远程库合并到本地，再push上去就没有问题了。
5. 仓库链接会有两个，一个是https协议的，一个是ssh协议的，推荐使用ssh协议。https协议每次推送都必须输入口令。
创建好仓库后，一般团队开发时不会直接在master分支上干活，master分支只是用于保存稳定的线上版本，所以我们创建一个develop分支，这才是我们干活的地方，创建方法：
方法1.直接在远程仓库上创建develop分支,之后在本地使用
git fetch(拉取远程分支）
git checkout -b develop origin/develop. //利用远程origin仓库的develop分支在本地创建develop分支
方法2.本地仓库使用：
git checkout -b develop //创建本地分支develop
git push -u origin develop //推送本地develop分支到远程仓库，并在远程仓库创建develop
接着我们需要把我们的小伙伴拉近我们的项目中
在这里就可以通过小伙伴的github账号添加collaborator,并且设置权限。一般情况下如果不允许别人直接push修改远程仓库的话，可以将权限设置为read就行了。
团队成员进行开发
由于大多数时候我们都无法通过push直接修改远程项目中的代码，那我们又怎么提交我们的代码给管理者呢？这时候就要用到pull request,请求管理者将我们的修改合并到项目中去
首先我们需要fork一份项目到自己的github上，
之后在我们的仓库中就会出现这个项目了
接着我们就可以使用
git clone -b 要克隆的分支 fork的仓库的地址
或者是
git clone -b fork的仓库的地址 //默认只会把master分支拉下来
git checkout -b 要创建的本地分支名 远程分支名 //拉取远程仓库指定的分支到本地，并创建新的本地分支。
作为团队成员，一般情况下我们只用把develop分支拉下来就行了，注意一定要用fork的仓库的地址，否则是会出问题的。如果需要远程仓库的其他分支，可以使用：
git checkout -b 分支名 远程分支
如git checkout -b master origin/master,意思就是利用远程分支origin/master来创建本地分支master.
为了规范，我们也不会直接在develop分支上进行开发，而是通过创建feature分支来进行功能开发，在develop上输入
git checkout -b feature/A
这里的分支名可以根据自己的习惯命名，之后就是不停地修改
git add -A
git commit -m "信息“
当我们开发完功能后就需要合并到本地的develop分支上，并且上传到我们fork的远程仓库即
git switch develop //切换分支
git merge --no-ff feature/A //合并分支
git branch -d feature/A //删除分支
但这里我们会发现一个问题，如果管理员的项目有所更新，我们改如何同步自己的fork后的远程项目呢？其实很简单：
方法一：输入：
git remote add upstream 管理员的仓库地址 //upstream是给远程仓库命的名，可以自己修改，这句话是建立与远程库的链接。
git pull --rebase upstream develop //拉取管理员的仓库更新
方法二：GitHub网页上操作，不太推荐，可以自己百度百度。。。
所以上传时的总过程一般是：
git remote add upstream 管理员的仓库地址（仅第一次的时候用）
//合并分支
git switch develop //切换分支
git merge feature/A //合并分支
git branch -d feature/A //删除分支
//上传分支
git pull --rebase upstream develop //同步远程分支
git push origin develop
合并更新完develop后，如果有冲突就改，改完后add,commit,之后就可以上传到自己fork的远程仓库了（一定别上传错对象），origin是你fork的那个远程仓库的代称，而upstream是管理员仓库的代称
注意
1.这里解释一下为什么pull 的时候加上rebase参数，当远程仓库有其他团队成员提交了新的commit,这时候我们直接git pull的话，就会产生分叉
为了解决分叉的问题，我们可以直接pull的时候加上rebase参数，之后就只会有一条分支，我们提交的commit就会直接位于远端commit的后面
2.当我们使用git pull --rebase时如果遇到了冲突，我们需要进行如下的操作
更改代码解决冲突
git add -A(不用commit)
git rebase --continue
参考
git rebase 最通俗的解释
git rebase 使用
更新完fork的远程仓库后，就需要利用pull request 来向管理员请求合并了。步骤如下（好像不能用命令行）：
到自己fork的仓库下：
点击new pull request
红圈部分左边是你想要合并到的分支（管理员仓库的某一条分支），右边是你想要被合并的分支（fork的仓库的某条分支）。确认无误后填写信息点击create pull request,之后就是管理员的事了。
管理员会出现如下界面
管理员可以查看修改的内容，并且通过点击merge pull request 确认融合。就这样一次完整的pull request就完成了。同时，如果你可以在网页上查看修改的内容。
但是当修改内容很多时，在网页上看就不太方便了，可不可以拉到本地进行Code View了，当然是可以的，而且很简单，点击command line structions,然后按照提示，就可以实现在本地处理pull request了，如图：
参考
官方简介：Cheking out pull request locally
管理员合并develop到master
develop分支上积累的功能到一定的程度就要要合并到master分支上形成一个新的版本。这时一般由管理员输入（前提时develop已经是最新版本）
git switch master
git merge --no-ff develop
git tag -a 版本号 -m "版本信息”
git push origin master //管理员具有push的权限，所以无需pull request
git push origin 版本号tag //推送版本号tag
这样的话就完成了一次版本更替。
注意
1.git merge(默认为fast-forward模式）:如果develop分支包含了master分支所有的commit,则融合时,就会通过移动master分支到develop分支上,即将develop分支上所有多余的commit加在master分支上完成合并,只会生成一条分支。
2.git merge --no-ff:只会在master分支上生成一个记录merge的commit.
3.git merge --squash:将develop分支上的commit压缩为一次，不移动HEAD指针，此时修改已经完全移动到了master分支上了，但是还需要一次commit总结一下。
参考
git merge 简介
版本回退
假设远程仓库的master分支是1.0->2.0->3.0，但现在3.0版本有问题我们需要回到2.0，这时我们就需要使用：
git log //找到我们需要回退的版本号
git reset --hard <指定版本号>
这样做的话，如果我们直接push到远程仓库是会有问题的，因为远程仓库现在仍然是1.0->2.0->3.0,本地回退后，会丢掉3.0版本变成1.0->2.0,很明显是会有冲突的。解决方法有两个：
方法1
git push origin master --force //强制更换远程代码
方法2
不用git reset 而是使用：
git revert -n 版本号
git revert 的区别就是，该命令会重新创建一次commit用于撤销某个指定版本的修改。这样的话本地的提交就变成了1.0->2.0->3.0->git revert产生的一次新的commit。
这时就可以没有冲突的push到远程仓库了。但是版本回退对于整个团队来说是特别麻烦的，要协商好，不到万不得已，尽量不要版本回退。
参考
git revert 与 git reset的区别
git 撤销和回滚操作
GitFlow各分支讲解
gitflow是一种代码管理方案，下面是我举的实例：
1.进行功能开发(创建发布分支feature）
团队成员拉下代码后
git checkout -b feature/A develop //feature/A是创建的分支名，develop是用来作为基础的那条分支
do somethintg
git switch develop
git merge --no-ff feature/A //合并功能分支
git pull --rebase upstream develop //同步远程仓库
git push
git branch -d feature/A //删除分支
2.即将发布新版本时(创建release分支)
准备发布新版本的时候
git checkout -b release/1.0 develop
进行一些测试，清理和任何发布前的工作
//合并到master分支并上传
git switch master
git merge --no-ff release/1.0
git push
//合并到develop分支并上传
git switch develop
git merge --no-ff release/1.0
git push
git branch -d release/1.0 //删除分支
3.为新版本加上tag
每当master版本发生变化，都应加上相应的版本
git switch master
git tag -a 2.0 -m “完成feature/A” //-a tag名 -m 注释
git push origin tags //origin 代表你想推送的远程库名
4.修复已发行版本上的紧急bug(创建hotfix分支)
如果现在发行的1.0版本出现了紧急bug,这时就需要从master分支创建hotfix分支
git switch master
git checkout -b hotfix/1.0
修复bug
//合并到master分支，并推送新tag
git switch master
git merge --no-ff hotfix/1.0
git push
git tag 1.1
git push origin --tags
//合并到develop分支，并同步到远程
git switch develop
git merge --no-ff hotfix/1.0
git push
git branch -d hotfix/1.0
