Git分布式工作流程

Git官网给出了三种分布式工作流程:

• 集中式工作流程
• 集成管理者工作流
• 司令官与副官工作流

这里以私有gitserver服务器上的git-test项目为例，简单说明集中式工作流程。

基于分支的开发策略

分支简介

参考Git Pro
使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。
使用Git开发的过程中，鼓励使用分支进行迭代开发，分支的创建、删除、合并非常简单，任何主题（新特性，bug，test，idea...）都可以在单独的分支上存在。

本地分支策略

参考Git Pro
Git管理的项目，有一个默认分支master，可以理解为项目的主分支，其他分支可以根据需要创建。
一般来说，master分支只负责版本发布，实际开发过程在类似于dev分支或develop的分支上完成。而每个新特性或每次迭代都在各自独立的分支上开发，最后合并到dev分支。

从服务器克隆项目

cd <work dir>
git clone git@gitserver:/git/git-test
cd git-test

设置跟踪分支并拉取内容

从远程克隆的项目只有master分支的内容，本地master分支默认跟踪远程的master分支，即origin/master。而本地dev分支跟踪远程dev分支需要手动设置。可以使用以下方式：

git checkout --track origin/dev

或

git checkout -b dev origin/dev

这样以来，本地dev分支和origin/dev就建立了联系，可以直接push或pull，可以用git branch -vv查看所有的跟踪分支。
要设置已有的本地分支跟踪一个刚刚拉取下来的远程分支，或者想要修改正在跟踪的上游分支，可以使用 -u 或 --set-upstream-to 选项运行 git branch 来显式设置：

git checkout dev
git branch -u origin/dev

本地开发

为了降低开发复杂度，强烈建议本地开发使用分支，每个新特性和迭代都可以建立新的分支，完成后合并到本地dev分支。

同步仓库

注意：

只能推送本地dev分支到远程dev分支，master分支只用于版本发布，可以定期从服务器拉取master分支以同步仓库内容。

由于是分布式开发，推送前一定要将其他人提交到库的内容合并到本地，这也可以避免推送时的冲突。有两种合并方式，一种是使用pull命令，一种是先fetch然后合并，pull直接合并远程分支的内容到本地，有一定的风险，推荐使用第二种。

fetch

git fetch origin

该命令会拉取origin的所有分支到本地，可以通过一个特殊的名字FETCH_HEAD来显示远程和本地的差异：

git log -p HEAD..FETCH_HEAD

也可以

git diff dev origin/dev

该命令会显示远程仓库内最新的内容，合并远程dev分支到本地可以使用merge。

merge

git checkout dev
git merge origin/dev

解决合并冲突可以参考Git Pro。
rebase可以避免将开发的细节过程推送到服务器，提交信息显得比较清爽干净。但是，rebase只可以用于本地的分支合并，不要对在你的仓库外有副本的分支执行变基。这样会使其他人强制rebase自己的分支，最终会导致很多问题。
如果你遵循这条金科玉律，就不会出差错。 否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。
更多内容可以参考Git Pro的变基部分。

推送dev分支

git push origin dev