Git 分布式版本控制软件_Windows_ThinkSAAS
Git 分布式版本控制软件
Git 分布式版本控制软件
内容来源： 网络
Git的维基百科地址：
Git --- The stupid content tracker，傻瓜内容跟踪器。Linux是这样给我们介绍Git的。
Git是用于Linux内核开发的版本控制工具。与常用的版本控制工具CVS、Subversion等不同，它采用了分布式版本库的方式，不必服务器端软件支持，使源代码的发布和交流极其方便。Git的速度很快，这对于诸如Linux kernel这样的大项目来说自然很重要。Git最为出色的是它的合并跟踪（merge tracing）能力。
实际上内核开发团队决定开始开发和使用Git来作为内核开发的版本控制系统的时候，世界开源社群的反对声音不少，最大的理由是Git太艰涩难懂，从Git的内部工作机制来说，的确是这样。但是随着开发的深入，Git的正常使用都由一些友好的脚本命令来执行，使Git变得非常好用，即使是用来管理我们自己的开发项目，Git都是一个友好，有力的工具。现在，越来越多的著名项目采用Git来管理项目开发，例如：wine、U-boot等[2] 。
作为开源自由原教旨主义项目，Git没有对版本库的浏览和修改做任何的权限限制，通过其他工具也可以达到有限的权限控制，比如：gitosis, CodeBeamer MR。原本Git的使用范围只适用于Linux / Unix平台，但逐步并成熟了在Windows平台下的使用，主要归功于Cygwin与msysgit环境与TortoiseGit这样易用的GUI工具。其实Git的源代码中已经加入了对Cygwin与MinGW编译环境的支持并被逐步完善，对于Windows使用者是个福音。
PHP开发框架
开发工具/编程工具
服务器环境文档分类：
下载后只包含 1 个 DOC 格式的文档，没有任何的图纸或源代码，
下载前请先预览，预览内容跟原文是一样的，在线预览图片经过高度压缩，下载原文更清晰。
您的浏览器不支持进度条
下载文档到电脑，查找使用更方便
还剩?页未读，继续阅读
播放器加载中，请稍候...
该用户其他文档
下载所得到的文件列表软件工程课程设计报告-版本控制工具综述.doc
文档介绍：
西安科技大学软件工程课程设计题目:软件版本管理工具题目:软件版本控制工具学院:计算机科学与技术班级:计科1004姓名学号:完成时间:引言随着信息技术的飞速发展,软件产品的规模也越来越庞大,个人单打独斗的开发方式已经越来越不适应社会发展的需要。各软件企业都积极地将软件项目管理引入开发活动中,对开发实行有效的管理。从概念上讲,软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,达到对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上,软件项目管理的意义不仅仅如此,进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力,企业的软件开发能力越高,表明这个企业的软件生产越趋向于成熟,企业越能够稳定发展,减小开发风险。软件开发不同于其他产品的制造,软件的整个过程都是设计过程;另外,软件开发不需要使用大量的物质资源,而主要是人力资源;并且,软件开发的产品只是程序代码和技术文件,并没有其他的物质成果果。如果在开发团队中没有使用版本控制,多个开发人员共同负责同一个软件文档的开发,每个人在各自的机器上有整个软件文档的备份,并对之实施编程开发,在分别完成各自任务之后,再通过文本比对工具将各自机器上的不同版本的程序整合到一台机器上。没有进行版本控制或者版本控制本身缺乏正确的流程管理,在软件开发过程中将会出现很多问题,版本控制的目的是实现开发团队并行开发、提高开发效率。其目的在于对软件开发过程中文件或目录的发展过程提供有效的追踪手段,保证在需要时可回到旧的版本,避免文件的丢失、修改的丢失和相互覆盖,通过对版本库的访问控制避免未经授权的访问和修改,达到有效保护企业软件资产和知识产权的目的。版本控制的功能在于跟踪记录整个软件的开发过程,包括软件本身和相关文档,以便对不同阶段的软件及相关文档进行表示并进行差别分析,对软件代码进行可撤消的修改,便于汇总不同开发人员所做的修改,辅助协调和管理软件开发团队。1版本控制现在的软件项目开发中,必然涉及版本控制(RevisionControl)工具。没有使用版本控制工具的开发工作,有人形容就如同驾驶一辆超速“汽车”,虽然会很快到达目的地,但是难免会中途发生事故。版本控制工具是项目开发中必不可少的,以此进行的版本控制可以确保在软件项目开发中,不同的开发人员所涉及的同一文档都得到更新。1.1“超速汽车”通常带来的“事故”3在没有使用版本控制工具之前,软件开发通常会遇到的问题:(1)软件代码的一致性问题;(2)软件内容的冗余问题;(3)软件过程的“事务性”;(4)软件开发的“并发性”;(5)软件代码的安全性;(6)软件的整合1.2关于软件版本控制如果在开发团队中没有使用版本控制,多个开发人员共同负责同一个软件文档的开发,每个人在各自的机器上有整个软件文档的备份,并对之实施编程开发,在分别完成各自任务之后,再通过文本比对工具将各自机器上的不同版本的程序整合到一台机器上。可想而知没有进行版本控制或者版本控制本身缺乏正确的流程管理,在软件开发过程中将会出现诸多问题。版本控制的目的是实现开发团队并行开发、提高开发效率的基础。其目的在于对软件开发进程中文件或目录的发展过程提供有效的追踪手段,保证在需要时可回到旧的版本,避免文件的丢失、修改的丢失和相互覆盖,通过对版本库的访问控制避免未经授权的访问和修改,达到有效保护企业软件资产和知识产权的目的。版本控制的功能在于跟踪记录整个软件的开发过程,包括软件本身和相关文档,以便对不同阶段的软件及相关文档进行表示并进行差别分析,对软件代码进行可撤消的修改,便于汇总不同开发人员所做的修改,辅助协调和管理软件开发团队。Linux下的版本控制图1-1所示集中式结构软件版本管理4图1-2所示分散式结构软件版本管理版本控制在空间上可以保证完成集中统一管理,解决一致性和冗余问题。在开发工作中,开发人员在提交软件代码的时候一般采用服务器/客户端方式,尽管开发人员可以在自己的本地留有备份,但最终唯一有效的只有服务器端的程序代码;在时间上全程跟踪记录工具将会自动记录开发过程中的每个更改细节,和不同时期的不同版本。这在一定程度上可以解决冗余、事务性处理并发性问题。项目管理人员可以通过版本控制对团队中的不同人员,实施操作权限的控制。对于不同角色的开发人员,对软件的不同部分可以定义不同的访问权限。这在一定程度可以解决软件安全性问题。版本控制工具的使用,可以减轻开发人员的负担,节省时间,同时降低人为错误。2各“级别”的版本控制工具“工欲善其事,必先利其器”。既然版本控制在软件项目开发中如此重要,那就有必要来仔细了解一下软件版本控制工具。版本控制工具也有“级别”之分,其中有“元老级”(ChangeandConfigurationControl)、RCS(RevisionControlSystem)、SCCS(SourceCodeControlSystem),“新秀级”的HanskyFirefly,“入门级”的VisualSourceSafe,“中坚级”的Clearcase,还有开源软件通用的版本控制工具CVS(Concurrent5VersionsSystem)和SVN(SubVersion)。CVS在一段时期内几乎成为版本控制工具的“代名词”,大概有着30多年的历史,而SVN是CVS的理想替代者,并出自同一人之手,被一些人誉为“迄今为止最好用的开源源码版本控制工具”。2.1“元老级”:ChangeandConfigurationControl。在20世纪60年代末70年代初,软件配置管理的概念开始提出。20世纪七十年代初期加利福利亚大学的LeonPresser撰写了一篇论文,提出控制变更和配置的概念,之后在1975年,他成立了一家名为SoftTool的公司,——这也是最早的配置管理工具之一。2.2RCSRCS:RevisionControlSystem。诞生于1980年,由WALTER.f.Tichy于美国的在Indina州的Purdue大学开发,是基于单一文件的版本维护系统。2.S:SourceCodeControlSystem。SCCS是一种基本的程序源代码版本控制工具,它适用于任何正文文件的版本维护。SCCS基于单一文件的版本控制,通常它的软件储藏室和要维护的文件在同一目录下.SCCS工作时,S格式的文件保留其源文件的编码版本,其记录了足够的信息来生成新的版本,并记录了谁对文件有修改权,拥有该版本的”锁”。2.4“新秀级”的HanskyFireflyHanskyFirefly:作为Hansky公司软件开发管理套件中重要一员的Firefly,可以轻松管理、维护整个企业的软件资产,包括程序代码和相关文档。Firefly是一个功能完善、运行速度极快的软件配置管理系统,可以支持不同的操作系统和多种集成开发环境,因此它能在整个企业中的不同团队,不同项目中得以应用。Firefly基于真正的客户机/服务器体系结构,不依赖于任何特殊的网络文件系统,可以平滑地运行在不同的LAN、WAN环境中。它的安装配置过程简1
内容来自淘豆网转载请标明出处.后使用快捷导航没有帐号？
查看: 1128|回复: 3
Linux内核开发：使用Git管理源代码
Git 是 Linux Torvalds 为了帮助管理 Linux& 内核开发而开发的一个开放源码的版本控制软件。我们可以自己下载这个软件用于对内核的 hack 分析，或者用来管理自己的软件开发项目。本文将向您展示如何使用 Git 工具开始分析 Linux 。 2 R" W. a- Y' r0 i
( B$ D5 Q9 [' ^: R2 @) p
在现代软件开发项目中，要成为一个有效的软件开发人员，我们必须能够与其他项目贡献者并行进行开发。源代码管理（SCM）系统不是什么新思想。为了编写一些能够更快速、简单地开发以后软件项目的软件，已经进行了很多尝试。最新的源代码解决方案都包含了版本控制系统，它可以对源代码的修改进行回滚，从而将有害的代码剔除出项目之外，或者简单地跟踪哪些人修改了代码的哪些行的内容。版本控制系统试图解决开发人员在试图同时对某个文件进行修改时所出现的冲突问题，可以防止用户覆盖其他人所作的修改。源代码管理使用的很多流行解决方案都试图解决以前 SCM 解决方案中的失效问题。 2 V$ \, i9 W: B% k2 D
% x" O3 H& x" R# W% U
集中化的版本控制系统通常采用两种方式
$ R7 d4 k& G7 L$ t6 a
有些提供了文件锁来防止多个用户的并行访问。这些系统对文件进行加锁，这样在某个时间只有一个开发人员对中心仓库具有写入权限。 . t1 F0 s! S3 }0 h
5 A, ~- Y2 p) ^1 \
另外一些工具，例如 CVS，允许多个开发人员同时对相同的文件进行编辑，并提供了一些机制稍后合并这些修改。
流行的版本控制系统包括:
) s4 ]4 Q$ M&&u* _1 u4 w! b
Subversion
Arch / x4 h' L3 k8 j6 g# @
BitKeeper " {) i! P3 B9 U
什么是 Git？ ! Y7 H* u! ~- \+ z4 ?) J1 i9 C
1 k1 Y% D2 v3 {; u1 q0 m: F
现在切换到包含新下载的内核的目录中：
$ cd linux-2.6
现在，我们应该在本地机器上有一个可以工作的 Linux 2.6 仓库了！此时我们就可以对这个仓库进行一些基本的操作了。
更新本地 Git 仓库 . R# L6 g/ R; \: `3 l. ]7 |
在使用 Git 时，我们通常可以假设自己的仓库可能比 kernel.org 的仓库有些滞后。因此我们通常都是首先将自己的仓库更新成最新的上游内核树。这个过程有时称为快速合并（fast-forward merge）。严格来说，我们现在并不需要执行这个过程，因为我们刚刚安装了自己的仓库，它应该还没有过期。但是检查一下毕竟没有坏处：
7 D2 }' q&&A. t$ M: O
$ cd linux-2.6 ; @2 W; o& G, R5 {' W- l
0 g& o1 k, A% [- P' n* p7 `
$ git-pull git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git 0 ]* e+ ^3 x) b* }" c
; X; G/ y$ D' |: }, {&&r4 N- m! Q
... ; m&&t' |& H/ M0 n* Q&&h& C* k
7 O4 s# z$ _&&]& G/ k4 E# b' F# R( M
如果成功，我们就应该会看到类似于下面的输出结果：
receiving file list ... done6 y2 u" S' r4 F- f: @&&T( W
sent 130 bytes received 21677 bytes 14538.00 bytes/sec
total size is
speedup is 5863.52
Already up-to-date.
$& 1 O- W. |/ X0 x9 u
如果我们的仓库不是最新的，就会看到有些内容通过网络传输到本地机器上了。 ( D' P3 g' }, g6 q
9 g+ c. ]: i! d6 [, Y/ v
从仓库中导出文件
6 X8 {# o5 r$ s! \& ]+ o7 }
我们需要将文件从 Git 仓库（隐藏目录中的那些文件）中导出到工作目录中才能开始自己的 hack 过程。下面的命令会在当前目录中写入没有隐藏的目录，其中包含了 Linux 的源代码：
" y& I2 i7 y" Y% f+ v
$ git-checkout
如果您希望覆盖本地修改，可以使用 -f 选项导出文件，这样就可以将您带回到一个干净的状态：
' G7 A) s5 r& y. Q. \: h
8 ?6 z+ `# d2 t) r% W! d4 X
$ git-checkout -f
现在在当前工作目录中，我们应该就可以看到熟悉的 Linux 源代码目录结构了，然后我们可以对这些源代码任意进行修改。 : ~7 d, f( W. v8 R6 s4 L
修改现有文件 % F3 F+ g/ Z3 c5 z
1 R' ^# k$ L' O; z
我们现在可以修改所选择的任何文件。举一个简单的例子来说，我们将修改 docs 目录中的一些内容：添加一条以后可以很容易识别的信息。为了让我的例子更容易试验，我没有选择修改源代码；不过只要您希望，欢迎继续重写整个内核的子系统。
首先，让我们在编辑器中打开一个文件： 9 ], T8 w3 ]$ F8 y1 T
/ G; h, O+ X5 ]+ ]7 `
$ vi ./Documentation/ManagementStyle
1 S$ y9 U3 @7 P
显然，我使用的是 vi；不过您当然可以使用自己喜欢的任何编辑器来完成这项工作。在编辑文件时，我在第一段前面添加了一行：“Eli shall be in charge of managing sandwich consumption. See Documentation/Sandwiches for more.”
如果您对自己所做的修改非常满意，并且觉得自己已经准备好将其作为仓库的一个永久部分了，就需要使用下面的命令导入您的修改：
1 n4 I. W8 m! \&&}1 z
$ git-commit Documentation/ManagementStyle
您会被提示说要求提供一个提交消息，它是一个用户生成的注释，用来帮助其他开发人员（也可能是您自己以后）理解刚才的实现到底进行了哪些修改。在我们的例子中，提交消息是一个描述刚才对文档所做修改的短句。 ; }) p6 @* w/ F& N
如果您希望检查一下到目前为止工作的状态，可以执行 git-log 来查看本地仓库的历史（它继承了所克隆的仓库的信息）。您的提交消息应该在日志的最上面。 : u" y8 W&&O5 [&&m
# i7 [& }% B; p. f5 T9 P&&S
添加或删除文件 : F' `" X, u" n8 X% Y
7 ?" d) e2 F7 b$ r9 r
但是请等一下！我们还没有添加 Documentation/Sandwiches 文件呢，因此我们需要将其添加到工作目录中，并告诉 Git 何时这个文件已经准备好了。我使用 echo 命令创建了想要添加的文件，因为这只是一个简单的例子而已。同样，您也可以使用自己喜欢的工具。 " M' c$ r7 s4 w! n8 B8 F2 N. R$ j
9 o: ]* a( v2 [( n) k: t
$ echo &Turkey is superior& & Documentation/Sandwiches' K% @# W1 q3 }&&U1 L5 j- k( v) a
% _+ g7 ]: p1 P
7 y9 ~. \3 F7 p7 L% o% W
现在我们已经添加了一个文件，接下来需要将这个文件添加到 Git 中，从而让 Git 了解这种变化，然后才能提交这个版本。我们可以通过执行下面的命令来完成这些任务： ( l8 R( E/ y3 P
$ git-add Documentation/Sandwiches
$ git-commit Documentation/Sandwiches
- [9 p3 R5 e' l- s# z( `" N0 Y6 a
如果您添加了多个文件，可以在同一行中的 git-add 命令后面列出这些文件，不过您也不必一次将它们全部添加到仓库中去。如果要删除某个文件，并且没有 git-add 之类的特殊命令；您只需要删除这个文件，然后提交就可以了。 + l6 n" k3 p2 D- ~$ Q&&A&&L& U
现在应该查看一下 git-log，从而确保到现在为止所做的事情都是正确的。这一次，我们将使用 -p 选项来以单独的补丁格式查看日志。 4 b9 [! t) i) Y5 t- h' J) X# n" _2 ~
% i7 x9 {$ n9 I4 B, Z* F3 O
$git-log -p& {7 V! ]/ P. {&&h! Q
创建 diff 文件
* x0 X+ o' |3 ?/ ~. r9 V7 |
最后，我们希望生成一个包含您修改后的文件和原文件之间区别的文本文件。这个文件通常是使用 diff 工具创建的，因此就称为 diff 文件。diff 可以帮助我们创建补丁文件（patch file），后者是我们向很多开放源码软件项目发送代码提交时通常使用的方法。有关 diff 的更多内容，请参看下面 参考资料 部分中有关 Kernel.org 的链接。
) I( F) H3 j0 \
Git 还可以干什么？ ! M% z4 s. T5 `2 U
4 U7 [&&r3 W&&}) v4 L: E" q& T( a3 }
我们可以使用 Git 来管理本地仓库，而不用镜像其他人的工作。例如，如果我们喜欢使用 Git 来管理自己个人对某个开放源码项目贡献的文件，就可以从项目快照中生成一个 Git 仓库。 2 P0 D& E" r6 m: D6 m6 G1 y
假设我们已经有了一个名为 release.tar.gz 的标准 release tarball，可以执行下面的命令来创建一个本地的 Git 仓库：
9 m6 _4 L; i9 T) i/ S&&^5 ]/ B! e# v, R
' ?( L- a7 F/ m* z&&p
$ tar -zxvf release.tar.gz
$ cd release 1 G+ c, B0 ]2 F&&U4 W2 J( `
! v# q2 b% f/ ?6 A- ~
$ git init-db
- J! q, X, q9 R# D" M( I9 j
我们可以看到消息说 Git 是 “默认于本地存储区域的”。这些消息都是正常的，说明我们有一个 Git 仓库。
$ z# H; y4 @- }% H
现在我们已经对工作目录进行了初始化，接下来在项目目录中应该会看到一个新目录 .git。为了告诉 Git 我们希望对这个项目中的每个文件都进行跟踪，请执行下面的命令：
. \; h/ ]; V9 }* h
$ git add ./ `5 v. H9 P, N$ ~
) g. D% D3 x: Z$ y! p. F9 j
% s0 K3 I&&t&&f* |1 O, ^9 ]
最后，使用下面的命令将所监视的文件提交到仓库中：
. L! [1 B* U/ w# p$ j&&v7 _6 M
$ git commit -a# ]2 \&&L& [, t# ^&&C; A2 f( E. c/ H: @
0 _' v9 R1 W& H- Z! I
同样，系统会提示我们输入提交消息。从现在开始，我们就可以在自己的 Git 仓库中使用 Git 所提供的完整功能了，例如对实验特性进行分支，为了追踪回归测试问题而将代码一分为二，并使用常见的版本历史功能。
结束语 / U7 D$ F& @& m. _
现在我们已经知道如何使用 Git 来获取 Linux 内核源代码和其他 Git 管理的项目了，接下来可以选择使用 Git 来管理下一个开发项目。 Git 仍然相对较新，仍然处于不断开发中。其他脚本和工具正在实现用来简化 Git 的使用；请参看 参考资料 中给出的例子。
5 r& }2 P- X+ u6 }) e3 e/ F
非常简单地说，Git 是 Linus Torvalds 最近实现的源代码管理软件。正如所提供的文档中说的一样，“Git 是一个快速、可扩展的分布式版本控制系统，它具有极为丰富的命令集，对内部系统提供了高级操作和完全访问。”
9 z$ w0 k, ^7 s0 L
Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper，后者之前一直是 Linux 内核开发人员在全球使用的主要源代码工具。开放源码社区中的有些人觉得 BitKeeper 的许可证并不适合开放源码社区的工作，因此 Torvalds 决定着手研究许可证更为灵活的版本控制系统。尽管最初 Git 的开发是为了辅助 Linux 内核开发的过程，但是我们已经发现在很多其他自由软件项目中也使用了 Git。例如，X.org 最近就迁移到 Git 上来了，很多 Freedesktop.org 的项目也迁移到了 Git 上。 1 j1 n7 ]2 w# O) T8 f5 e
&&}' O9 a! O6 h& b, r$ R0 e
Git 目前主要由寻找 CVS 或专有代码管理解决方案替代物的软件开发人员所使用。Git 与 CVS 有很多区别：
( x( `) u# o' r+ s+ C" [* i
分支更快、更容易。 + z4 W" K7 g. U: o! ~
支持离线工作；本地提交可以稍后提交到服务器上。
4 _- z8 o5 r( o( R7 k% V3 @
Git 提交都是原子的，且是整个项目范围的，而不像 CVS 中一样是对每个文件的。 1 T" [! c% l. @&&x' C+ _! F9 x
&&`! O; g" A2 Z# L
Git 中的每个工作树都包含一个具有完整项目历史的仓库。 # e8 ~* c* A) b- l0 s: o
没有哪一个 Git 仓库会天生比其他仓库更重要。
要安装当前版本的 Git，我们可以使用供应商在 Linux 发行版中提供的包，或者从最新的稳定快照开始手工进行编译。我建议下载包含最新 Git 源代码稳定快照的 tarball；截止到撰写本文时这个版本是 v1.4.0。我们可以在下面的 参考资料 一节中找到链接。 , |4 F1 @9 F; x% a/ y( W6 l
有了这个 tarball 之后，请确保初始安装所依赖的包都已经安装了。系统中必须包含以下包，以及相应的开发头文件： 7 M&&R- p( H5 g1 P: ~+ |7 ]! w
7 L: }2 s' N# w: C8 k
libcurl : D/ a9 ~&&y9 ~
% r5 Z) }( c/ ]
libcrypto（OpenSSL） &&^" W4 `: I# x! h% T8 _, h
' q3 b# @& `9 h) e
rsync（2.6.0 或更高版本）: L% l, J1 }7 m3 T9 ^# X6 `
: C, s% |: _0 |+ T# k0 H! j
这些条件满足之后，我们就可以开始编译初始的 Git 安装系统了。这个过程对于大部分一直使用 Linux 的开发人员来说应该非常熟悉了。首先使用对应下载的包格式的命令将包展开：
! k: q0 @&&[& g" }' I&&M
$ tar -jxvf git-1.4.0.tar.bz2或
$ tar -zxvf git-1.4.0.tar.gz# f' O4 Z. Q* p1 w- b+ Y% b
/ q3 F: Z& h) O5 U: z# Q7 Y9 a
/ h- e7 h* V" {* @&&}3 I
然后切换到适当的目录中，并执行 make 命令。（注意目录名取决于我们下载的快照的日期。）
% ]" I5 ^. L0 s3 `& I! J
; n$ f, e% c1 @6 z- f2 t& e6 ]( D
$ cd git-1.4.0/9 C7 w% a* \2 z8 m- c
$ make prefix=/usr/local install
$ sudo make prefix=/usr/local install7 V1 h% w3 V/ |
您会被提示输入 sudo 密码才能继续安装。现在就已经准备好使用 Git 工具了。
获得最新的内核源代码树
3 y! o' G. v1 |1 u# p1 _6 i+ a
在使用 Git 管理源代码仓库时，我们可以使用两种方法开始我们的工作。我们可以使用现有代码的一个本地目录，然后从中生成一个仓库；也可以映射其他人发布的仓库。
对于本文的目的来说，我们将获得 Torvalds 发布的 Git 仓库的一个镜像。下面的命令将创建一个名为 linux-2.6 的 Git 仓库。这个目录包含了一个隐藏目录 .git/ 。
$ git-clone&&' v' f) I+ h, W% E7 U9 Y: l5 {
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6$ c& M' ^3 [7 o8 r% p
这个步骤会执行很长时间，因为 Git 正在将内核源代码（这有数百兆大）从 kernel.org 传输到本地机器上。输出结果可能有些晦涩难懂，但是如果您有一个快速的 Internet 链接，卷屏的速度应该相当快。966,690 六月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
版本控制、Git及其在企业中的应用
版本控制、Git及其在企业中的应用
日. 估计阅读时间:
不到一分钟
道AI风控、Serverless架构、EB级存储引擎，尽在!
相关厂商内容
相关赞助商
ArchSummit深圳-8日，深圳&华侨城洲际酒店，
在版本控制中，合并通常是最令人烦恼的一项任务，但Git使这一流程得到了改善，它为不同的合并用例提供了强大的、特定的合并策略。无论你打算合并分支、对分支的origin进行rebase操作、还是需要进行选择性的合并提交，在Git中都能够找到相应的功能以满足你的需求。Git的分布式模型为开发者提供了极大的自由度，他们可以随意选择能够为他们带来最大价值的方式使用版本控制系统。开发者在本地可以尽早提交、频繁提交，而当他们需要将变更交付给属于上游团队的用户时，则可以选择以较大粒度的、更富于逻辑性的块进行提交。
开发者都希望能够按照他们所需的任何方式进行工作，与他们所使用过的其它工具相比，开发者在使用Git时能够对于操作的类型与方式有更细粒度的控制。Git中的大量命令通常可以分为两类：高层命令（porcelain）与底层命令（plumbing）。有人将其比作一个水槽，意思是说：你可以通过传统的工具与高层命令打交道，这部分命令提供了工具的一种抽象和受控的界面。但在Git中，你也可以打开它的面盆、拨出塞子、以改变版本控制执行的方式，包括重写历史等等。无论开发者是否真的需要这种能力，他们总希望能够拥有它，可以随时使用。
但就像其它所有开发工具一样，Git也不是一个完美的方案。Git确实是市场上发展最快的版本控制工具，但对于它的分歧也同样很大。这种分歧不仅包括应当在企业项目中使用还是在开源项目中使用，并且还包括是否应当由独立的开发团队使用还是让整个企业拥抱Git。这种分歧的存在是源于Git这门工具的缺点，而这些缺点与它的优点一样，都显得非常突出。
在2013年， ，以了解在企业中使用Git的最大顾虑是什么。在所有回复中排名前三的分别是安全、治理以及与工具的集成，总监以及更高级别的管理者通常会将安全性视为他们最大的顾虑。那么，为什么这三点会成为在企业中应用Git的障碍呢？
说起来，这还要追溯到这门工具本身的起源，Git最初的目的只是为了实现一个特定的开发方式的流程。虽然Git的设计者很清楚他们需要这一工具处理哪些任务，但他们并不怎么关心其他人如何使用这一工具。当然，随着时间的推移，Git也在不断进化，它也在逐渐地适应其他用户的需求与期望。但它的本质还是以面向开源项目类型的开发为主所设计的工具，对于企业级开发来说仍存在着一些不足之处。
在开源项目开发过程中，整个工作流与企业开发相比有很大的差别。这些项目对于创建分支的需求较低，并且基本没有人关心如何治理，在安全性方面的处理也简化了许多。按照一般开源项目的特性，全球开发者都可以随意读取代码，而写入的权限通常只会给予少部分可信的参与者。而企业的需求则是千变万化的，并且企业中每个项目团队的需求往往也各有差别。企业项目开发通常需要进行更多的分支操作、要求进行详细地管理、需要更细粒度的访问控制、并且需要一些额外的安全措施，例如与企业中的LDAP进行集成。
对于企业来说，问题并不在于每个开发者如何使用Git的功能，而在于如何支持必要的canonical库以及上游团队的流程。由于Git本身并没有canonical库的概念，因此只能以其它方式实现保护核心信任源的任务。举例来说，在本地进行历史重写操作对于开发者来说相当便利，但在严格的配置管理流程中，对canonical服务器进行历史操作会带来一定的风险。
由于企业的需求不同，为了应对这些需求就出现了多种不同的解决方式，而这些方式仍旧能够充分利用Git的各种益处。这些不同的解决方式并不一定是传统意义中的 &fork&，而更像是一种插件、一种封装，只是以不同的手段去克服同样的问题罢了。这也就意味着某个开发团队在使用Git时所选择的架构与同一企业中的另一团队的选择可能是截然不同的，对于企业来说，这一点绝非他们所希望看到的结果。
确实，每个团队使用Git的方式都是不同的。对于团队各自具有不同的工具、流程与实践这一现状，企业总是会例行公事地表示，这些工具都是以一个基础工具为基本的。但他们很快会发现，这些不同的解决方案将限制企业自身的敏捷性与可扩展性。由于企业中的应用程序各自散落在不同的环境与位置，因此没有什么一目了然的方法可以充分地了解这些应用。而因为缺乏对这些应用的可见度，企业就无法维持必要的管理工作，以确保团队成员在各自的流程中都能够做到遵循企业的标准。企业不得不为此投入更多资源，以支持这些不同的解决方案，而这些时间本可以用于为公司创造更多的价值与创新工作。
此外，Git本身也存在着一些缺陷，在大型的代码库不断扩展时，如何保持多个开发团队依然能够高效地开展工作是一项巨大的挑战。另外，Git对于大型二进制文件的支持也有一些局限性。为了应对这些缺陷，大型的应用不得不使用多个代码库以管理所有相关的代码与文件，这又产生了其它的问题。举例来说，企业团队希望能够对完整的应用程序代码执行某些操作（例如创建分支与设置标签等等），无论有多少个代码库牵涉到这一操作。他们希望能够同步地在所有相关的库中执行相同的操作，但在Git中并没有跨多个库的原子操作这一概念。核心Git特性无法处理这一问题，因此企业不得不考虑一些第三方的功能，例如Git Slaves或Android社区的 repo工具。
另一方面，Git的分支与合并操作所针对的是整个代码库，因此Git库与应用程序之间被限制为一种1对1的关系。如果某个企业通过一个单一的库保存多个相关应用的所有资源，为了隔离某个特定应用程序的开发与文档里程碑，他们就不得不为每个应用程序创建一个单独的库。这一结果所带来的影响不仅在于库的数量大大提高了，而且还需要对构建、签出以及安装流程和脚本进行修改，以应对代码库结构的变化。
另外，由于Git本身就具有克隆的这种底层概念，因此用户和项目团队可能会倾向于对应用程序和模块进行fork，而没有考虑如何更恰当地使用分支操作。在开发应用的新发布时，不应在上一个发布的项目上创建一个新的代码库，而是应当在现有的代码库中为新的发布创建一个全新的分支。当团队需要修改一个共享的组件或库时，也应当遵循相同的策略。分支能够将工作进行隔离，甚至对某个通用的基础组件或类库来说，也能够将一些独立的变更进行隔离，但这些分支应当存在于一个通用的库中，让使用这部分代码的用户能够对其进行评估及应用。
最后，对于多数企业来说，代码的重用以及对第三方库的利用都会被视为一种理想的方式。但对于这方面的需求，Git也无法给出完美的答复。企业可以尝试使用Git中的子模块，这个功能在标准的Git包中就已经存在了，但实现这一点需要每个开发者掌握更多的实现方面的知识，以及操作的步骤。当然，他们也可以选择使用Git子树功能，但他们必须确保建立起合适的关联，以拉取这些代码，并以适当的方式使用它。由于这两种方案都有其弊端所在，企业可能会因此寄希望于更好的解决方案的出现。
需要考虑的问题
从以上分析可以看出，Git的优点与缺点都是非常显著的，这让人有些不知所措。如果你仍然希望将现有的产品或应用从其它的版本控制工具中迁移至Git，那么你需要考虑以下几个问题：
在版本控制方面，怎样的流程才能够最好地满足你的需求？
你的组织在治理与安全方面有哪些需求？
有哪些工具、服务与流程需要与Git进行集成，又有哪些数据需要进行迁移？
如何对使用者进行Git与流程方面的培训？
首先，在版本控制方面，怎样的流程才能够最好地满足你的需求？有许多组织都是这样想的：虽然我需要将数据迁移到一种不同的结构中，但仍然可以使用相同的流程，而不用做出任何变化。这些组织没有认识到一点，即他们的流程往往是由所选择的工具的长处（以及短处）等因素而定型的。要在一个本质上完全不同的工具，例如Git中照搬现有的流程，很可能会导致一种&格格不入&的尴尬境地。因此，你应当重新审视一下你的基本需求，并采用Git的最佳实践以打造一种全新的流程，让它既能够满足你的需求，同时也能够充分利用Git的强大功能。
人们总是认为，对于一种特定的工具来说，只存在着唯一一种进行分支与合并操作的最佳实践模型。而实际上，分支操作是由于对隔离的需求而产生的，而不是由某个工具的功能所决定的。GitFlow通常被人们错误地认为是一种专属于Git的分支与合并模型，但除了它的名字与相关的脚本之外，它与Git并没有直接的关联，完全可以应用于其它版本控制工具。
几乎所有的分支模型都属于两种基本方式之一，选择哪种方式要根据对并行发布式开发过程支持的需求而决定。其中，不稳定的master方式在设计时所针对的开发方式主要专注于在任一时间只有一个新发布的情况，大多数开源项目就属于这种情况，因为它们的工作周期较短。而稳定的master方式在设计时所针对的开发方式专注于同时进行多个发布的情况，这正是多数企业中所采用的开发方式。
GitFlow初看上去似乎是基于稳定的master方式而设计的，因为代码的签入工作通常不会直接发生在master分支上。但实际上，GitFlow的设计目标是基于不稳定master基础的方式，支持连续的发布，只是将这种不稳定性从master分支转移到一个通用的、连续的开发分支而已。因此，对于企业应用来说，GitFlow这种方式作为一个最佳实践的吸引力有所降低，也难以成为Git这门工具的一种标准用途。
其次，你需要问问你自己，你的组织在治理与安全方面有哪些需求？你是否需要一种比代码库更底层的访问控制？你是否需要通过角色的方式定义一些通用的访问规则，并将其应用到进行应用程序开发的多个团队之间？你是否需要选择一种单一的帐号与密码源？你是否已经定义好一组流程，让团队能够遵循，你也可以进行监控它们的实施情况？通过回答以上问题，能够帮助你定义必需的访问控制，以及回顾那些能够满足这些需求的流程。或者，在回答这些问题的过程中，你可能会发现Git并不是你的企业、或是某个特定项目的最佳选择。
在安全与治理方面的需求并不代表不能够使用Git，但这意味着你必须找到一种合适的封装，让它提供这些额外的功能。你需要找到一种这样的封装，它能够满足组织中的多个开发团队所表现出的各种需求。在没有治理方面的需求时，它应当能够让变更直接应用到canonical库中。而一旦治理成为一种需求，它应当能够强制实施一些必须在变更应用到代码库之前所遵循的一些流程，同时又保证能够在团队这一层级上定义这种流程。为了支持企业在中央式治理能力与可见性方面的需求，需要提供一种唯一的封装能力。
是一个开源的解决方案，它能够满足这方面的需求。其实Gerrit原本是设计为一种专门支持代码审查的工具，它的设计方式是只允许已批准的提交可以公开访问。但它还提供了一些额外的功能，以支持企业对于安全与治理方面的需求。它将每个代码库都视为一个项目，能够应用不同的安全与治理策略。它还能够在分支级别以及对特定的操作定义访问控制权限，这些操作包括标签以及推送合并。Gerrit还提供了对LDAP的集成，以满足有这方面需求的企业。作为企业级Git解决方案来说，Gerrit是一个完美的示例。
再次，你需要决定有哪些工具、服务与流程需要与Git进行集成，又有哪些数据需要进行迁移？为了成功地实现这一过程，你需要拥有一个平台与合作伙伴，以得到必要的工具。此外，你还需要充分地评估有哪些数据需要迁移至Git。对于某些环境来说，完整的历史迁移是不必要的（或者说是不可能的）。
曾几何时，版本控制工具被视为软件开发这片汪洋中的一座孤岛，这种观念现在已经一去不复返了。企业需要与集成开发环境（IDE）、问题管理工具、测试工具、构建工具与DevOps流程进行无缝的整合，而这些工具中也有相当一部分需要进行相互整合。你需要做的是找出在你的组织里使用了哪些工具、将这些工具与现有的版本控制工具进行整合，或是与额外的版本控制工具进行整合将带来哪些头信息。在完成这些工作后，你就能够通过一个支持这种整合的平台，从你的Git环境中获取最大的价值。
如果你曾经转移过你的个人资产，你就可以将它与从一个版本控制工具转到另一个工具的挑战进行类比。你需先要评估，在新的环境之中，哪些东西是无用的，哪些东西是现在可能不需要，但一旦出现相关需求时就必需用到的。你是否有过帮朋友进行搬家的经历？如果你的朋友打算把所有的一切全都打包搬走，而新的住所还比原来的更小，那种经历应当不会很美妙。历史信息确实是版本控制数据的核心，但大多数历史信息的价值只体现在一段有限的时间之内。并且，各种工具所提供的特性不同、实现常见特性的方式不同、保存数据的方式也不同。你需要认真地评估，哪些数据可以被迁移，以及哪些数据确实需要被迁移。把剩余的部分留在遗留的系统中别去管它。
最后，你将如何对使用者进行Git与流程方面的培训？不要单纯地因为Git是一个开源工具，就认为用户能够简单地了解它。Git是一个复杂的工具，它与你平日的工作方式有着很大的差异。你需要通过诸如午餐学习时间 、基于web的学习课程、以及引导式的培训课程等方式让你的团队加快掌握Git的步伐。对于这方面的专家代表来说，你需要让他们与真正的专家进行互动，以及提供额外的动手实践的机会，让他们成为企业中能够对Git进行第一线支持的人员。用户在培训中需要了解这一工具的功能，还需要通过专门的培训以了解企业或项目团队如何使用Git。流程的培训也非常重要，但需要另行安排。
Git能够带来各种益处，这使它成为了如今成长最快的版本控制解决方案。通过了解它的益处、它的限制、它的工作方式、它如何满足你的业务需求、以及你需要在哪些方面补充它的不足，你才能够决定Git是否是适合你的企业的正确工具。
Bob Jenkins是CollabNet版本控制服务部门的总监，在过去的19年中，他始终专注于应用程序生命周期管理工具，尤其关注版本控制工具，包括ClearCase、Subversion以及Git。在CollabNet工作的14年间，他的主要工作是为那些计划实施Git与Subversion的企业提供顾问服务，并且为他们提供这两种版本控制工具的终端用户培训教材。他已经为上百家企业提供了顾问服务，帮助他们成功地在企业中实施所选择的版本控制工具。
查看英文原文：
Author Contacted
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
订阅InfoQ每周精要，加入拥有25万多名资深开发者的庞大技术社区。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
找回密码....
InfoQ账号使用的E-mail
关注你最喜爱的话题和作者
快速浏览网站内你所感兴趣话题的精选内容。
内容自由定制
选择想要阅读的主题和喜爱的作者定制自己的新闻源。
设置通知机制以获取内容更新对您而言是否重要
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。