git 使用流程规范（merge-request)

git 使用流程规范（merge-request)

若是你的git workflow 采用此模式，谨记必定要忘记 git merge,除了在 master 分支上 git pull 可使用 git pull，其余分支若是要 git pull应该使用 git pull --rebase
使用 git rebase 的黄金法则就是：分支的开发者尽可能是一我的，重写提交历史不会影响别人

1. 新建分支

   # 建立分以前，先切换到 master 分支，更新到最新版本，确保你的新分支是基于最新版本的master
   # 在 master 分支上基本上只有一个操做 git pull
   git checkout master
   git pull
   # 建立分支 git checkout 命令是切换分支，加上参数 -b 表示若是分支不存在，就建立，且当即切换到新建立的分支
   git checkout -b myfeature

2. 分支开发

   # 添加工做区改变的文件到暂存区，尽可能git add file1 file2, 不提倡 git add *
   git add *
   # 查看当前工做区的状态
   git status
   # 把暂存区内容放入版本库,加上 verbose 参数的话会对变化比较且显示
   git commit --verbose

3. 撰写提交信息

   git 提交的信息很是重要
   第一行是信息摘要50字之内

   空一行，
   第三行罗列出改天缘由，主要变更，注意事项
   切记提交有意义的 commit message

4. 与主干同步

   # 拉取远端仓库全部变动内容到本地仓库
   # 注意和 git pull 的区别，git pull=git fetch + git merge(rebase)
   git fetch origin

   假设分支 myfeature 是几我的共同开发，这个时候 须要执行

   # 此操做可能会产生冲突，且解决完以后 push 的时候，可能要加上 --force 参数强制推送代码，改变提交历史记录，慎用
   git pull --rebase

5. 合并 commit
   此处的操做是最复杂的

   #rebase 命令和 merge 相仿,-i参数表示交互模式
   git rebase -i origin/master

   使用交互模式，能够合并同一个分支里面的多个 commit 为一个或者多个，能灵活控制 commit。
   当执行 rebase 发生冲突的时候，先解决冲突文件，使用git add 标志全部冲突为已经解决。 最后 git rebase --continue 完成 rebase 流程

6. 推送代码到远端

   # push 命令加上 --force 参数，由于 rebase 以后，分支历史改变，跟远程分支不必定兼容
   # 
   git push -u origin myfeature

7. 请求代码合并 merge-request