共计 9590 个字符，预计需要花费 24 分钟才能阅读完成。
1 关于版本控制
版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。有以下三种版本控制系统：
1. 本地版本控制系统
许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单。不过坏处也不少：有时候会混淆所在的工作目录，一旦弄错文件丢了数据就没法撤销恢复。
为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。图示如下，
2. 集中化的版本控制系统
集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）能够让在不同的开发系统上的开发人员协同工作。这类系统，诸如 CVS，Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法
基于 Gitolite 的 Git 服务架设 http://www.linuxidc.com/Linux/2014-02/96991.htm
Fedora 通过 Http Proxy 下载 Git http://www.linuxidc.com/Linux/2009-12/23170.htm
在 Ubuntu Server 上安装 Git http://www.linuxidc.com/Linux/2009-06/20421.htm
服务器端 Git 仓库的创建（Ubuntu）http://www.linuxidc.com/Linux/2011-02/32542.htm
Linux 下 Git 简单使用教程（以 Android 为例）http://www.linuxidc.com/Linux/2010-11/29883.htm
Git 权威指南 PDF 高清中文版 http://www.linuxidc.com/Linux/2013-10/91053.htm
3. 分布式版本控制系统
分布式版本控制系统(Distributed Version Control System，简称 DVCS), 像 Git，Mercurial，Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份,
更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。
2 关于 Git
Git 是分布式版本控制系统的一个完美实现，它与集中式版本控制系统 SVN 的基本区别如下：
Git 是分布式的，而 SVN 不是
Git 和 SVN 一样有自己的集中式版本库或服务器。但，GIT 更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库 / 服务器上 chect out 代码后会在自己的机器上克隆一个自己的版本库。
Git 将内容按元数据方式存储，而 SVN 是按文件
所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs 等的文件夹里。如果你把.git 目录的体积大小跟.svn 比较，你会发现它们差距很大。因为,.git 目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。
Git 分支和 SVN 分支的不同
SVN 的分支就是版本库中的另外一个目录，而 Git 的分支却是整个版本库的一个快照，而且可以在同一个工作目录下快速的在几个分支间切换。
Git 没有一个全局的版本号，而 SVN 有
SVN 的版本号实际是任何一个相应时间的源代码快照。而 Git 并没有这样的一个全局版本号，这也是 Git 缺少的最大的一个特征
Git 的内容完整性要优于 SVN
Git 的内容存储使用的是 SHA- 1 哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。
Git 的基本工作流程如下：
- 在工作目录中修改某些文件。
- 对修改后的文件进行快照，然后保存到暂存区域。
- 提交更新，将保存在暂存区域的文件快照永久转储到 Git 目录中。
更多详情见请继续阅读下一页的精彩内容：http://www.linuxidc.com/Linux/2014-06/103885p2.htm
2 关于 Git
——————————————————————————–
Git 是分布式版本控制系统的一个完美实现，它与集中式版本控制系统 SVN 的基本区别如下：
Git 是分布式的，而 SVN 不是
Git 和 SVN 一样有自己的集中式版本库或服务器。但，GIT 更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库 / 服务器上 chect out 代码后会在自己的机器上克隆一个自己的版本库。
Git 将内容按元数据方式存储，而 SVN 是按文件
所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs 等的文件夹里。如果你把.git 目录的体积大小跟.svn 比较，你会发现它们差距很大。因为,.git 目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。
Git 分支和 SVN 分支的不同
SVN 的分支就是版本库中的另外一个目录，而 Git 的分支却是整个版本库的一个快照，而且可以在同一个工作目录下快速的在几个分支间切换。
Git 没有一个全局的版本号，而 SVN 有
SVN 的版本号实际是任何一个相应时间的源代码快照。而 Git 并没有这样的一个全局版本号，这也是 Git 缺少的最大的一个特征
Git 的内容完整性要优于 SVN
Git 的内容存储使用的是 SHA- 1 哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。
Git 的基本工作流程如下：
在工作目录中修改某些文件。
对修改后的文件进行快照，然后保存到暂存区域。
提交更新，将保存在暂存区域的文件快照永久转储到 Git 目录中。
3 Git 服务器搭建
——————————————————————————–
1. 环境部署
系统环境：服务器端：CentOS 6.5，ip：192.168.56.1
客户端：CentOS 6.5，ip：192.168.56.101
软件版本：服务器端：源码编译安装，git-1.9.0.tar.gz
客户端：yum 在线安装机制
2. 安装
2.1 服务器端：
#yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel perl-devel
#wget http://git-core.googlecode.com/files/git-1.9.0.tar.gz
#tar zxvf git-1.9.0.tar.gz
#cd git-1.9.0
#make prefix=/usr/local all
#make prefix=/usr/local install #root 用户运行
查看版本号：git –version
git version 1.9.0
安装 gitosis：gitosis 为 Git 用户权限管理系统, 通过管理服务端的 /home/git/.ssh/authorized_key 文件来执行对用户权限的管理，是一个 Python 模块包
#yum install python python-setuptools
#git clone git://github.com/res0nat0r/gitosis.git
#cd gitosis/
#python setup.py install
显示 Finished processing dependencies for gitosis==0.2 即表示成功
2.2 客户端安装：
#yum install git
#git –version
git version 1.7.1
3. ssh 设置
客户端生产密钥并上传到服务器端：
#ssh-keygen -t rsa
#scp ~/.ssh/id_rsa.pub root@192.168.56.1:~/
服务端查看已经上传的密钥：ls ～/id_rsa.pub
4. 服务器上生成 git 用户，使用 git 用户并初始化 gitosis
添加用户 git：
#useradd -r -s /bin/sh -c ‘git version control’ -d /home/git git
设置权限：
#mkdir -p /home/git
#chown git:git /home/git
在服务器端生成管理库：
#sudo -H -u git gitosis-init < ～/id_rsa.pub
Initialized empty Git repository in /home/git//repositories/gitosis-admin.git/ Reinitialized existing Git repository in /home/git/repositories/gitosis-admin.git/
注解：
1. 生成的 gitosis-admin 为 Git 的用户访问权限管理库，gitosis 通过这个 git 库来管理所有 git 库的访问权限。
2. 通过执行初始化，该公钥的拥有者就能修改用于配置 gitosis 的那个特殊 Git 仓库了
修改上传权限：
#chmod 755 /home/git/repositories/gitosis-admin.git/hooks/post-update
5. 客户端导出管理
#mkdir -p /git-repo/
#cd /git-repo/
#git clone git@192.168.56.1:gitosis-admin.git
#cd gitosis-admin
#find .
./gitosis.conf
./keydir
./keydir/oot@vm1.pub
注解：
gitosis.conf 文件用来设置用户、仓库和权限的控制文件
keydir 目录则是保存所有具有访问权限用户公钥的地方
./keydir/root@vm1.pub: 如前所述，该用户具有访问权限
6. 客户端创建及设置管理项目
#cd /git-repo/gitosis-admin
查看已经上传密钥
#ls keydir/
root@vm1.pub
授权和权限控制
#vim gitosis.conf
[gitosis]
[group gitosis-admin]
writable = gitosis-admin
members = root@vm1 #显示用户 root@vm1.pub 是初始化 gitosis 公钥的拥有者，是唯一能管理 gitosis-admin 项目的人
[group jay_fans] #组名称
members = root@vm1 #密钥用户名
writable = git-test #项目名称
7. 初始、增加及使用项目 git-test
#cd /git-repo
#mkdir git-test
#cd git-test
#git init
#touch README
#git add .
#git commit -a -m “init git-test”
#git remote add origin git@192.168.56.1:git-test.git
#git push origin master
注解：在新项目 git-test 里首次推送数据到服务器前，需先设定该服务器地址为远程仓库，但你不用事先到服务器上手工创建该项目的裸仓库— Gitosis 会在第一次遇到推送时自动创建。
8. 客户端增加其他成员公钥到系统中：通过添加用户的公钥到 keydir 目录即可
#cd /git-repo/gitosis-admin
#cp /path/to/member/public/key keydir/
#git add keydir/member.pub
修改 gitosis.conf
[group jay_fans] #组名称
members = jay # 新的密钥用户名
writable = git-test
提交修改：
#git commit -a -m “granted jay commit rights to git-test”
#git push
注解：gitosis 实际上是从服务器端的 /home/git/.gitosis.conf 文件读取信息的，通过以上操作，会将新的权限信息写入到该文件中，如果搞错了配置，导致失去了推送权限，可以通过修改该文件来重新设定，如果你手工编辑该文件的话，它会一直保持到下次向 gitosis-admin 推送新版本的配置内容为止。
成员 jay 通过以下命令获取代码：
#git clone git@192.168.56.1:git-test.git
1 关于版本控制
版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。有以下三种版本控制系统：
1. 本地版本控制系统
许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单。不过坏处也不少：有时候会混淆所在的工作目录，一旦弄错文件丢了数据就没法撤销恢复。
为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。图示如下，
2. 集中化的版本控制系统
集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）能够让在不同的开发系统上的开发人员协同工作。这类系统，诸如 CVS，Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法
基于 Gitolite 的 Git 服务架设 http://www.linuxidc.com/Linux/2014-02/96991.htm
Fedora 通过 Http Proxy 下载 Git http://www.linuxidc.com/Linux/2009-12/23170.htm
在 Ubuntu Server 上安装 Git http://www.linuxidc.com/Linux/2009-06/20421.htm
服务器端 Git 仓库的创建（Ubuntu）http://www.linuxidc.com/Linux/2011-02/32542.htm
Linux 下 Git 简单使用教程（以 Android 为例）http://www.linuxidc.com/Linux/2010-11/29883.htm
Git 权威指南 PDF 高清中文版 http://www.linuxidc.com/Linux/2013-10/91053.htm
3. 分布式版本控制系统
分布式版本控制系统(Distributed Version Control System，简称 DVCS), 像 Git，Mercurial，Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份,
更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。
2 关于 Git
Git 是分布式版本控制系统的一个完美实现，它与集中式版本控制系统 SVN 的基本区别如下：
Git 是分布式的，而 SVN 不是
Git 和 SVN 一样有自己的集中式版本库或服务器。但，GIT 更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库 / 服务器上 chect out 代码后会在自己的机器上克隆一个自己的版本库。
Git 将内容按元数据方式存储，而 SVN 是按文件
所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs 等的文件夹里。如果你把.git 目录的体积大小跟.svn 比较，你会发现它们差距很大。因为,.git 目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。
Git 分支和 SVN 分支的不同
SVN 的分支就是版本库中的另外一个目录，而 Git 的分支却是整个版本库的一个快照，而且可以在同一个工作目录下快速的在几个分支间切换。
Git 没有一个全局的版本号，而 SVN 有
SVN 的版本号实际是任何一个相应时间的源代码快照。而 Git 并没有这样的一个全局版本号，这也是 Git 缺少的最大的一个特征
Git 的内容完整性要优于 SVN
Git 的内容存储使用的是 SHA- 1 哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。
Git 的基本工作流程如下：
- 在工作目录中修改某些文件。
- 对修改后的文件进行快照，然后保存到暂存区域。
- 提交更新，将保存在暂存区域的文件快照永久转储到 Git 目录中。
更多详情见请继续阅读下一页的精彩内容：http://www.linuxidc.com/Linux/2014-06/103885p2.htm
4 Github 的使用
——————————————————————————–
GitHub 是一个托管 Git 项目的网站，对于闭源项目收费，开源项目则免费。使用 Github 进行代码发布和托管的步骤如下：
1. 登录 Github 官网 https://github.com/ , 申请 Github 账户，并创建名为 github-test 的 Repository
2. 安装 Git 客户端（Linux）
#yum install git git-gui
3. 生成密钥对，并拷贝到 Github 网站
#ssh-keygen -t rsa -C“xxx@gmail.com”
xxx@gmail.com 为你注册 Github 时的邮箱账户
登录 Github 点击 Edit your profile->SSH keys, 添加./.ssh/id_rsa.pub 中的内容
4. 设置 ssh 不输入口令
#eval `ssh-agent`
#ssh-add
5. 测试是否能连接上 GIthub
#ssh git@github.com
PTY allocation request failed on channel 0
Hi rangochan! You’ve successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.
连接成功
6. 配置 Git 全局用户配置
# git config –global user.name xxx
# git config –global user.email xxx@gmail.com
xxx 及 xxx@gmail.com 分别为 Github 账户名和邮箱
7. 创建本地新项目
#mkdir github-test
#cd github-test/
#git init
#touch README
#git add README
#git commit -m ‘my first commit’
定义远程服务器别名 origin
#git remote add origin git@github.com:xxx/github-test.git
本地和远程实行合并，本地默认为 master
#git push origin master
当通过 Github 以 xxx 对 github-test 作出修改时，由于本地快照与 Github 远程服务器上的不一致，会引起以下错误：
! [rejected] master -> master (fetch first)
error: failed to push some refs to ‘git@github.com:xxx/puppet’
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push –help’ for details.
解决：
通过 pull 子命令更新 Github 项目中作出的更改
#git pull origin master
之后再执行 git push origin master
Counting objects: 8, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (7/7), 714 bytes | 0 bytes/s, done.
Total 7 (delta 0), reused 0 (delta 0)
登录 https://github.com/xxx/github-test , 可查看到 github-test 项目
8. 更新文件
#vim README
just for test
自动 commit 更改文件
#git commit -a
更新到远程
#git push origin master
9. 创建和合并分支
#git branch
* master
显示当前分支是 master
#git branch new-branch
创建分支
# git checkout new-branch
切换到新分支
# vi check.py
创建新文件
# git add check.py
# git commit -a -m “added a Python script”
Commit 到本地 Git
# git push origin new-feature
合并到远程服务器
如果 new-branch 分支成熟了，则可以合并进 master
#git checkout master
#git merge new-branch
#git branch
* master
new-banch
#git push
执行合并，master 中也合并了 new-branch 中的更新
登录到 GitHub，点击 ”Switch Branches” 可以更改分支来查看不同分支下代码情况。
Git 的详细介绍：请点这里
Git 的下载地址：请点这里
更多 CentOS 相关信息见CentOS 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=14
