分支名规范: feature[fixbug]-功能名[修复bug的名，只能是英文]
增加功能的分支名feature-开头
修改bug的分支名fixbug-开头
说明: 修复bug，新增功能的操作 也是一样的，只是分支名规范而已。
操作口头决:
a切换分支
先提交本地所修改的并且更新到远程分支,
b新建分支(修改bug/新增功能)，
切换主master分支[注意 需步骤a]，拉取master最新代码，从master创建分支新的分支
c分支提交给测试前 【或者正式上线】
切换要被测的分支[注意 需步骤a]
拉取要被测的远程分支最新代码 【修改冲突】
拉取master最新的代码 【修改冲突】
修复冲突后，提交到远程分支
案例1. 增加一个新的功能叫 登录
git checkout master #切换master主分支
git pull origin master #拉取master最新的代码
git checkout -b feature-login #创建一个 feature-login分支 该分支主要是 登录功能
案例2. 增加一个新的功能叫 注册
git branch #查看下当前我所在的分支，由于上面我 checkout -b 创建并切换到 新的分支feature-login
#现在我为了不让 登录和注册功能 混淆，因此，我需要先把本地 有关登录功能修改的代码 提交到本地/远程
git status #查看下 这个登录功能的分支 修改了哪些文件
git add . #选择所有修改的文件 注意这个. 点，是提交所有修改的文件，有时候你并不想把所有文件都提交，所以这里要注意
git commit -m "这些修改的文件 做的是 登录功能" #这里备注说明，这些被选择的文件是干嘛的, 并且提交到本地仓库
git pull origin feature-login #拉取 feature-login的最新代码
git push origin feature-login # 把本地修改的记录 都更新到远程分支上面[远程登录功能分支]
git checkout master #因为接下来我需要做新的功能 叫注册功能，所以先切换master[非常重要!!!!]
git checkout -b feature-register #新建并切换到 feature-register分支 [注册功能的分支]
....接着依次类推重复案例1
案例3. 功能做完了，就要去 跟测试人员说，你要测的是这个功能分支，如登录功能
git branch #查看我当前所处的分支，当前在 feature-register注册功能的分支
git status #查看当前所处的分支修改了什么问题件
git add . #选择修改的文件
git commit -m "注册功能" #给修改的文件备注 并提交到本地
git pull origin feature-register #拉取注册分支最新的代码
git push origin feature-register #把本地修改的代码 更新到远程分支上面
git checkout feature-login #切换登录功能的分支
git pull origin feature-login #拉取登录功能分支的最新代码
git pull origin master #拉取主分支master的代码
git push origin feature-login #把最新的代码 更新到远程分支上面
案例4.有时候执行git pull 时候，看到命令行说 某某某路径文件进行冲突
冲突的文件必须修复好，才能 提交到远程分支！！
打开冲突的文件，发现很多 ======等号，这时候跟同事反馈下 哪些代码要，哪些代码不能要
修改所有的冲突文件后，需要提交到远程分支
git branch #查看当前分支
git add . #选择 修改后的冲突文件
git commit -m "修改冲突" # 备注下这些文件的原因并提交到本地仓库
git push origin feature-login # 更新到远程分支
案例5. 测试的功能分支 已经测试完毕，并确定能上线, 如登录功能 可以上线了
原理[保持 当前测试分支 与主干master的分支 是一样的，所以每次上线时，都需要拉取master分支]
git checkout feature-login #切换登录功能的分支
git pull origin feature-login #拉取登录功能分支的最新代码
git pull origin master #拉取主分支master的代码
git push origin feature-login #把最新的代码 更新到远程分支上面