GIT使用—安装配置及工作流程

一、Git 与 SVN 区别

GIT不仅仅是个版本控制系统,它也是个内容管理系统(CMS),工作管理系统等。
1、GIT是分布式的,SVN不是:这是GIT和其它非分布式的版本控制系统,例如SVN,CVS等,最核心的区别。
2、GIT把内容按元数据方式存储,而SVN是按文件:所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。
3、GIT分支和SVN的分支不同:分支在SVN中一点不特别,就是版本库中的另外的一个目录。
4、GIT没有一个全局的版本号,而SVN有:目前为止这是跟SVN相比GIT缺少的最大的一个特征。
5、GIT的内容完整性要优于SVN:GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性,确保在遇到磁盘故障和网络问题时降低对版本库的破坏。

二、GIT安装

[root@localhost ~]# yum list |grep git
git.x86_64                                1.7.1-4.el6_7.1             centos6.7   
git-all.noarch                            1.7.1-4.el6_7.1             centos6.7  获取其他Git工具的元软件包
git-cvs.noarch                            1.7.1-4.el6_7.1             centos6.7    导入CVS库的Git工具
git-daemon.x86_64                         1.7.1-4.el6_7.1             centos6.7  共享你的版本库,接受匿名下载请求
git-email.noarch                          1.7.1-4.el6_7.1             centos6.7  通过电子邮件发送Git补丁
git-gui.noarch                            1.7.1-4.el6_7.1             centos6.7   基于Tcl/Tk的图形界面
git-svn.noarch                            1.7.1-4.el6_7.1             centos6.7  导入SVN库的Git工具
gitk.noarch                               1.7.1-4.el6_7.1             centos6.7   更侧重于项目历史可视化的Git浏览器
gitweb.noarch                             1.7.1-4.el6_7.1             centos6.7   在浏览器里显示Git版本库

[root@localhost ~]# yum install curl-devel expat-devel gettext-devel \
  openssl-devel zlib-devel
[root@localhost ~]# yum -y install git-core
[root@localhost ~]# git --version
git version 1.7.1

三、Git配置

Git 提供了一个叫做 git config 的工具,专门用来配置或读取相应的工作环境变量。
这些环境变量,决定了 Git 在各个环节的具体工作方式和行为。这些变量可以存放在以下三个不同的地方:

  • /etc/gitconfig 文件:系统中对所有用户都普遍适用的配置。若使用 git config 时用 --system 选项,读写的就是这个文件。
  • ~/.gitconfig 文件:用户目录下的配置文件只适用于该用户。若使用 git config 时用 --global 选项,读写的就是这个文件。
  • 当前项目的 Git 目录中的配置文件(也就是工作目录中的 .git/config 文件):这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置,所以 .git/config 里的配置会覆盖 /etc/gitconfig 中的同名变量。

(1)用户信息
配置个人的用户名称和电子邮件地址:

[root@localhost ~]# git config --global user.name "tong"
[root@localhost ~]# git config --global user.email tong@test.com

如果用了 --global 选项,那么更改的配置文件就是位于你用户主目录下的那个,以后你所有的项目都会默认使用这里配置的用户信息。
如果要在某个特定的项目中使用其他名字或者电邮,只要去掉 --global 选项重新配置即可,新的设定保存在当前项目的 .git/config 文件里。

(2)文本编辑器
设置Git默认使用的文本编辑器, 一般可能会是 Vi 或者 Vim。如果你有其他偏好,比如 Emacs 的话,可以重新设置:

[root@localhost ~]# git config --global core.editor vim

(3)差异分析工具
还有一个比较常用的是,在解决合并冲突时使用哪种差异分析工具。比如要改用 vimdiff 的话:

[root@localhost ~]# git config --global merge.tool vimdiff

(4)查看配置信息

[root@localhost ~]# git config --list
user.name=tong
user.email=tongxiaoda@anzhi.com
core.editor=vim
merge.tool=vimdiff

