集中式工作流
image.png
集中式工作流以中央仓库作为所有项目所有修改的单点实体，也就是说改工作流只有master一个分支，所有的修改提交到这个分支上。
步骤：
-
首先假设中央仓库已将建好地址是ssh://user@host/path/to/repo.git，开发团队的所有人clone一份
git clone ssh://user@host/path/to/repo.git -
假设小明在自己的工作目录修改增加文件，跟踪文件，提交
git status # 查看本地仓库的修改状态 git add # 暂存文件 git commit # 提交文件 -
小明的开发完成了，推送到中央仓库
git push origin master
由于中央仓库自从小明克隆以来还没有被更新过，所以push操作不会有冲突，成功完成。
-
小红在之后也完成了自己的开发，需要推送到中央仓库
git push origin master但是由于小红的本地仓库历史已将和中央仓库有了分歧，所以会报错，git拒绝推送
-
这时小红要解决冲突，她要先pull小明的更新到她的本地仓库合并上她的本地修改后，再重试。
git pull --rebase origin master git push origin master--rebase选项告诉Git把小红的提交移到同步了中央仓库修改后的master分支的顶部，如下图所示：
image.png
-
如果小红和小明开发的是不同的功能，不大可能在rebase的时候冲突，若果有Git在合并有冲突的提交处暂停rebase过程，输出下面的信息并带上相关的指令：
CONFLICT (content): Merge conflict in
然后小红用 git status 来查看哪里有问题，查看unmergeed paths
接着小红修改这些文件的冲突，重新提交git status //小红 fix conflics git add somefile git rebase --continue git push origin master
要做的就这些了。Git会继续一个一个地合并后面的提交，如其它的提交有冲突就重复这个过程。
如果你碰到了冲突，但发现搞不定，不要惊慌。只要执行下面这条命令，就可以回到你执行git pull --rebase命令前的样子：
`git rebase --abort`
### 功能分支工作流
* 功能分支工作流的核心是所有的功能开发应该有一个单独的分支，而不是在master分支上
* 功能分支工作流和集中式工作流一样都使用中央仓库，并且master分支还是代表了正式项目的历史，但不是提交本地历史到master上而是开发者每次在开发一个新的功能时都新建一个分支，在这个分支上开发新功能。
* 在master分支和功能分支之间，Git是没有技术上的区别，所以开发者可以用和集中式工作流中完全一样的方式编辑. 暂存和提交修改到功能分支上。
#### 步骤：
1. 开发人员小红开发一个新功能 new-feature
```
git pull origin master
git checkout -b new-feature
git status
git add
git commit
git push -u origin new-feature
```
然后小红没有merge到 master的权限，所以小红发了一个pull request 到给项组的大家一起review 代码，提出评论或修改建议，
2. 要再做修改，小红用和功能第一个迭代完全一样的过程。编辑. 暂存. 提交并push更新到中央仓库。小红这些活动都会显示在Pull Request上，小黑（项目组长）和其他项目人员可以断续做评注。
如果小黑有需要，也可以把marys-feature分支拉到本地，自己来修改，他加的提交也会一样显示在Pull Request上
3. 一旦大家讨论同意了发布这个功能后，项目组长小黑可以的接受Pull Request，就可以合并功能到稳定项目代码中
```
git checkout master
git pull
git pull origin marys-feature
git push
```
7. 与此同时，小明在做和小红一样的事
当小红和小黑在marys-feature上工作并讨论她的Pull Request的时候，小明在自己的功能分支上做完全一样的事。
网友评论