git初接触之一

上一篇 / 下一篇  2016-04-08 09:23:42 / 个人分类:git

什么是Git?

Git是一款免费、开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目。Git的读音为/gɪt/。

Git是一个开源的分布式版本控制系统,用以有效、高速的处理从很小到非常大的项目版本管理。Git 是 Linus Torvalds 为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。

Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper,后者之前一直是 Linux 内核开发人员在全球使用的主要源代码工具。开放源码社区中的有些人觉得 BitKeeper 的许可证并不适合开放源码社区的工作,因此 Torvalds 决定着手研究许可证更为灵活的版本控制系统。尽管最初 Git 的开发是为了辅助 Linux 内核开发的过程,但是我们已经发现在很多其他自由软件项目中也使用了 Git。例如 最近就迁移到 Git 上来了,很多 Freedesktop 的项目也迁移到了 Git 上。


产品特点

分布式和集中式的最大区别在于开发者可以本地提交。每个开发者机器上都有一个服务器的数据库

下图是经典的git开发过程。

Git的功能特性:

从一般开发者的角度来看,git有以下功能:

1:从服务器上克隆数据库(包括代码和版本信息)到单机上。

2:在自己的机器上创建分支,修改代码。

3:在单机上自己创建的分支上提交代码。

4:在单机上合并分支。

5:新建一个分支,把服务器上最新版的代码fetch下来,然后跟自己的主分支合并。

6:生成补丁(patch),把补丁发送给主开发者。

7:看主开发者的反馈,如果主开发者发现两个一般开发者之间有冲突(他们之间可以合作解决的冲突),就会要求他们先解决冲突,然后再由其中一个人提交。如果主开发者可以自己解决,或者没有冲突,就通过。

8:一般开发者之间解决冲突的方法,开发者之间可以使用pull 命令解决冲突,解决完冲突之后再向主开发者提交补丁。

功能介绍

从主开发者的角度(假设主开发者不用开发代码)看,git有以下功能:

1:查看邮件或者通过其它方式查看一般开发者的提交状态。

2:打上补丁,解决冲突(可以自己解决,也可以要求开发者之间解决以后再重新提交,如果是开源项目,还要决定哪些补丁有用,哪些不用)。

3:向公共服务器提交结果,然后通知所有开发人员。

优点:

适合分布式开发,强调个体。

公共服务器压力和数据量都不会太大。

速度快、灵活。

任意两个开发者之间可以很容易的解决冲突。

离线工作。

缺点:

资料少(起码中文资料很少)。

学习周期相对而言比较长。

不符合常规思维。

代码保密性差,一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

开发模式

尽管 git 是一个正式项目发布系统,它却可以方便地将你的项目建立在松散的开发人员组织形式上。 Linux内核的开发,就是按这样的模式进行的。在 Randy Dunlap 的著作中("Merge to Mainline" 第17页)就有很好的介绍

需要强调的是真正的非常规的开发组织形式, git 这种组织形式,意味着对于工作流程的约束,没有任何强迫性的原则。你不必从唯一一个远程版本库中导入(工作目录)。

项目领导人(project lead)的工作推介

1. 在你自己的本地机器上准备好主版本库。你的所有工作都在这里完成。

2. 准备一个能让大家访问的公共版本库。

如果其他人是通过默协议的方式(http)来导入版本库的,那么你有必要保持这个 默协议的友好性。 git-init-db 之后,复制自标准模板库的 $GIT_DIR/hooks/post-update 将包含一个对 git-update-server-info 的调用,但是 post-update 默认是不能唤起它自身的。通过 chmod +x post-update 命令使能它。这样让 git-update-server-info 保证那些必要的文件是最新的。

3. 将你的主版本库推入公共版本库。

4. git-repack 公共版本库。这将建立一个包含初始化提交对象集的打包作为项目的起始线,可能的话,执行一下 git-prune,要是你的公共库是通过 pull 操作来从你打包过的版本库中导入的。

5. 在你的主版本库中开展工作,这些工作可能是你自己的最项目的编辑,可能是你由 email 收到的一个补丁,也可能是你从这个项目的“子系统负责人” 的公共库中导入的工作等等。

你可以在任何你喜欢的时候重新打包你的这个私人的版本库。

6. 将项目的进度推入公共库中,并给大家公布一下。

7. 尽管一段时间以后,"git-repack" 公共库。并回到第5步继续工作。

项目的子系统负责人(subsystem maintainer)也有自己的公共库,工作流程大致如下:

1. 准备一个你自己的工作目录,它通过 git-clone 克隆自项目领导人的公共库。原始的克隆地址(URL)将被保存在 .git/remotes/origin 中。

2. 准备一个可以给大家访问的公共库,就像项目领导人所做的那样。

3. 复制项目领导人的公共库中的打包文件到你的公共库中,除非你的公共库和项目领导人的公共库是在同一部主机上。以后你就可以通过 objects/info/alternates 文件的指向来浏览它所指向的版本库了。

4. 将你的主版本库推入你的公共版本库,并运行 git-repack,如果你的公共库是通过的公共库是通过 pull 来导入的数据的话,再执行一下 git-prune 。

5. 在你的主版本库中开展工作。这些工作可能包括你自己的编辑,来自 email 的补丁,从项目领导人,“下一级子项目负责人”的公共库哪里导入的工作等等。

你可以在任何时候重新打包你的私人版本库。

6. 将你的变更推入公共库中,并且请“项目领导人”和“下级子系统负责人”导入这些变更。

7. 每隔一段时间之后,git-repack 公共库。回到第 5 步继续工作。

“一般开发人员”无须自己的公共库,大致的工作方式是:

1. 准备你的工作库,它应该用 git-clone 克隆自“项目领导人”的公共库(如果你只是开发子项目,那么就克隆“子项目负责人”的)。克隆的源地址(URL)会被保存到 .git/remotes/origin 中。

2. 在你的个人版本库中的 master 分支中开展工作。

3. 每隔一段时间,向上游的版本库运行一下 git-fetch origin 。这样只会做 git-pull 一半的操作,即只克隆不合并。公共版本库的新的头就会被保存到 .git/refs/heads/origins 。

4. 用 git-cherry origin 命令,看一下你有什么补丁被接纳了。并用 git-rebase origin 命令将你以往的变更迁移到最新的上游版本库的状态中。(关于 git-rebase 命令,请参考 git-rebase)

5. 用 git-format-patch origin 生成 email 形式的补丁并发给上游的维护者。回到第二步接着工作。


TAG:

 

评分:0

我来说两句

Open Toolbar