大型项目中，多人协作开发和平常我们自己单人开发一个项目是不太一样的，为了保证线上环境的稳定性，也就是master分支上的代码是绝对不允许手动修改的，防止线上出现问题，而且生产环境dev分支的代码一般情况下也是不会去修改的，通常是从master分支上检出一个稳定的分支test，然后在这个本地分支test上进行功能的开发或者bug的修改，在开发完成之后再把本地分支test提交到远端分支test，然后在远端进行test分支和dev分支的合并，在合并完成之后，进行build操作（为了确保代码没有编译错误），然后再将dev分支的代码合并到master分支上，进行build，上线部署等操作。
接下来介绍一下这个过程中需要用到的一些git命令
首先确保你已经clone了远端仓库的代码，并处在某一个分支上
- 检出新分支并切换到该分支上
git checkout -b newBranch origin/master
或者
git branch 分支名称
git checkout 分支名称
或者简写：
git checkout -b 分支名称
2.建立本地分支到远端分支的映射关系
git pull <远程库名> <远程分支名>:<本地分支名>
例如：取回远程库中的online分支，与本地的online分支进行merge，要写成：
git pull origin online:online
如果是要与本地当前分支merge，则冒号后面的<本地分支名>可以不写
git pull origin online
通常，git会将本地库分支与远程分支之间建立一种追踪关系。比如，在git clone的时候，所有本地分支默认与远程库的同名分支建立追踪关系。也就是说，本地的master分支自动追踪origin/master分支。因此，如果当前处于本地online分支上，并且本地online分支与远程的online分支有追踪关系，那么远程的分支名可以省略：
比如，取回远程库中的online分支，与本地的online分支进行merge，要写成：
git pull origin
git pull 操作就可以从远程库中获取某个分支的更新，再与本地指定的分支进行自动merge(即使本地不存在这个分支) 其实，git pull 命令等同于先做了git fetch ，再做了git merge。即：
git fetch origin online
git checkout online
git merge origin/online
- 推送本地分支到远端 这个时候一般需要将本地分支推送到与其对应的远程仓库，也就是test远程分支(新建的)
git push --set-upstream origin <远程分支名>
git push -u origin <远程分支名>
在这之后本地的test分支就与远端的test分支建立了映射关系
可以通过git branch -vv命令查看本地分支和远程分支的映射关系
//本地dev4test分支映射关联远程仓库dev4test分支
git branch --set-upstream-to origin/dev4test dev4test
- 在远程仓库合并当前分支与dev分支
这一步骤一般在远端通过git工具进行操作，例如gitlab中的查看branchs，然后选择某个分支
merge request然后选择要合并的分支即可 还有一种方法就是在本地合并然后提交，不过这种方法需要操作master分支，具有一定的风险性，在大型项目中，为了项目的安全性，稳定性考虑一般不允许该种操作，具体操作方法如下 切换到master分支git checkout master，然后将test分支的代码合并到mastergit merge test，并在解决完冲突问题之后，git push origin master将master分支推到远端。
下面是常用的git命令
本地新建分支:git checkout -b dev-north-feature
将本地新建分支推送到远程仓库：git push origin dev-north-feature
*此时拉取远端git pull分支可能会报There is no tracking information for the current branch.表示当前branch没有跟踪信息
解决方法一：指定远程分支 git pull origin dev-north-feature
解决方法二：先指定本地分支到远程分支的映射 git branch --set-upstream-to=origin/dev-north- dev-north-，再拉取git pull
如果远程分支已存在，要新建本地分支关联到远程分支 git checkout -b release origin/release 也可以理解为拉取远程分支release到本地
删除本地分支：git branch -D dev-north-release-366825
删除远程仓库分支：git push origin --delete dev-north-release-366825
合并之前先拉取各个分支最新代码，使用git fetch命令
然后直接使用本地分支合并远程master代码 git rebase origin/master
或者
本地开发分支合master代码，使用git rebase master
git rebase --abort 会放弃合并，回到rebase操作之前的状态，之前的提交的不会丢弃；
git rebase --continue 合并冲突，结合"git add 文件"命令一起用与修复冲突，提示开发者，一步一步地有没有解决冲突。（fix conflicts and then run “git rebase --continue”）
正常操作流程是：
先把自己开发的代码git stash
然后git fetch 所有分支
然后git rebase origin/master
注意:在rebase master的时候，如果何本地当前代码有冲突，则分支会显示正在变基，需要在解决完冲突之后，在git rebase —continue，如果还有冲突，则继续解决，直到没有冲突
会提示你有哪些更改会被合到你的当前分支，然后:wq，退出，这个时候才算git rebase完毕，分支名称会显示回你的开发分支
然后git stash pop 把自己的开发代码pop到当前分支中，如果有冲突则解决
然后可以继续开发，或者提交MR
git在不commit的情况下切换分支修改其他内容（git stash）
在工作过程中，我们不时会遇到这类问题。在当前分支正在进行功能的开发，突然来了一个bug，要切换到其他分支修改。但是当前分支的改动还不适合提交。所以我们可以使用如下方法进行当前工作区的缓存:
在切换分支前我们可以使用git stash
如果此类需求较多，可以给stash加一个message（git stash save ‘message’），方便分辨这个stash是哪个需求的，在apply指定stash时，便于分辨
git stash # 将存储修改
git checkout master # 切换分支去解决
修改完之后，回到开发分支,执行
git checkout dev # 切换回开发分支
git stash list # 查看储存列表
有两个恢复的方法
方法一：
git stash apply # apply恢复后手动drop清除stash
git stash drop
$ git stash apply stash@{0} # 多个stash时,恢复指定stash需加上id， 如
方法二：
git stash pop # 恢复最近一次stash到栈中的内容到工作区，恢复后删除此stash
git stash pop stash@{0} # 同理 有多个存储时
git reset 回退到某次commit
git reset --mixed HEAD^ 回退到上个版本的提交，本地修改代码不变，工作区已add状态
git reset --soft HEAD^^ 回退到上两个版本的提交，本地修改代码不变，工作区未add状态
Git reset —hard commit-id 回退到指定版本的提交，代码变为该版本提交时的状态，本地其他修改代码丢失
同时撤销远程仓库的提交，在本地commit撤回之后，使用命令
git push origin HEAD --force
