跪着行走的boy

lb5645284

1．git简介
　　前言：
　　git是一套内容寻址文件系统（content-addressable），在此之上提供了一个 VCS 用户界面。
　　Git的功能特性：
　　从一般开发者的角度来看，git有以下功能：
　　1、从服务器上克隆完整的Git仓库（包括代码和版本信息）到单机上。
　　2、在自己的机器上根据不同的开发目的，创建分支，修改代码。
　　3、在单机上自己创建的分支上提交代码。
　　4、在单机上合并分支。
　　5、把服务器上最新版的代码fetch下来，然后跟自己的主分支合并。
　　6、生成补丁（patch），把补丁发送给主开发者。
　　7、看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。
　　8、一般开发者之间解决冲突的方法，开发者之间可以使用pull 命令解决冲突，解决完冲突之后再向主开发者提交补丁。
　　从主开发者的角度（假设主开发者不用开发代码）看，git有以下功能：
　　1、查看邮件或者通过其它方式查看一般开发者的提交状态。
　　2、打上补丁，解决冲突（可以自己解决，也可以要求开发者之间解决以后再重新提交，如果是开源项目，还要决定哪些补丁有用，哪些不用）。
　　3、向公共服务器提交结果，然后通知所有开发人员。
　　集中式版本控制系统：
　　最显而易见的缺点是中央服务器的单点故障。如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。要是中央服务器的磁盘发生故障，碰巧没做备份，或者备份不够及时，就还是会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录，而被客户端 提取出来的某些快照数据除外，但这样的话依然是个问题，你不能保证所有的数据都已经有人事先完整提取出来过。本地版本控制系统也存在类似问题，只要整个项 目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。就像图下图所示。

　　集中式版本控制系统（CVS，Subversion，Perforce，Bazaar 等等）每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容，就像图下图所示。

　　分布式系统：
　　这类系统中，像 Git，Mercurial，Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜 像出来的本地仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份，就像图下图所示。

　　Git 和其他版本控制系统的主要差别在于，Git 只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异。Git 并不保存这些前后变化的差异数据。实际上，Git 更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照 的索引。为提高性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照作一链接。Git 的工作方式就像图下图所示。

　　集中式和分布式的区别：
　　先说集中式版本系统，版本库是集中放在中央服务器的，干活的时候，都是用自己的电脑，从中央处理器取得最新的版本，干完活后，在把自己的活推送给服务器。中央处理器就好比一个图书馆，大家都从图书馆借书，然后回家自己看，看完后再返回给图书馆。集中式版本系统的缺点是必须联网才可以干活，如果互联网，网速慢的话，可能提交一个10M的文件就得很长时间，如果中央服务器快掉的话，所有人对没法干活了
　　分布式版本系统有什么不同呢，首先、分布式版本系统没有中央处理器，每个人的电脑都是完整的版本库，这样，你工作的时候就不需要联网的，那多个人如何协作呢，比方说自己在电脑上修改了A,你的同时也在电脑上修改了A，这时，你们俩之间只需把各自的修改退送给对方，就可以互相看到对方的修改了
　　和集中式版本控制相比，分布式版本控制系统更安全，因为每个的电脑都有完整的版本库，某一个人的电脑坏掉不要紧，从其他人那里复制一个就可以了
　　版本，顾名思义，就是记录每个模块的改动，并为每次改动编上序号，个人理解：用来记录和区分你的每次操作。
　　在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天 你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的 修改，没有它大家也一样干活，只是交换修改不方便而已。
　　Git 与SVN 比较
　　SVN（Subversion）是当前使用最多的版本控制工具。与它相比较，Git 最大的优势在于两点：易于本地增加分支和分布式的特性。
　　下面两幅图可以形象的展示Git与SVN的不同之处：
　　1）本地增加分支
　　图中Git本地和服务器端结构都很灵活，所有版本都存储在一个目录中，你只需要进行分支的切换即可达到在某个分支工作的效果
　　而SVN则完全不同，如果你需要在本地试验一些自己的代码，只能本地维护多个不同的拷贝，每个拷贝对应一个SVN服务器地址
　　举一个实际的例子：
　　使用SVN作为版本控制工具，当正在试图增强一个模块，工作做到一半，由于会改变原模块的行为导致代码服务器上许多测试的失败，所以并没有提交代码。
　　这时候假如现在有一个很紧急的Bug需要处理， 必须在两个小时内完成。我只好将本地的所有修改diff，并输出成为一个patch文件，然后回滚有关当前任务的所有代码，再开始修改Bug的任务，等到修改好后，在将patch应用回来。前前后后要完成多个繁琐的步骤，这还不计中间代码发生冲突所要进行的工作量。
　　可是如果使用Git， 我们只需要开一个分支或者转回到主分支上，就可以随时开始Bug修改的任务，完成之后，只要切换到原来的分支就可以优雅的继续以前的任务。只要你愿意，每一个新的任务都可以开一个分支，完成后，再将它合并到主分支上，轻松而优雅。
　　2）分布式提交
　　Git 可以本地提交代码，所以在上面的图中，Git有利于将一个大任务分解，进行本地的多次提交
　　而SVN只能在本地进行大量的一次性更改，导致将来合并到主干上造成巨大的风险
　　3）日志查看
　　Git 的代码日志是在本地的，可以随时查看
　　SVN的日志在服务器上的，每次查看日志需要先从服务器上下载下来
　　例如：代码服务器在美国，当每次查看几年前所做的工作时，日志下载可能需要十分钟，这不能不说是一个痛苦。但是如果迁移到Git上，利用Git日志在本地的特性，查看某个具体任务的所有代码历史，每次只需要几秒钟，大大方便了工作，提高了效率。
　　当然分布式并不是说用了Git就不需要一个代码中心服务器，如果你工作在一个团队里，还是需要一个服务器来保存所有的代码的。
1.1 环境信息（系统自带）

