一、集中式工作流

有两个开发者小明和小红，看他们是如何开发自己的功能并用git工作流来协作的

有人先初始化好中央仓库

所有人克隆(fork)中央仓库

下一步，各个开发者通过git clone命令创建整个项目的本地拷贝

小明开发功能

在小明的本地仓库中，他使用标准的Git过程开发功能：编辑、暂存（Stage）和提交。

git status # 查看本地仓库的修改状态
git add # 暂存文件
git commit # 提交文件
git diff #查看本地的所有修改
git checkout file/. ##撤销文件更改

这些命令生成的是本地提交，小明可以按自己需求反复操作多次，而不用担心中央仓库上有了什么操作。

小红开发功能

与此同时，小红在自己的本地仓库中用相同的编辑、暂存和提交过程开发功能。和小明一样，她也不关心中央仓库有没有新提交； 当然更不关心小明在他的本地仓库中的操作，因为所有本地仓库都是私有的。

小明发布功能

一旦小明完成了他的功能开发，会发布他的本地提交到中央仓库中，这样其它团队成员可以看到他的修改。他可以用下面的[git push命令]：
git push origin master

注意，origin是在小明克隆仓库时Git创建的远程中央仓库别名。master参数告诉Git推送的分支。 由于中央仓库自从小明克隆以来还没有被更新过，所以push操作不会有冲突，成功完成。

小红试着发布功能

一起来看看在小明发布修改后，小红push修改会怎么样？她使用完全一样的push
命令：
git push origin master

但她的本地历史已经和中央仓库有分岐了，Git拒绝操作并给出下面很长的出错消息：

error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

这避免了小红覆写正式的提交。她要先pull小明的更新到她的本地仓库合并上她的本地修改后，再重试。

小红在小明的提交之上rebase

小红用[git pull]合并上游的修改到自己的仓库中。 ——拉取所有上游提交命令到小红的本地仓库，并尝试和她的本地修改合并：
git pull --rebase origin master

--rebase选项告诉Git把小红的提交移到同步了中央仓库修改后的master分支的顶部，如下图所示：

如果你忘加了这个选项，pull操作仍然可以完成，但每次pull操作要同步中央仓库中别人修改时，提交历史会以一个多余的『合并提交』结尾。 对于集中式工作流，最好是使用rebase而不是生成一个合并提交。

小红解决合并冲突

rebase操作过程是把本地提交一次一个地迁移到更新了的中央仓库master分支之上。 这意味着可能要解决在迁移某个提交时出现的合并冲突，而不是解决包含了所有提交的大型合并时所出现的冲突。 这样的方式让你尽可能保持每个提交的聚焦和项目历史的整洁。反过来，简化了哪里引入Bug的分析，如果有必要，回滚修改也可以做到对项目影响最小。

如果小红和小明的功能是不相关的，不大可能在rebase过程中有冲突。如果有，Git
在合并有冲突的提交处暂停rebase过程，输出下面的信息并带上相关的指令：

CONFLICT (content): Merge conflict in <some-file>

Git很赞的一点是，任何人可以解决他自己的冲突。在这个例子中，小红可以简单的运行[git status]命令来查看哪里有问题。 冲突文件列在Unmerged paths（未合并路径）一节中：

Unmerged paths:
(use "git reset HEAD <some-file>..." to unstage)
(use "git add/rm <some-file>..." as appropriate to mark resolution)

both modified: <some-file>

接着小红编辑这些文件。修改完成后，用老套路暂存这些文件，并让[git rebase
]完成剩下的事：
git add <some-file> git rebase --continue

要做的就这些了。Git会继续一个一个地合并后面的提交，如其它的提交有冲突就重复这个过程。
如果你碰到了冲突，但发现搞不定，不要惊慌。只要执行下面这条命令，就可以回到你执行[git pull --rebase]命令前的样子：
git rebase --abort

小红成功发布功能

小红完成和中央仓库的同步后，就能成功发布她的修改了：
git push origin master

更多请查看my-git