Git分布式工作流程
Posted whenyd
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Git分布式工作流程相关的知识,希望对你有一定的参考价值。
Git官网给出了三种分布式工作流程:
- 集中式工作流程
- 集成管理者工作流
- 司令官与副官工作流
这里以私有gitserver服务器上的git-test项目为例,简单说明集中式工作流程。
基于分支的开发策略
分支简介
参考Git Pro
使用分支意味着你可以把你的工作从开发主线上分离开来,以免影响开发主线。
使用Git开发的过程中,鼓励使用分支进行迭代开发,分支的创建、删除、合并非常简单,任何主题(新特性,bug,test,idea...)都可以在单独的分支上存在。
本地分支策略
参考Git Pro
Git管理的项目,有一个默认分支master,可以理解为项目的主分支,其他分支可以根据需要创建。
一般来说,master分支只负责版本发布,实际开发过程在类似于dev分支或develop的分支上完成。而每个新特性或每次迭代都在各自独立的分支上开发,最后合并到dev分支。
从服务器克隆项目
cd <work dir>
git clone [email protected]:/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
查看所有的跟踪分支。
本地开发
为了降低开发复杂度,强烈建议本地开发使用分支,每个新特性和迭代都可以建立新的分支,完成后合并到本地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
以上是关于Git分布式工作流程的主要内容,如果未能解决你的问题,请参考以下文章