关于从 SVN 过渡的团队来说，会集式作业流（Centralized Workflow）是一个很棒的 Git 作业流。与Subversion相同，会集式作业流运用中心库房作为项目一切更改的单个进口点。类比 svn 的 trunk，它 运用master作为默认的开发分支且一切提交操作都在该分支上。 这种作业流除了master分支外，不需求任何其他分支。
会集式作业流在运用长途服务器端保管库房方面与其他作业流相似，开发人员能够经过这种库房推送（push）和拉取（pull）资源。
与其他作业流程相比，会集式作业流程没有定义的兼并恳求（pull request）或派生（fork）形式。会集式作业流一般更适合从 SVN 迁移到 Git 的团队以及规划较小的团队。
运作原理
初始化中心库房
ssh user@host git init --bare /path/to/repo.git
一般咱们将库房保管到 git 库房保管渠道（如 Bitbucket、Gitlab），在保管渠道上面初始化中心库房。
克隆中心库房
接下来，每个开发人员都将创立整个项目的本地副本。经过以下git clone指令完结的：
git clone ssh://user@host/path/to/repo.git
当 clone 一个库房时，假设您要在以后与之进行进一步的交互，Git 会主动添加一个叫origin的快捷方法，并指向“父”库房。
修正与提交
一旦在本地克隆了库房，开发人员就能够运用规范的 Git 提交进程进行更改：修改（edit），暂存（stage）和提交（commit）。
暂存：实际上便是我改了 3 个文件，可是我只想提交 2 个文件，就能够先
git add将指定的 2 个文件暂存，然后运用git commit就只会提交暂存的那 2 个文件，这样便避免了提交非必要文件。
git status # 查看库房状况
git add # 暂存
git commit # 提交
请记住，由于这些指令创立了本地提交，小王能够根据需求屡次重复此进程，而不用忧虑中心库房中的状况。这关于需求分解为更简单，更原子的块的大型功用十分有用。
推送新提交到中心库房
将本地更新推送到长途中心库房中。
git push origin master
该指令会将本地新提交的更改推送到长途中心库房。在此推送进程中或许出现一种特殊状况便是小丽（另一开发者）在小王之前推送过代码，此时 Git 将输出一条音讯，指出此抵触。
抵触状况下，应该先履行 Git 拉取指令：
git pull
下一节将对此抵触情形进行扩展。
抵触管理
中心库房代表官方项目，因而其提交前史应视为崇高且不行改动。假如开发人员的本地提交违背中心库房，则 Git 将拒绝推送其更改，由于这将掩盖官方提交。
在开发人员发布功用之前，他们需求获取更新的中心提交并在其基础上从头进行更改。这就像在说：“我想将自己的更改添加到其他一切人现已完结的操作中。”与传统的 SVN 作业流程相同，成果是完美的线性前史记录。
假如本地更改直接与上游提交抵触，则 Git 将暂停变基进程（the rebasing process），并为您供给手动处理抵触的时机。关于 Git 的优点是，它运用相同的git status和git add指令来生成提交和处理兼并抵触。这使新开发人员能够轻松管理自己的兼并。别的，假如他们遇到麻烦，Git 能够很轻松地间断整个从头部署并重试（或寻求帮助）。
举例阐明
让咱们举一个例子，阐明典型的小型团队怎么运用此 Git 作业流进行协作。咱们将看到小王和小丽这两个开发人员怎么运用单独的功用并经过会集式库房同享他们的奉献。
小王
在他的本地库房中，小王能够运用规范的 Git 提交进程（修改、暂存和提交）来开发功用。
git status # 查看库房状况
git add # 暂存
git commit # 提交
请记住，由于这些指令创立了本地提交，因而小王能够根据需求屡次重复此进程，而不用忧虑中心库房中的状况。
小丽
同时，小丽运用相同的（修改、暂存和提交）进程在自己的本地库房中开发自己的功用。像小王相同，她不在乎中心库房中发生的事情，她也不用在乎小王在其本地库房中正在做什么，由于一切本地库房都是私有的。
小王发布他完结的功用
小王完结其功用后，应将其本地提交发布到中心库房，以便其他团队成员能够拜访它。他能够运用git push指令履行此操作，如下所示：
git push origin master
请记住，源（origin）是与小王克隆 Git 库房时创立的中心库房的长途连接。master参数告诉 Git 测验使源（origin）的master分支对照本地的master分支。由于小王克隆以来中心库房尚未更新，因而不会形成任何抵触，而且推送将按预期进行。
小丽测验发布她完结的功用
让咱们看看假如小王成功将其更改发布到中心库房后小丽测验发布其功用，会发生什么状况。她能够运用完全相同的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.
这样能够防止小丽掩盖正式提交。她需求将小王的更新放入库房中，并将其与本地更改集成，然后重试。
小丽从头以小王的提交为基准
小丽能够运用git pull将上游更改兼并到她的库房中。这个指令有点像svn update-将整个上游提交前史记录拉到小丽的本地库房中，并测验将其与她的本地提交集成：
git pull --rebase origin master
--rebase选项告诉 Git 在将其与中心库房中的更改同步后，将一切小丽的提交都移至 master 分支的结尾，如下所示：
假如您忘记了此选项--rebase，pull仍然有效，可是每次有人需求与中心库房同步时，您都会得到多余的“兼并提交”。关于此作业流程，最好从头设置基准，而不是生成兼并提交。
小丽处理兼并抵触
变基（rebase）作业是经过将每个本地提交一次一个的转移到最新的（master）主分支。这意味着您能够逐个提交地处理兼并抵触，而不是在一个大规划兼并提交中处理一切抵触。这样能够使您的提交尽或许会集，并确保项目前史记录的整齐。反过来，这使得找出错误的方位变得容易得多，而且在必要时以对项目的影响最小的方法回滚更改。
假如小丽和小王正在开发不相关的功用，则从头定基进程不太或许发生抵触。但假如发生了抵触，Git 将在当时提交时暂停定基（rebase），并输出以下音讯以及一些相关阐明：
CONFLICT (content): Merge conflict in xxx
Git 的巨大之处在于，任何人都能够处理自己的兼并抵触。在咱们的示例中，小丽只需运行git status即可查看问题出在哪里。抵触的文件将显示在“未兼并的路径”部分中：
# Unmerged paths:
# (use "git reset HEAD ..." to unstage)
# (use "git add/rm ..." as appropriate to mark resolution)
#
# both modified:
然后，她将根据自己的喜好修改文件。对成果感到满足后，她能够依照常用的方法暂存文件（git add），然后让git rebase完结其他作业：
git add
git rebase --continue # 兼并抵触，结合 git add 指令一同用于修正抵触（fix conflicts and then run "git rebase --continue"）
以上便是一个提交的抵触处理的整个流程，Git 将继续进行下一个提交，并针对发生抵触的任何其他提交重复该进程。
当您（在抵触处理进程中）意识到感觉不对、不知道发生了什么时，不要惊慌，只需履行以下指令，您便会回到开端的方位：
git rebase --abort # 抛弃兼并，回到rebase操作之前的状况，之前的提交不会丢弃；
小丽成功发布已完结的功用
与中心库房同步后，小丽将能够成功发布其更改：
git push origin master
总结
如您所见，仅运用少数 Git 指令即可复制传统的 Subversion 开发环境。这关于将团队从 SVN 过渡过来十分有用，但它没有使用 Git 的分布式特性。
会集式作业流程十分适合小型团队。当您的团队规划扩大时，上面详述的抵触处理进程或许会成为瓶颈。假如您的团队对会集式作业流程感到满足，但想简化其协作作业，那么绝对值得探索{% post_link Git作业流之功用分支作业流 %}。经过为每个功用指定一个独立的分支，能够在将新功用集成到正式项目中之前就新功用进行深入的讨论。
英文原文