[iyunv@oldboyedu~]# cat /etc/redhat-release

　　CentOSrelease 6.7 (Final)

[iyunv@oldboyedu~]# git --version

　　gitversion 1.7.1
　　注意：您应该至少有2GB的RAM可用于系统，而我们建议使用4GB RAM，以及4或8个CPU内核。
1.2 git工作流程的简介
　　在正式使用前，我们还需要弄清楚Git的三种重要模式，分别是已提交、已修改、已暂存

　　已提交(committed):表示数据文件已经顺利提交到Git数据库中。
　　已修改(modified):表示数据文件已经被修改，但未被保存到Git数据库中。
　　已暂存(staged):表示数据文件已经被修改，并会在下次提交时提交到Git数据库中。
　　提交前的数据文件可能会被随意修改或丢失，但只要把文件快照顺利提交到Git数据库中，那就可以完全放心了，流程为：
　　1.在工作目录中修改数据文件。
　　2.将文件的快照放入暂存区域。
　　3.将暂存区域的文件快照提交到Git仓库中。
1.3 git的命令简介
　　yuminstall git                                                         #安装Git
　　gitconfig –global user.name “xubusi”                        #配置git使用用户
　　gitconfig –global user.email “xubusi@mail.com”       #配置git使用邮箱
　　gitconfig –global color.ui true                                  #加颜色
　　gitconfig –list                                                        #所有配置的信息（上面的结果）
　　user.name=xubusi
　　user.email=xubusi@mail.com
　　color.ui=true
　　git的参数简介：
　　add                #添加文件内容至索引
　　bisect             #通过二分查找定位引入 bug 的变更
　　branch            #列出、创建或删除分支
　　checkout         #检出一个分支或路径到工作区
　　clone              #克隆一个版本库到一个新目录
　　commit           #记录变更到版本库
　　diff                #显示提交之间、提交和工作区之间等的差异
　　fetch              #从另外一个版本库下载对象和引用
　　grep                #输出和模式匹配的行
　　init                #创建一个空的 Git 版本库或重新初始化一个已存在的版本库
　　log                 #显示提交日志
　　merge            #合并两个或更多开发历史
　　mv                 #移动或重命名一个文件、目录或符号链接
　　pull                #获取并合并另外的版本库或一个本地分支（相当于git fetch和git merge）
　　push                #更新远程引用和相关的对象
　　rebase             #本地提交转移至更新后的上游分支中
　　reset                #重置当前HEAD到指定状态
　　rm                 #从工作区和索引中删除文件
　　show               #显示各种类型的对象
　　status              #显示工作区状态
　　tag                 #创建、列出、删除或校验一个GPG签名的 tag 对象
1.4 git使用流程
　　1.先创建一个工程的目录mkdirtest_project
　　2.cd test_project
　　3.git init 初始化git工作目录（git init–bare功能相同）
　　git init的结果（这个隐藏的git目录里面的内容和--bare创建的相同）

　　git init --bare 路径

　　4.touch readme 创建一个文件
　　5.git status 查看状态
　　第一次查看，这个文件还没有添加到暂存区的

　　6.git add readme 将readme文件添加到暂存区
　　既然有添加，那就有删除（此处说的是暂存区的操作，不会删除文件）
　　git rm --cached readme 　　
　　7.git status 再次查看暂存区的状态
　　将readme添加到暂存区后的状态

