add toc

git-workflows-and-tutorials/workflow-centralized.md

@@ -1,6 +1,20 @@
 集中式工作流
 =================================
 
+- [工作方式](#beer-工作方式)
+    - [冲突解决](#冲突解决)
+- [示例](#beer-示例)
+    - [有人先初始化好中央仓库](#有人先初始化好中央仓库)
+    - [所有人克隆中央仓库](#所有人克隆中央仓库)
+    - [小明开发功能](#小明开发功能)
+    - [小红开发功能](#小红开发功能)
+    - [小明发布功能](#小明发布功能)
+    - [小红试着发布功能](#小红试着发布功能)
+    - [小红在小明的提交之上`rebase`](#小红在小明的提交之上rebase)
+    - [小红解决合并冲突](#小红解决合并冲突)
+    - [小红成功发布功能](#小红成功发布功能)
+- [下一站](#beer-下一站)
+
 ![Git Workflows: SVN-style](images/git-workflow-svn.png)
 
 转到分布式版本控制系统看起来像个令人生畏的任务，但不改变已用的工作流你也可以用上`Git`带来的收益。团队可以用和`Subversion`完全不变的方式来开发项目。
@@ -22,8 +36,8 @@
 
 ![git-workflow-svn-push-local](images/git-workflow-svn-push-local.png)
 
-:beer: 冲突解决
----------------------
+### 冲突解决
+
 
 中央仓库代表了正式项目，所以提交历史应该被尊重且是稳定不变的。如果开发者本地的提交历史和中央仓库有分歧，`Git`会拒绝`push`提交否则会覆盖已经在中央库的正式提交。