Nov 11

git分布式版本管理 不指定

bkkkd , 23:20 , 开发应用 , 评论(0) , 引用(0) , 阅读(4769) , Via 本站原创 | |
一直以来很多人都在讨论git的强大.但一直忙于正常的开发,所以没时间去研究这个版本管理系统.


引用

git快速上手三步曲

创建一个目录,建立一个版本库(进入目录,运行 git-init-db )

一个版本库是就是一组代码或文本的集合。一般来说,在文件系统的层面上,通常是将其放入同一个目录下。与之相适应,我们让一个版本库与一个文件目录相对应,将一组相关(一个工程的)代码建立版本库,并储存于一个目录中。
mkdir gittutorcn
cd gittutorcn
git-init-db
放入要加入版本库中的文件,并植入跟踪系统(git-add)

执行了git-init-db后,只是做了一些版本库的初始化工作,还没有任何实质性的内容加进里面去。下面我们就要将一些代码文件拷到刚才建立的那个目录中去(更通常的方式是先拷入这些文件,再运行上面的 git-init-db),然后运行git-add *(*也可以替换成具体的文件名或目录名), 就将那些文件加入到git的版本跟踪库里面去了。不过此时还只是告诉git“我们有哪些(新)文件要加入”(会自动进行修改时间比较,然后自动判断哪些文件该加入),并没有提交这些文件的具体内容到版本库中去。
git-add *
提交内容到版本库中去(git-commit)

现在我们要把内容提交到版本库中去。用
git-commit -m "Initial commit of gittutor reposistory" -a
可以将工程目录下的文件全部提交(当然最好当前的位置处于工程根目录下)。
一些常用的命令

查看当前版本库的状态(git-status)



分支管理命令(git-branch)

前面的所有操作都没有涉及到版本管理的一个重要方面──多人协作开发所带来的分支管理。git上有一个默认的分支名master,之前所有的操作都是在master分支上进行,即你是以这个版本库的管理员的身份来操作的。引入分支管理基于如下情况:

创建一个属于自己的个人工作分支,以避免对主分支 master 造成太多的干扰,也方便与他人交流协作。
当进行高风险的工作时,创建一个试验性的分支,扔掉一个烂摊子总比收拾一个烂摊子好得多。
合并别人的工作的时候,最好是创建一个临时的分支,关于如何用临时分支合并别人的工作的技巧,将会在后面讲述。
创建分支

#创建了一个名叫“b1"的分支。
git-branch b1

#把刚才创建的那个叫"b1"的分支给删除了。
git-branch -D b1
查看分支

git-branch
会把所有的分支名称列出来。前面打“*”号的就是你当前所在的分支。

导出分支内容,切换分支(git-checkout)

运行git-checkout后,会将当前所在的分支的最新版本内容导出来(如果你在修改后还没有提交的话,那种这种导出将直接覆盖你的修改)。 而如果运行

git-checkout master
那么,就会从当前分支切换到master分支上去。

查看版本库中每个分支的世系发展状态(git-show-branch)

git-show-branch 命令可以使我们看到版本库中每个分支的世系发展状态,并且可以看到每次提交的内容是否已进入每个分支。不过格式不敢恭维,眼花缭乱的。

查看差别(git-diff)

查看当前工作与版本库中的差别 运行 git-diff 将给出当前工作目录中的文件与版本库的头节点(最新提交的)数据的差别,差异将以典型的 patch 方式表示出来:

git-diff master b2
可查看master和b2两个分支的差别。

查看某个分支的发展过程(git-whatchanged)

运行 git-whatchanged 可以显示当前所在分支的发展状况(版本提交状况)。

分支合并与冲突解决方式

git-checkout master
git-merge "Merge work in robin" HEAD b2


git-checkout master
git-pull . b2
作用都是将b2这个分支的最新版本内容(提交后的)合并到master分支中去。如果在合并的过程中出现了冲突(具体通俗点说,就是在master, b2这两个分支中的某个文件的某些相同的行中的内容不一样),我们就需要手动解决这些冲突,用编辑器把发生冲突的那个文件的内容编辑一下(会在里面看到 diff的文件格式)。然后再执行

git-commit -i XXXX (XXXX就是发生冲突的那个文件名)
就可以提交此冲突文件,并且将未合并完的过程继续做完。

逆转与恢复命令(git-reset)

项目跟踪工具的一个重要任务之一,就是使我们能够随时逆转(Undo)和恢复(Redo)某一阶段的工作。git-reset 命令就是为这样的任务准备的。它可以将当前的工作分支的“头”定位到以前提交的任何版本中。

git-reset 参数 版本标号

其中,参数项可以有以下3个。
--mixed
      仅是重置索引的位置,而不改变你的工作树中的任何东西(即,文件中的所有变化都会被保留,也不标记他们为待提交状态),并且会提示什么内容还没有被更新了。这个是默认的选项。
--soft
      既不触动索引的位置,也不改变工作树中的任何内容。这个选项使你可以将已经提交的东西重新逆转至“已更新但未提交(Updated but not Check in)”的状态。就像已经执行过 git-add 命令,但是还没有执行git-commit 命令一样。
--hard
  将工作树中的内容和头索引都切换至指定的版本位置中,也就是说自“版本标号”项之后的所有的跟踪内容和工作树中的内容都会全部丢失。因此,这个选项要慎用,除非你已经非常确定你的确不想再看到那些东西了。