　　8. git commit -m "first commit" 提交到自己的中央仓库（init就是创建自己的中央仓库）
　　9. git log查看日志（相当与svn的提交日志）

　　到目前为止自己本地仓库就提交结束了
　　之后就是提交到远程仓库了
　　10 git remote –v 查看本地存储的远程仓库信息，如果是clone出来的工程这个结果如下

　　origin 表示的是远程仓库的别名（默认为origin，也可以自己起，fetch更新类似于update，push推数据相当于commit）
　　如果不是clone的工程，就不会有任何结果，要自己添加，命令如下：
　　git remote add testssh://root@10.0.0.5/usr/GitData/DingDang/.git

　　11.做完这步然后就是远程推数据了（必须保证本地仓库里面有提交，注意是本地仓库而不是暂存区）
　　git push test
　　到此自己创建的文件就推到了远程的git仓库了
　　12还有一个功能比较重要，本地仓库的版本回退
　　再提交一次，如下log：
　　git reset --hard HEAD^   #还原历史提交版本上一次
　　git reset --hard 版本号   #就是上图黄色的部分，仅需要前7位即可
　　如果回退过头了，log是看不到未来的版本号的，想看可以用git reflog查看
1.5 git分支命令
　　创建分支：
　　gitbranch linux                           #创建分支
　　gitcheckout linux                        #切换分支
　　gitbranch                                    #查看当前分支情况,当前分支前有*号
　　git addreadme.txt                       #提交到暂存区
　　gitcommit -m “new branch”        #提交到git版本仓库
　　gitcheckout master                      #我们在提交文件后再切回master分支
　　分支合并：（合并前必须保证在master主干上）
　　gitbranch #查看在哪个位置
　　git mergeLinux#合并创建的Linux分支（–no–ff默认情况下，Git执行”快进式合并”（fast-farward merge），会直接将Master分支指向Develop分支。使用–no–ff参数后，会执行正常合并，在Master分支上生成一个新节点。）
　　gitbranch -d linux#确认合并后删除分支
　　如果有冲突：
　　git mergelinux
　　#合并Linux分支(冲突)
　　Auto-mergingreadme.txt
　　CONFLICT(content): Merge conflict in readme.txt
　　Automaticmerge failed; fix conflicts and then commit the result.
　　#那么此时，我们在master与linux分支上都分别对中readme文件进行了修改并提交了，那这种情况下Git就没法再为我们自动的快速合并了，它只能告诉我们readme文件的内容有冲突，需要手工处理冲突的内容后才能继续合并
　　自己修改完readme.txt文件后再次提交

–no–ff原理图

2．gitlab服务端
2.1 安装服务相关命令
　　安装有可能的依赖：
　　yum install openssh-server
　　yum install postfix
　　yum install cronie
　　安装gitlab：
　　curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh#下载数据源
　　yum install gitlab-ce
　　安装完成后：
　　gitlab-ctl reconfigure    #使配置文件生效 但是会初始化除了gitlab.rb之外的所有文件
　　gitlab-ctl status         #查看状态
　　gitlab-ctl stop                 #停服务
　　gitlab-ctl start                #起服务
　　gitlab-ctl tail                 #查看日志的命令（Gitlab 默认的日志文件存放在/var/log/gitlab 目录下）
　　如下表示启动成功：（全是run，有down表示有的服务没启动成功）

　　然后打开浏览器输入ip或者域名
2.2 相关目录文件信息
　　相关目录：
　　.git/config                                                #版本库特定的配置设置，可用--file修改
　　~/.gitconfig                                              #用户特定的配置设置，可用--global修改
　　/var/opt/gitlab/git-data/repositories/root       #库默认存储目录
　　/opt/gitlab                                                 #是gitlab的应用代码和相应的依赖程序
　　/var/opt/gitlab                                           #此目录下是运行gitlab-ctlreconfigure命令编译后的应用数据和配置文件，不需要人为修改配置
　　/etc/gitlab                                                        #此目录下存放了以omnibus-gitlab包安装方式时的配置文件，这里的配置文件才需要管理员手动编译配置
　　/var/log/gitlab                                           #此目录下存放了gitlab各个组件产生的日志
　　/var/opt/gitlab/backups/                              #备份文件生成的目录
　　相关文件：
　　/opt/gitlab/embedded/service/gitlab-rails/config      #配置文件（修改clone的ip地址）
　　/etc/gitlab/gitlab.rb                                    #设置相关选项进行配置（gitlab地址就在这）
　　/var/opt/gitlab/git-data                               #Git存储库数据（默认）
　　相关参考文档：https://docs.gitlab.com
　　分支参考文档：http://www.cnblogs.com/haore147/p/3604464.html