分布式版本管理工具GIT使用心得

分布式版本管理工具GIT使用心得
来自于：服务端框架工具经验 作者：gufeiyong 2014-08-13
11:01

为什么选择git

从这个项目开始,我们项目组已经全面把代码管理从SVN转移到了GIT。很多人会问为什么不用SVN呢?svn有什么不好吗？
 SVN缺点
SVN的确是一个很强大的版本管理工具，但是他有以下一些缺点：

1.代码提交更新等操作速度慢。由于svn是一个集中式的项目管理工具，所有操作都要和服务器交互，当项目大了以后所有操作都很慢，感觉很笨重，比较影响工作效率

2.代码merge难度高，当开发一个月的版本要做代码merge的时候特别是有目录变更的时候，那叫一个痛苦啊，各种tree conflict, 处理起来难啊，而且速度很慢，有时为了做一个merge要花费一下午的时间。

3.目录管理麻烦，由于svn管理的工程下都有一个.svn的目录保存当前目录的原数据，因此如果你想把这个目录下的内容移动那就很麻烦了，直接拷贝会有一大堆问题等着你，必须连到远程操控操作，费时费力也容易出错。

4.分支代价大，SVN的分支代价很大，如果要为了一个测试性的任务开个分支，需要到远程仓库开分支，而且会复制项目工程，占用服务器磁盘空间。
 git优缺点
优点：

1.代码更新、提交、diff等操作都很快，git所有和服务器的操作交互都是通过一个文件快照，而不是像SVN那样一个个文件比较，速度简直天差地远。我相同的工程目录svn checkou出来话了几分钟，git clone仅仅需要十秒左右。代码diff git是一个本地操作，而svn是远程操作

2.可以开本地分支，开分支代价小，分支merge简单。测试性的任务本地git branch xx开个xx分支开开发，用完后git merge xx就可以了，分支合并仅需数秒，而SVN需要七八分钟。平时开发的时候可以频繁开分支、合并分支、删除分支。

3.代码管理无污染。SVN会在每个目录下放一个.svn目录，你不能破坏这个目录，一旦这个目录破坏或者移动到非它所属的目录，就会发生那些目录无法被SVN管理到的情况，解决起来是非常头疼的。而git仅在项目根目录下放了一个git目录，在其他代码目录未注入任何东西，不用担心删除目录、移动目录会带来什么影响。管理非常方便。

4.服务器占用空间少。对于长期项目来说，一般都会有很多分支，SVN分支多了磁盘占用量就会大量增加。但是git开一个分支仅仅增加几十字节的空间而已。对长期的大项目来说git会节省空间。
缺点：

1、服务器权限难以管理，由于git没有目录概念，无法针对不同用户赋予不同目录的读写权限，只能从项目总体角度来赋予权限。由于我们项目人少，代码权限管理没那么严格，所以这个问题不大。如果真的需要管理可以考虑通过sub model的方式来控制权限，相对麻烦一些。

2. 版本号不是递增的数字，而是SHA1校验码，不太容易判断哪个版本更新，要查历史记录。

3.一般一个项目会有很多工程，每个开发人员负责不同的工程，当一个开发同事改好要push时会发现不能提交，要先更新merge其他同事的代码，再提交。虽然代价也不大，就是稍微麻烦一些，记得每次提交前先pull一下其他人的更新。因为git的提交是针对整个项目工程的，没有目录概念。
总体来说git的优点胜过他的缺点。
二、git原理
 生命周期

 


 git生命周期有4个

1.untracked(未跟踪文件)

2.unmodified（已跟踪未修改文件）

3.modified(已跟踪并修改的文件)

4.staged(commit的文件)
上图显示了4个周期变化的过程。
 git 仓库
git 是一个分布式版本管理系统，它的仓库分为远程仓库和本地仓库。
在项目管理中可以有一个远程的中心仓库，用来项目组各成员共同开发使用。
本地也有一个本地仓库，本地仓库里你可以多次提交，但是不同步到远程仓库中去，等到开发测试完成了再提交远程仓库。
要使用git 首先要初始化一个git仓库，可以先在远程服务器上先安装一个仓库作为中心仓库，具体安装步骤这里不赘述了，可以参考链接的文档安装。
安装好远程仓库后通过

git clone  ssh://<gufeiyong>@<host>:<port>/<url>.git
就可以把远程仓库下载到本地。
可以通过git remote -v 来查看远程仓库信息
例如：

$ git remote -v

origin  ssh://xxx@xxx:2222/backend/ddd.git (fetch)

origin  ssh://xxx@xxx:2222/backend/ddd.git (push)
git基础操作命令
1.add
当你在当前工程中增加某个文件或者修改了某个文件可以使用
git add <fileName>
把这个文件进入准备提交状态
2.rm 
当你删除了某个文件可以通过
git rm <fileName>
把这个删除文件进入准备提交状态
3.status
git status来查看当前工程文件修改情况，会列出以下内容
（1）changes added to commit  需要add的未跟踪文件
（2）Changes not staged for commit  已修改的跟踪文件
（3）Changes to be committed   准备提交的文件

4.commit 
当你把准备提交状态的文件提交到本地仓库
git commit -m "some comment"
5.push 
git push <远程仓库名>  <分支名>
像这个
origin  ssh://xxx@xxx:2222/backend/ddd.git (push)
它的远程仓库名就是origin
6.branch
git branch xxx
开出一个名为xxx的分支
7.git checkout xxx
同svn switch,切换到名为xxx的分支
8.git merge xxx
将xxx分支合并到当前分支上
9.git pull
更新远程仓库的更新
10.git reset
回滚操作
git reset --hard
把之前被搞乱的代码reset到HEAD的代码，加入你执行git pull时发生conflict又无法总动merge，可以使用该命令来处理先丢弃本地提交
三、git分支管理方法

以下是一个比较优秀的分支管理模型，也是我们项目组目前使用的分支管理办法



1. master 分支为发布分支，绝对要求稳定，由配置管理员控制，开发不提交代码到master。每
次上线由配置管理员在master 上打tag，并打build。

2. develop 分支是开发的长期分支

3. release 分支是当开发到一定阶段时准备提交QA 测试准备release 前开的分支，开发人员从

develop 分支上拉出release 分支，QA 在该分支测试，发现问题fix bug 并提交到release 分支。
测试通过后将该release 分支merge 到master 上线，并且merge 到develop 分支。

4. 当线上出现紧急bug 时在master 上开hostfixes 分支，修复线上bug。修复完成后merge 到

master 分支上线，并merge 到develop 分支。

5. 开发人员准备后期版本的一些开发，可以开几个future branch，不影响当前版本的release，
当准备发布时再合并到develop 分支。
6. 另外，由于git 开分支代价很小，开发人员在开发过程中尽量使用本地分支开发，不要频繁
提交develop 分支，当阶段性完成部分任务的时候合并develop 分支并提交，减小对其他开
发人员的影响。

7. 每次上线由配置管理员在master 上打tag，并打build。
四、结论
    开发人员从svn转化到git需要一定的思维转变，git 也有一些用起来没有svn方便的地方，但是适应了以后会发现git管理代码真的很方便，能大大提升工作效率。尤其是在分支管理上，几乎不会花费太多精力。
五、参考文件
pro git：  http://git-scm.com/book

 

标签：

服务端工具