From 4328a55eec8cf2cc11642198a2127194cf89d2ea Mon Sep 17 00:00:00 2001 From: Jerry Lee Date: Mon, 25 Aug 2014 22:17:11 +0800 Subject: [PATCH] add foot link for index; adjust translation term for centralized --- git-workflows-and-tutorials/README.md | 11 ++++++++--- git-workflows-and-tutorials/workflow-centralized.md | 8 ++++---- 2 files changed, 12 insertions(+), 7 deletions(-) diff --git a/git-workflows-and-tutorials/README.md b/git-workflows-and-tutorials/README.md index ab8f390..2009e36 100644 --- a/git-workflows-and-tutorials/README.md +++ b/git-workflows-and-tutorials/README.md @@ -12,9 +12,9 @@ :beer: 概述 --------------------- -### 中心化（Centralized）工作流 +### 集中式工作流 -如果你的开发团队成员已经很熟悉`Subversion`，中心化工作流让你无需去适应一个全新流程就可以用上`Git`带来的收益。这个工作流也是一个向更`Git`风格工作流迁移的友好过渡。 +如果你的开发团队成员已经很熟悉`Subversion`，集中式工作流让你无需去适应一个全新流程就可以用上`Git`带来的收益。这个工作流也是一个向更`Git`风格工作流迁移的友好过渡。 [了解更多 »](workflow-centralized.md) @@ -22,7 +22,7 @@ ### 功能分支（Feature Branch）工作流 -功能分支工作流以中心化工作流为基础，不同的是为各个新功能分配一个单独的分支来开发。这样可以在把新功能合并到正式主干前，用`Pull Requests`的方式讨论变更。 +功能分支工作流以集中式工作流为基础，不同的是为各个新功能分配一个单独的分支来开发。这样可以在把新功能合并到正式主干前，用`Pull Requests`的方式讨论变更。 [了解更多 »](workflow-feature-branch.md) @@ -45,3 +45,8 @@ `Pull requests`是`Bitbucket`让开发者更方便地进行协作的功能，提供了友好的Web界面可以在合并得提交的修改到官方项目之前对修改进行讨论。 ![Workflows: Pull Requests](images/pull-request.png) + + +----------------- + +　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　[集中式工作流 »](workflow-centralized.md) diff --git a/git-workflows-and-tutorials/workflow-centralized.md b/git-workflows-and-tutorials/workflow-centralized.md index b41b715..fe81b68 100644 --- a/git-workflows-and-tutorials/workflow-centralized.md +++ b/git-workflows-and-tutorials/workflow-centralized.md @@ -1,4 +1,4 @@ -中心化（Centralized）工作流 +集中式工作流 ================================= ![Git Workflows: SVN-style](images/git-workflow-svn.png) @@ -13,7 +13,7 @@ :beer: 工作方式 --------------------- -像`Subversion`一样，中心化工作流以中央仓库作为项目所有修改的单点实体。相比`SVN`缺省的开发分支`trunk`，`Git`是`master`，所有修改提交到这个分支上。这种工作流只用到`master`这一个分支。 +像`Subversion`一样，集中式工作流以中央仓库作为项目所有修改的单点实体。相比`SVN`缺省的开发分支`trunk`，`Git`是`master`，所有修改提交到这个分支上。这种工作流只用到`master`这一个分支。 开发者开始先克隆中央仓库。在自己的项目拷贝中像`SVN`一样的编辑文件和提交修改；但修改是存在本地的，和中央仓库是完全隔离的。把和上游的同步延后到一个方便时间点。 @@ -138,7 +138,7 @@ git pull --rebase origin master ![](images/git-workflow-svn-6.png) 如果你忘加了这个选项，`pull`操作仍然可以完成，但每次`pull`操作要同步别人修改时，提交历史会以一个多余的『合并提交』结尾。 -对于中心化工作流，最好是使用`rebase`而不是生成一个合并提交。 +对于集中式工作流，最好是使用`rebase`而不是生成一个合并提交。 ### 小红解决合并冲突 @@ -197,7 +197,7 @@ git push origin master 如你所见，仅使用几个`Git`命令就我们就可以模拟传统`Subversion`开发环境。对于要从`SVN`迁移的团队来说这太好了，但这没有发挥出`Git`分布式本质。 -如果你的团队适应了中心化工作流，并想更流畅的协作效果，绝对值得探索一下[功能分支工作流](workflow-feature-branch.md)。 +如果你的团队适应了集中式工作流，并想更流畅的协作效果，绝对值得探索一下[功能分支工作流](workflow-feature-branch.md)。 通过为一个功能分配一个隔离分支，使得一个新增功能集成到正式项目前对新功能进行深入讨论成为可能。 -----------------