有时候会看到重复的变量名,那就说明它们来自不同的配置文件(比如 /etc/gitconfig 和 ~/.gitconfig),不过最终 Git 实际采用的是最后一个。

[root@localhost ~]# cat .gitconfig 
[user]
	name = tong
	email = tongxiaoda@anzhi.com
[core]
	editor = vim
[merge]
	tool = vimdiff
[root@localhost ~]# git config user.name
tong

四、Git工作流程及原理

(1)工作流程

一般工作流程如下:

  • 克隆Git资源作为工作目录。
  • 在克隆的资源上添加或修改文件。
  • 如果其他人修改了,你可以更新资源。
  • 在提交前查看修改。
  • 提交修改。
  • 在修改完成后,如果发现错误,可以撤回提交并再次修改并提交。

(2)基本概念

  • 工作区:就是你在电脑里能看到的目录。
  • 暂存区:英文叫stage, 或index。一般存放在 ".git目录下" 下的index文件(.git/index)中,所以我们把暂存区有时也叫作索引(index)。
  • 版本库:工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库。

版本库中的暂存区和版本库之间的关系:

图中左侧为工作区,右侧为版本库。在版本库中标记为 "index" 的区域是暂存区(stage, index),标记为 "master" 的是 master 分支所代表的目录树。
图中我们可以看出此时 "HEAD" 实际是指向 master 分支的一个"游标"。所以图示的命令中出现 HEAD 的地方可以用 master 来替换。
图中的 objects 标识的区域为 Git 的对象库,实际位于 ".git/objects" 目录下,里面包含了创建的各种对象及内容。

当对工作区修改(或新增)的文件执行 "git add" 命令时,暂存区的目录树被更新,同时工作区修改(或新增)的文件内容被写入到对象库中的一个新的对象中,而该对象的ID被记录在暂存区的文件索引中。
当执行提交操作(git commit)时,暂存区的目录树写到版本库(对象库)中,master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。
当执行 "git reset HEAD" 命令时,暂存区的目录树会被重写,被 master 分支指向的目录树所替换,但是工作区不受影响。
当执行 "git rm --cached " 命令时,会直接从暂存区删除文件,工作区则不做出改变。
当执行 "git checkout ." 或者 "git checkout -- " 命令时,会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险,会清除工作区中未添加到暂存区的改动。
当执行 "git checkout HEAD ." 或者 "git checkout HEAD " 命令时,会用 HEAD 指向的 master 分支中的全部或者部分文件替换暂存区和以及工作区中的文件。这个命令也是极具危险性的,因为不但会清除工作区中未提交的改动,也会清除暂存区中未提交的改动。

(3)架构

从一般开发者的角度来看,git有以下功能:
1、从远程服务器上克隆clone完整的git仓库(包括代码和版本信息)到自己的机器(单机)上。
2、在自己的机器上根据不同的开发目的,创建分支,修改代码。
3、在单机上自己创建的分支上提交代码。
4、在单机上合并分支。
5、把远程服务器上最新版的代码fetch下来,然后跟自己的主分支合并。
6、生成补丁(patch),把补丁发送给主开发者。
7、看主开发者的反馈,如果主开发者发现两个一般开发者之间有冲突(他们之间可以合作解决的冲突),就会要求他们先解决冲突,然后再由其中一个人提交。如果主开发者可以自己解决,或者没有冲突,就通过。
8、一般开发者之间解决冲突的方法,开发者之间可以使用pull命令解决冲突,解决完冲突之后再向主开发者提交补丁。

从主开发者的角度看,git有以下功能:
1、查看邮件或者通过其它方式查看一般开发者的提交状态。
2、打上补丁,解决冲突(可以自己解决,也可以要求开发者之间解决以后再重新提交,如果是开源项目,还要决定哪些补丁有用,哪些不用)。
3、向远程服务器(公共的)提交结果,然后通知所有开发人员。

posted @ 2018-02-27 11:20  BXBZ—边学边做  阅读(168)  评论(0编辑  收藏  举报