分类: 项目管理
2013-06-10 11:13:35
Git版本控制系列相关文章:
如果你严肃对待编程,就必定会使用"版本管理系统"(Version Control System)。
眼下最流行的"版本管理系统",非Git莫属。
源代码管理(SCM)系统不是什么新思想。为了编写一些能够更快速、简单地开发以后软件项目的软件,已经进行了很多尝试。最新的源代码解决方案都包 含了版本控制系统,它可以对源代码的修改进行回滚,从而将有害的代码剔除出项目之外,或者简单地跟踪哪些人修改了代码的哪些行的内容。版本控制系统试图解 决开发人员在试图同时对某个文件进行修改时所出现的冲突问题,可以防止用户覆盖其他人所作的修改。源代码管理使用的很多流行解决方案都试图解决以前 SCM 解决方案中的失效问题。
集中化的版本控制系统通常采用两种方式:
有些提供了文件锁来防止多个用户的并行访问。这些系统对文件进行加锁,这样在某个时间只有一个开发人员对中心仓库具有写入权限。
另外一些工具,例如 CVS,允许多个开发人员同时对相同的文件进行编辑,并提供了一些机制稍后合并这些修改。
流行的版本控制系统包括:
emerge -av git
即可完成git及其依赖的编译和安装。
git config --global user.name "Your Name"
git config --global user.email "youremail@domain.com"
切换到工程目录,执行
git init
进行初始化工作
git status
查看git的状态
使用命令
git add
git add . 添加目录下的所有文件
使用命令
git commit -m "your commitment"
进行向版本库提交
通过使用命令
git log
查看提交的日志记录
下面修改下目录中test1.cpp文件,添加一行,删除两行
然后执行git status查看状态:
添加并提交修改:
分支更快、更容易。
首先,代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本,都在这个主分支上发布。
Git主分支的名字,默认叫做Master。它是自动建立的,版本库初始化以后,默认就是在主分支在进行开发。
创建分支:
主分支只用来分布重大版本,日常开发应该在另一条分支上完成。我们不妨把开发用的分支,叫做Develop。
这个分支可以用来生成代码的最新隔夜版本(nightly)。如果想正式对外发布,就在Master分支上,对Develop分支进行"合并"(merge)。
下面是几个有关分支的命令:
git checkout -b develop master #创建develop分支
git checkout master #切换分支到master
git merge --no-ff develop #对develop进行分支合并
默认情况下,Git执行"快进式合并"(fast-farward merge),会直接将Master分支指向Develop分支。使用--no-ff参数后,会执行正常合并,在Master分支上生成一个新节点。为了保证版本演进的清晰,我们希望采用这种做法。
前面讲到版本库的两条主要分支:Master和Develop。前者用于正式发布,后者用于日常开发。其实,常设分支只需要这两条就够了,不需要其他了。
但是,除了常设分支以外,还有一些临时性分支,用于应对一些特定目的的版本开发。临时性分支主要有三种:
这三种分支都属于临时性需要,使用完以后,应该删除,使得代码库的常设分支始终只有Master和Develop。
它是为了开发某种特定功能,从Develop分支上面分出来的。开发完成后,要再并入Develop。
它是指发布正式版本之前(即合并到Master分支之前),我们可能需要有一个预发布的版本进行测试。
预发布分支是从Develop分支上面分出来的,预发布结束以后,必须合并进Develop和Master分支。它的命名,可以采用release-*的形式。
软件正式发布以后,难免会出现bug。这时就需要创建一个分支,进行bug修补。
修补bug分支是从Master分支上面分出来的。修补结束以后,再合并进Master和Develop分支。它的命名,可以采用fixbug-*的形式。