Git版本控制--Git的初始设置和使用

久之前就听说版本控制器，而Git是一款优秀的版本控制软件。因为没有多大的团队合作过什么项目，所以也没有好好学习使用。下面就学习下，方便以后自己对项目的管理。

Git版本控制系列相关文章：

如果你严肃对待编程，就必定会使用"版本管理系统"（Version Control System）。
眼下最流行的"版本管理系统"，非Git莫属。

1.什么是Git?

源代码管理（SCM）系统不是什么新思想。为了编写一些能够更快速、简单地开发以后软件项目的软件，已经进行了很多尝试。最新的源代码解决方案都包 含了版本控制系统，它可以对源代码的修改进行回滚，从而将有害的代码剔除出项目之外，或者简单地跟踪哪些人修改了代码的哪些行的内容。版本控制系统试图解 决开发人员在试图同时对某个文件进行修改时所出现的冲突问题，可以防止用户覆盖其他人所作的修改。源代码管理使用的很多流行解决方案都试图解决以前 SCM 解决方案中的失效问题。

集中化的版本控制系统通常采用两种方式：
有些提供了文件锁来防止多个用户的并行访问。这些系统对文件进行加锁，这样在某个时间只有一个开发人员对中心仓库具有写入权限。
另外一些工具，例如 CVS，允许多个开发人员同时对相同的文件进行编辑，并提供了一些机制稍后合并这些修改。

流行的版本控制系统包括：

• CVS
• Subversion
• Arch
• Bazaar
• BitKeeper

 

Git 是 Linus Torvalds 最近实现的源代码管理软件。正如所提供的文档中说的一样，“Git 是一个快速、可扩展的分布式版本控制系统，它具有极为丰富的命令集，对内部系统提供了高级操作和完全访问。”

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

Git 目前主要由寻找 CVS 或专有代码管理解决方案替代物的软件开发人员所使用。Git 与 CVS 有很多区别：

• 2. 软件的安装

  Linux下安装git不是什么问题，比如我的机器（Gentoo Linux），直接命令

  emerge -av git

  即可完成git及其依赖的编译和安装。

  3. 软件的基本使用

  安装完成后先进行基本的设置

  git config --global user.name "Your Name"
  git config --global user.email "[e-mail]"

  切换到工程目录，执行

  git init

  进行初始化工作
  

  使用命令

  git status

  查看git的状态

  
  

   

  使用命令

  git add 添加某个文件
  git add . 添加目录下的所有文件

  

   

  使用命令

  git commit -m "your commitment"

  进行向版本库提交

   

  

  通过使用命令

  git log

  查看提交的日志记录

   

  
  

  下面修改下目录中test1.cpp文件，添加一行，删除两行

  然后执行git status查看状态：

  

  添加并提交修改：

  

  分支更快、更容易。
• 支持离线工作；本地提交可以稍后提交到服务器上。
• Git 提交都是原子的，且是整个项目范围的，而不像 CVS 中一样是对每个文件的。
• Git 中的每个工作树都包含一个具有完整项目历史的仓库。

  4. Git中分支(Branch)的使用

  首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。

  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分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。

   

  

  5. 其他类型的几种分支

  前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。
  但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：

  • 　　功能（feature）分支
  • 　　预发布（release）分支
  • 　　修补bug（fixbug）分支

  这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。

   

   

  5.1 功能分支

  它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。

   

   

  5.2 预发布分支

  它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。

  预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。

   

   

  5.3 修补bug分支

  软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。
  修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。

  
  

• 没有哪一个 Git 仓库会天生比其他仓库更重要。