Git简介和基础操作

本文原作者鲍晓攀

1. Git简介：

    Git最初是在2005年由Linux之父Linus TorvaLinus领导开发的一套为Linux内核维护的版本管理系统，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。它的速度飞快，极其适合管理大项目，它还有着令人难以置信的非线性分支管理系统，可以应付各 种复杂的项目开发需求。

•     集中式和分布式

    诸如 CVS，Subversion 以及 Perforce等这些版本管理系统，他们都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新：
    像 Git，Mercurial，Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。如果任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地 仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份：

•     Git的三种状态

              Git 和其他版本控制系统的主要差别在于，Git 只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异。对于任何一个文件，在 Git 内都只有三种状态：已提交（committed），已修改（modified）和已暂存（staged）。已提交表示该文件已经被安全地保存在本地数据库 中了；已修改表示修改了某个文件，但还没有提交保存；已暂存表示把已修改的文件放在下次提交时要保存的清单中。由此我们看到 Git 管理项目时，文件流转的三个工作区域：Git 的工作目录，暂存区域，以及本地仓库。

•     Git和SVN的比较

             

              从本地分支分支维护的层面讲，图中Git本地和服务器端结构都很灵活，所有版本都存储在一个目录中，你只需要进行分支的切换即可达到在某个分支工作的效 果。而SVN则完全不同，如果你需要在本地试验一些自己的代码，只能本地维护多个不同的拷贝，每个拷贝对应一个SVN服务器地址。

              分布式对于Git而言，你可以本地提交代码，所以在上面的图中，Git有利于将一个大任务分解，进行本地的多次提交，而SVN只能在本地进行大量的一次性 更改，导致将来合并到主干上造成巨大的风险。Git的代码日志是在本地的，可以随时查看。SVN的日志在服务器上的，每次查看日志需要先从服务器上下载下 来。

              Git和SVN的主要区别，归纳起来主要有以下5点：

              1）GIT是分布式的，SVN不是：

                   这是GIT和其它非分布式的版本控制系统，例如SVN，CVS等，最核心的区别。如果你能理解这个概念，那么你就已经上手一半了。需要做一点声明，GIT 并不是目前第一个或唯一的分布式版本控制系统。还有一些系统，例如Bitkeeper, Mercurial等，也是运行在分布式模式上的。但GIT在这方面做的更好，而且有更多强大的功能特征。GIT跟SVN一样有自己的集中式版本库或服务器。但，GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。可以这样说，如果你被困在一个不能连接网络的地方时，就像在飞机上，地下室，电梯里等，你仍然能够提 交文件，查看历史版本记录，创建项目分支，等。对一些人来说，这好像没多大用处，但当你突然遇到没有网络的环境时，这个将解决你的大麻烦。同样，这种分布式的操作模式对于开源软件社区的开发来说也是个巨大的恩赐，你不必再像以前那样做出补丁包，通过email方式发送出去，你只需要创建一个分支，向项目团队发送一个推请求。这能让你的代码保持最新，而且不会在传输过程中丢失。

               2）GIT把内容按元数据方式存储，而SVN是按文件：

                   所 有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。如果你把.git目录的体积大小跟.svn比较，你会发现它们差距很 大。因为,.git目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。

               3）GIT分支和SVN的分支策略不同：

                   分支在SVN中一点不特别，就是版本库中的另外的一个目录。如果你想知道是否合并了一个分支，你需要手工运行像这样的命令svn propget svn:mergeinfo，来确认代码是否被合并。 然而，处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支，你能简单而快捷的合并这些文件。

               4）GIT没有一个全局的版本号，而SVN有：

                   目前为止这是跟SVN相比GIT缺少的最大的一个特征。你肯定知道，SVN的版本号实际是任何一个相应时间的源代码快照。

               5）GIT的内容完整性要优于SVN：

                   GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。