其中,版本标号通常可以用 HEAD, HEAD^ 之类的标号表示。
与其它人交换代码

通常的情况下,合并其他的人的工作的情况会比合并自己的分支的情况要多,这在 git 中是非常容易的事情,和你运行 git-merge命令没有什么区别。事实上,远程合并的无非就是“抓取(fetch)一个远程的版本库中的工作到本地”,然后再使用 git-merge 命令。

项目克隆命令(git-clone)

此命令会将项目库中的所有内容(包括版本数据记录和所有的文件)都拷贝到本地。 它支持5种协议:

**本地目录**: git-clone /root/workspace/projects/kernel/kernel-2f/
    下载,单向操作

**SSH服务**: git-clone git@172.16.2.56:/root/workspace/projects/kernel/kernel-2f/
    上传下载,双向操作

**GIT服务**: git-clone git://172.16.2.56/root/workspace/projects/kernel/kernel-2f/
    下载,单向操作

**Rsync**: git-clone rsync://172.16.2.56/root/workspace/projects/kernel/kernel-2f/
    上传下载,双向操作

**HTTP**: git-clone http://172.16.2.56/root/workspace/projects/kernel/kernel-2f/
    下载,单向操作
抓取版本记录(git-fetch)

将远程版本库中相对于本地库的origin的版本更新信息下载下来。更新索引。 与 git-clone 一样,它也支持上面5种协议。如 git-clone git@172.16.2.56:/root/workspace/projects/kernel/kernel-2f/

获取实际文件(git-pull)

git-pull与git-fetch的区别在于git-pull将版本记录下载下来后,还要与本地分支进行合并。所以相当于 git-pull = git-fetch + git-merge。

利用服务器进行协同开发工作(代码管理模式探讨)

一个团队进行项目开发,必须要有清晰的开发交互管理模式。一般来讲,一个团队总是要用一个服务器来做为代码的存储和下载中心。如何将基于分布式概念的git用活成为一个方便的团队版本管理工具,是一个值得研究的问题。下面以一个实例来探讨一下: 现有A,B,C,D四个员工,一台服务器。服务器IP为172.16.1.50,A的计算机IP为172.16.1.51,B的计算机IP为172.16.1.52,C的计算机IP为172.16.1.53,D的计算机IP为172.16.1.54。有一个项目,名叫GOD,A是管理员。可以有如下几种工作方式。 一: A在本地机器上建立GOD的代码库。其他三位员工直接从A的机器上克隆(利用SSH,需要知道用户和密码)代码和版本信息。然后,B,C,D分别在各自的master分支里进行工作。等到要提交的时候,比如说B要提交,则B给A发封邮件,提醒一下,我这儿有些工作要提交给你。A收到提示后,就主动去B的机器(通过SSH)上去取(需要知道用户名,密码)master分支,取的时候,将取回的版本信息存放到本地的一个新的分支中去。然后,再将这个新的分支与自己的工作分支(可能是master分支)进行合并,产生新的代码。合并完成后,再通知B,我已经合并完成了,请你同步到最新的代码来。于是,B用git-fetch或git-pull将A的合并后的代码同步到本地机器上来。这样就完成了一个交互。C,D也类似。 这样做的特点就是:

没有使用独立的服务器;
需要B,C,D和A知道互相知道对方的机器帐号,密码;
不需使用邮件来交互;
需要管理员A来主动取各个员工的代码。
二: A在服务器上建立一个GOD的公开版本库。利用git协议,或http协议(匿名的)。A在本机上工作的内容,首先是推到服务器上去(git-push)。其它员工,从服务器上去克隆(git-clone)代码。B,C,D在下载代码后,在各自的master分支上开发。B做了一些工作后,再提醒A来我这里取代码,A主动去取。取回后,再合并。最后,把合并好的代码再Push到服务器上去。其他员工从服务器上来pull代码,进行同步更新。这样做的特点是:

使用了独立的服务器;
需要A知道B,C,D的机器帐号,密码。不需要B,C,D知道A的机器帐号,密码;
不需使用邮件来交互;
需要管理员A来主动取各个员工的代码。
三: A在服务器上建立一个GOD的公开版本库。利用git协议,或http协议(匿名的)。A在本机上工作的内容,首先是推到服务器上去(git-push)。其它员工,从服务器上去克隆(git-clone)代码。B,C,D在下载代码后,在各自的master分支上开发。B做了一些工作后,利用 git-format-patch origin 打自己的版本与origin版本的补丁(最好在打补丁之前运行一下git-fetch origin,跟进的最新的版本记录),生成后,通过Email的形式,将补丁发给A。A收到后,对自已的工作代码打补丁。最后,把打补丁(合并)好的代码再Push到服务器上去。其他员工从服务器上来pull代码,进行同步更新。这样做的特点是:

使用了独立的服务器;
不需要A知道B,C,D的机器帐号,密码。不需要B,C,D知道A的机器帐号,密码。只需要知道各自的邮箱即可。
需使用邮件来交互;
不需要管理员A来主动取各个员工的代码。由员工主动向管理员发送补丁文件。

http://dev.lemote.com/drupal/book/export/html/21
http://f2e.us/wiki/Git.html#!/
http://blog.prosight.me/index.php/2009/11/485

http://gitbook.liuhui998.com/index.html 中文用户手册
发表评论
表情
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
打开HTML
打开UBB
打开表情
隐藏
记住我
昵称   密码   游客无需密码
网址   电邮   [注册]