一个成功的Git分支模型

能力所限,本文的翻译多处都很不地道,如果哪些地方难于理解,还烦请查看原文。 在本文中,我向大家介绍的是在大约一年前我为自己的项目(包括工作和私人项目)引入的且已被证实非常成功的一个开 发模型(development model)。这段时间我一直想写点关于它的东西,但在此之前,我却从未能抽出充足的时间来完成这件事。我不会谈论项目的任何细节,只涉及分支策略 (branching strategy)和发布管理(release management)。 它的焦点是Git,我们所有源码的版本管理工具。

CentOS 6.5下Git服务器搭建

1 关于版本控制 版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统。有以下三种版本控制系统: 1. 本地版本控制系统 许多人习惯用复制整个项目目录的方式来保存不同的版本,或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单。不过坏处也不少:有时候会混淆所在的工作目录,一旦弄错文件丢了数据就没法撤销恢复。 为了解决这个问题,人们很久以前就开发了许多种本地版本控制系统,大多都是采用某种简单的数据库来记录文件的历次更新差异。图示如下,   2. 集中化的版本控制系统 集中化的版本控制系统( Centralized Version Control Systems,简称 CVCS )能够让在不同的开发系统上的开发人员协同工作。这类系统,诸如 CVS,Subversion 以及 Perforce 等,都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。多年以来,这 已成为版本控制系统的标准做法   3. 分布式版本控制系统 分布式版本控制系统(Distributed Version Control System,简称 DVCS ),像 Git,Mercurial,Bazaar 以及 Darcs 等,客户端并不只提取最新版本的文件快照,而是把代码仓库完整地镜像下来。这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来 的本地仓库恢复。因为每一次的提取操作,实际上都是一次对代码仓库的完整备份, 更进一步,许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此,你就可以在同一个项目中,分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程,比如层次模型式的工作流,而这在以前的集中式系统中是无法实现的。