Git 工作流 -- 集中式工作流

Git

https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md#21-%E9%9B%86%E4%B8%AD%E5%BC%8F%E5%B7%A5%E4%BD%9C%E6%B5%81

相比较SVN， Git集中式工作流有以下两个优势：
1. 每个开发者可以有自己的整个工程的本地拷贝
2. Git 提供了强壮的分支和合并模型

工作方式

本工作流只用到master一个分支。

1. 开发者clone中央仓库。在自己的项目拷贝中，像SVN一样的编辑文件和提交修改；但注意：修改是本地的。
2. 开发者将修改push到master分支中。

冲突解决

在开发者提交自己功能修改到中央库前，需要先fetch在中央库的新增提交，rebase自己提交到中央库提交历史之上。
如果本地修改和上游提交有冲突，Git会暂停rebase过程，给你手动解决冲突的机会。Git解决合并冲突，用和生成提交一样的git status和git add命令，很一致方便。还有一点，如果解决冲突时遇到麻烦，Git可以很简单中止整个rebase操作，重来一次。

举例

当有组员已经对中央仓库进行了修改，此时，如果我使用git push origin master 推送，那么Git会拒绝并报错，此时，我需要先pull 其他组员的更新到我的本地仓库并合并我的本地修改再进行git push。

此时可以通过命令：git pull --rebase origin master来进行拉取， --rebase 选项告诉Git把我的提交移到已经同步中央仓库master分支的顶部，如果不添加这个选项，pull依旧可以完成，但每次pull 后需要同步你的本地修改，使用一个merge操作。而对于集中式工作流，最好使用rebase而不是生成一个合并提交。

rebase 操作过程是把本地提交一次一个地迁移到更新了的中央仓库master分支之上。 如果组员和你的功能是不相关的，那么不大可能在rebase过程中有冲突。如果有，Git会在合并有冲突的提交处暂停rebase过程，并输出合并信息。

然后，我可以通过 git stasus来查看冲突，然后编辑冲突文件，然后就可以按照下面命令接着合并了：

git add some_file
git rebase --continue

如果冲突无法解决， 执行git rebase --abort 就能够回到 执行 git pull --rebase 命令前的样子。

最后，发布修改： git push origin master