•     如何理解Git的分布式 & 我们为什么要用Git

              去中心化：去中心化绝对是Git最伟大的改变，每个人机器上都是一个完整的库， 我们平时开发代码时的中央服务器其实和我们自己机器上的库内容是完全一样的（格式有点不同，是bare的）。虽然平时大家 都是将代码提交到中央服务器上再统一pull别人的代码，但实际情况你可以总是pull张三的库，然后push给李四等等操作。如果你用过Github， 你肯定知道大名鼎鼎的fork功能，你可以fork任何一个你喜欢的项目，接着按自己的喜好修改成自己的项目，或是发起pull request请原作者merge你的功能到他们项目里去（这同样也得益于Git另一项与SVN很大不同的功能------上面提到的第3小点：分支策 略），而且大多数开源项目都会鼓励你去fork它们。这里面没有权威，没有主从。

              离线提交：本地的离线提交好处主要有以下几个：

                   1）断网提交。不要认为这个没用，想想上面提到的例子：在火车飞机或是脱离网络需要工作的情况。

                   2）小步提交。可以对自己的阶段成果有跟踪，并且提高每次变更的安全性。

                   3）本地库。这个和断网提交是同一个实现，但从需求角度出发则略有不同，主要是说即使只有自己一个人开发项目，也可以轻易的让自己的代码有版本跟踪，而不需要去费力建个什么svn server。

                   4）本地回滚。这个其实是由于本地库的存在而产生的，但可以减少中央库上的冗余版本。

              分支策略：分支策略从技术上来讲是将版本节点化了，即最终的版本状态是树状的。从结果上来讲既是弱化了分支，也是强化了分支。弱化的是分支的概念，强化的是分支的功能。分之策略是Git最强大的功能，没有之一。请大家日后慢慢体会。

              当然，Git其实还有很多其他的有点，大家用熟悉了以后就自然和SVN有一个比较鲜明的对比了。

2. Git基础命令及演示：

•     首次运行Git前的配置：

              -> /etc/gitconfig文件：系统中对所有用户都普遍适用的配置。若使用 git config 时用 --system 选项，读写的就是这个文件。

              -> ~/.gitconfig 文件：用户目录下的配置文件只适用于该用户。若使用 git config 时用 --global 选项，读写的就是这个文件。

              -> 当前项目的 git 目录中的配置文件（也就是工作目录中的 .git/config 文件）：这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置，所以 .git/config 里的配置会覆盖 /etc/gitconfig 中的同名变量。

              -> 在 Windows 系统上，Git 会找寻用户主目录下的 .gitconfig 文件。主目录即 $HOME 变量指定的目录，一般都是 C:\Documents and Settings\$USER。此外，Git 还会尝试找寻 /etc/gitconfig 文件，只不过看当初 Git 装在什么目录，就以此作为根目录来定位。

              必要配置：你个人的用户名称和电子邮件地址，以及编辑器。这两条配置很重要，每次 Git 提交时都会引用这两条信息，说明是谁提交了更新，所以会随更新内容一起被永久纳入历史记录：

$ git config --global user.name "鲍晓攀"
$ git config --global user.email [e-mail]
$ git config --global core.editor vim
$ git config --global push.default simple
$ git config --list

              如果用了 --global 选项，那么更改的配置文件就是位于你用户主目录下的那个，以后你所有的项目都会默认使用这里配置的用户信息。

•     基础操作：添加和提交、推送改动、分支操作、更新合并、替换回退、创建标签：

#检出仓库：
#执行如下命令以创建一个本地仓库的克隆版本：
git clone /path/to/repository

#如果是远端服务器上的仓库，你的命令会是这个样子：
git clone username@host:/path/to/repository


#创建新仓库:
#创建新文件夹，打开，然后执行
git init
#以创建新的 git 仓库。


#添加与提交：
#你可以计划改动（把它们添加到缓存区），使用如下命令：
git add <filename>
git add *
#这是 git 基本工作流程的第一步；

使用如下命令以实际提交改动：
git commit -m "代码提交信息"
#现在，你的改动已经提交到了 HEAD，但是还没到你的远端仓库。


#推送改动：
#你的改动现在已经在本地仓库的 HEAD 中了。执行如下命令以将这些改动提交到远端仓库：
git push origin master
#可以把 master 换成你想要推送的任何分支。

#如果你还没有克隆现有仓库，并欲将你的仓库连接到某个远程服务器，你可以使用如下命令添加：
git remote add origin <server>
#server e.g: 在中心服务器建好的远程项目：[e-mail]:xiaopan.baoxp/test.git
#如此你就能够将你的改动推送到所添加的服务器上去了。


#分支：
#分支是用来将特性开发绝缘开来的。在你创建仓库的时候，master 是“默认的”。在其他分支上进行开发，完成后再将它们合并到主分支上。
#创建一个叫做“feature_x”的分支，并切换过去：
git checkout -b feature_x

#切换回主分支：
git checkout master

#再把新建的分支删掉：
git branch -d feature_x

#除非你将分支推送到远端仓库，不然该分支就是 不为他人所见的：
git push origin <branch>
#默认git push会推送到你当前所指向的分支


#更新与合并：
#要更新你的本地仓库至最新改动，执行：
git pull
#以在你的工作目录中 获取（fetch）并合并（merge）远端的改动。

#要合并其他分支到你的当前分支（例如 master），执行：
git merge <branch>
#两种情况下，git 都会尝试去自动合并改动。不幸的是，自动合并并非次次都能成功，并可能导致 冲突（conflicts）。 这时候就需要你修改这些文件来人肉合并这些 冲突（conflicts） 了。

改完之后，你需要执行如下命令以将它们标记为合并成功：
git add <filename>

#在合并改动之前，也可以使用如下命令查看：
git diff <source_branch> <target_branch>


#标签：
#在软件发布时创建标签，是被推荐的。这是个旧有概念，在 SVN 中也有。可以执行如下命令以创建一个叫做 1.0.0 的标签：
git tag 1.0.0 1b2e1d63ff
#1b2e1d63ff 是你想要标记的提交 ID 的前 10 位字符。

#使用如下命令获取提交 ID：
git log
#你也可以用该提交 ID 的少一些的前几位，只要它是唯一的。


#替换本地改动：
#假如你做错事（自然，这是不可能的），你可以使用如下命令替换掉本地改动：
git checkout -- <filename>
#此命令会使用 HEAD 中的最新内容替换掉你的工作目录中的文件。已添加到缓存区的改动，以及新文件，都不受影响。

#假如你想要丢弃你所有的本地改动与提交，可以到服务器上获取最新的版本并将你本地主分支指向到它：
git fetch origin
git reset --hard origin/master

3. Git典型分支管理策略和开发模型介绍：

      这里仅仅介绍的是最主流最简单的一个模型，具体的更多的模型，详见官方文档：分布式 Git - 分布式工作流程

•     主分支master：

              首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。Git主分支的名字，默认叫做Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。

•     开发分支develop：

              主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。
              这里顺便给大家讲一下Git合并过程中的FF模式和Normal模式，默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向Develop分支。FF模式使用的命令是：

# 对Develop分支进行非ff模式合并（--no-ff指定非快进式合并）
git merge --no-ff develop

              用两幅图来说明一下区别：
              从上面两幅图可以看出，使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。刚好我这里也有一个现成的例子：

              --no-ff: http://gitlab.alibaba-inc.com/xiaopan.baoxp/bobtest/network/master

              normal: http://gitlab.alibaba-inc.com/xiaopan.baoxp/releasecenter/network/master

•     临时性分支：功能（feature）分支、预发布（release）分支、修复（hotfix）分支：

              前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：功能（feature）分支、预发布（release）分支、修复（hotfix）分支。这三种分支都属于临时性需要，使用完以后，应该删除（这和svn有很大的区别，svn是不鼓励甚至是禁止进行删除操作的），使得代码库的常设分支始终只有Master和Develop。

•               功能分支：从Develop分支上面分出来，开发完成后，要再并入Develop

  #创建一个功能分支：
  git checkout -b feature-x develop
  
  #开发完成后，将功能分支合并到develop分支： git checkout develop
  git merge --no-ff feature-x
  
  #删除feature分支：
  git branch -d feature-x

  

•               预发布分支：是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。

  #创建一个预发布分支：
  git checkout -b release-1.2 develop
  
  #确认没有问题后，合并到master分支：
  git checkout master
  git merge --no-ff release-1.2
  
  #对合并生成的新节点，做一个标签
  git tag -a 1.2
  
  #再合并到develop分支：
  git checkout develop
  git merge --no-ff release-1.2
  
  #最后，删除预发布分支：
  git branch -d release-1.2

•              修复分支：软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。

  #修补结束后，合并到master分支：
  git checkout master
  git merge --no-ff fixbug-0.1
  git tag -a 0.1.1
  
  #再合并到develop分支：
  git checkout develop
  git merge --no-ff fixbug-0.1
  
  #最后，删除"修补bug分支"：
  git branch -d fixbug-0.1
  

  

4. Git的权限控制：

    我们公司用的是Gitlab，所以这里就针对Gitlab的权限控制进行一个简要的说明，Gitlab中对权限的分配大致有2中情况：

    1）用户授权：

         添加仓库的新成员：

         在一个仓库的首页可以看到如下的一个操作区
         选择 Team 标签，会列出当前的仓库的所有成员

         点击 就可以添加新的仓库成员

         在新的添加用户的界面中（如下）可以选择要添加的新用户的名字，用户的角色( 包括 guest,reporter,developer,master )

         选择好对应的角色名称和对应的权限之后就可以点击保存了，这样就添加了一个团队的成员。

         仓库成员的权限介绍：* Guest:

• • 创建一条issue
  • 进行代码的评论
  • 在项目强上面留言
• Reporter:
  • 包括所有 Guest 的权限
  • 拉取项目的代码
  • 下载项目代码
  • 创建一个 merge 请求
  • 创建一个代码片段
• Developer:
  • 包括所有 Reporter 的权限
  • 创建新分支
  • 向非受保护分支推送代码
  • 删除非受保护分支
  • 添加 tags
  • 编辑项目的 wiki
• Master:
  • 包括所有 Developer 的权限
  • 添加新的团队的成员
  • 向受保护分支推送代码
  • 删除受保护的分支
  • 使用“强制”选项进行推送
  • 编辑项目
  • 添加项目的只读授权 key
  • 配置项目Git Hooks

    2）密钥授权：

         在你的个人profile页面：http://gitlab.alibaba-inc.com/profile，可以添加ssh key，在添加了ssh key之后，你所在的机器就可以访问你所拥有权限的任何项目了：

         添加key时请慎重，因为这意味着所有能访问这台机器的人都可以对你的项目进行操作，一般对于开发人员来说，都会给自己的开发机加上key。

         除此以外，还需要注意，一个key只能加一次，再次添加就会出错，举个例子：我在我的配置里添加了A机器的key，然后风伯想要在他的配置里加上A的key，就会失败。

5. Git中的MarkDown说明文件介绍：

•     使用MarkDown语法的README文件

              在Github中的项目主页里，我们经常可以看到一个README.md文件，这个文件就是使用markdown语法编写的说明文件，添加合适的README文件是一个很好的习惯。这里具体的语法就不做介绍了，请自行参看上面的链接。另外，还有很多的在线编辑器，如以下两个：http://dillinger.io/， http://markable.in/editor/

6. 定制自己的Git：

•     配置 .gitconfig：这一内容已经在第2点中的第一小点中做过说明，这里不再做重复说明，举例一些常用的缩写，如：

  [user]
          name = Bob
          email = [e-mail]
  [color]
          ui = true
  [format]
          #pretty = short
          #pretty = format:"%h - %ae: %s"
  [core]
          editor = vim
  [alias]
          last = log -1 HEAD
          co = checkout
          br = branch
          ci = commit
          st = status
  [merge]
          tool = vimdiff

                此外，如果加入 .git-completion.bash 文件的话，还可以实现git命令行的自动补全，附件在这里：.git-completion.bash

7. Git的一些可编程扩展库：

•     libgit2：

              这个简直碉堡，支持Linux, FreeBSD, OpenBSD, Mac OS X, iOS, Amiga, MinGW and fully native Windows. 支持各类语言，比如python，perl，lua，erlang，c++，node.js等等，具体用法请访问主页参考使用手册。

8. 推荐几个资源

•     我们公司用的是Gitlab，较Github属于轻量级产品，内部有一个文档：http://gitlab.alibaba-inc.com/gitlab-help，不过这个页面由于没有加到统一账户登录中心貌似暂时访问不了，我自己找了一台服务器搭了一个服务，可以访问以下网址查看：http://10.250.4.42/gitlab-help/pages/index.html

•     我自己整理了个比较主流的帮助页面，大家有空可以翻翻：http://scmbob.org/git-help.html

 

评论

1 楼 缘字訣 2013-11-25  

图片看不了啊