Git详解

起步 - Git 简史

同生活中的许多伟大事物一样，Git 诞生于一个极富纷争大举创新的年代。

Linux 内核开源项目有着为数众多的参与者。绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。

到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds）基于使用 BitKeeper 时的经验教训，开发出自己的版本系统。他们对新的系统制订了若干目标：

速度
简单的设计
对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
完全分布式
有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）

自诞生于 2005 年以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。它的速度飞快，极其适合管理大项目，有着令人难以置信的非线性分支管理系统。

三种状态

好，请注意。如果你希望后面的学习更顺利，记住下面这些关于 Git 的概念。 Git 有三种状态，你的文件可能处于其中之一：已提交（committed）、已修改（modified）和已暂存（staged）。已提交表示数据已经安全的保存在本地数据库中。已修改表示修改了文件，但还没保存到数据库中。已暂存表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。

由此引入 Git 项目的三个工作区域的概念：Git 仓库、工作目录以及暂存区域。

关于版本控制

什么是“版本控制”？我为什么要关心它呢？版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。在本书所展示的例子中，我们对保存着软件源代码的文件作版本控制，但实际上，你可以对任何类型的文件进行版本控制。

如果你是位图形或网页设计师，可能会需要保存某一幅图片或页面布局文件的所有修订版本（这或许是你非常渴望拥有的功能），采用版本控制系统（VCS）是个明智的选择。有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。使用版本控制系统通常还意味着，就算你乱来一气把整个项目中的文件改的改删的删，你也照样可以轻松恢复到原先的样子。但额外增加的工作量却微乎其微。

　　1、本地版本控制系统

　　许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单，但是特别容易犯错。有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。

为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。

　　2、集中化的版本控制系统

　　如何让在不同系统上的开发者协同工作？于是，集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）应运而生。这类系统，诸如 CVS、Subversion 以及Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法。

　　3、分布式版本控制系统

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

Git 官方中文手册 https://git-scm.com/book/zh/v2

安装git

环境说明：

[root@gitlab ~]# rpm -qa centos-release
centos-release-7-4.1708.el7.centos.x86_64
[root@gitlab ~]# uname -a
Linux gitlab 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[root@gitlab ~]# getenforce 
Disabled
[root@gitlab ~]# systemctl status firewalld.service 
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:firewalld(1)

　　1、Yum安装Git

# centos 自带git
[root@gitlab ~]# rpm -qa git
git-1.8.3.1-11.el7.x86_64

# 安装方法
yum install git -y

　　2、编译安装

编译安装可以安装较新版本的git
Git下载地址： https://github.com/git/git/releases

# 安装依赖关系
yum install curl-devel expat-devel gettext-devel  openssl-devel zlib-devel

# 编译安装
tar -zxf git-2.0.0.tar.gz
cd git-2.0.0
make configure
./configure --prefix=/usr
make  
make install

初次运行 Git 前的配置

　　1、配置git

git config --global user.name "clsn"  #配置git使用用户
git config --global user.email "admin@znix.top"  #配置git使用邮箱
git config --global color.ui true  #语法高亮
git config --list # 查看全局配置

　　2、配置过程

[root@gitlab ~]# git config --global user.name "clsn"  #配置git使用用户
[root@gitlab ~]# git config --global user.email "admin@znix.top"  #配置git使用邮箱
[root@gitlab ~]# git config --global color.ui true  #语法高亮
[root@gitlab ~]# git config --list # 查看全局配置
user.name=clsn
user.email=admin@znix.top
color.ui=true

　　3、生成的配置文件

[root@gitlab ~]# cat .gitconfig 
[user]
    name = clsn
    email = admin@znix.top
[color]
    ui = true

　　4、获取帮助

使用Git时需要获取帮助，有三种方法可以找到Git命令的使用手册：

git help <verb>
git <verb> --help
man git-<verb>
例如，要想获得配置命令的手册，执行

git help config

获取 Git 仓库（初始化仓库）

# 创建目录
mkdir git_data
# 进入目录
cd git_data/
# 初始化
git init
# 查看工作区状态
git status

　　操作过程

[root@gitlab ~]# mkdir git_data
[root@gitlab ~]# cd git_data/
[root@gitlab git_data]# git init
初始化空的 Git 版本库于 /root/git_data/.git/
[root@gitlab git_data]# git status
# 位于分支 master
#
# 初始提交
#
无文件要提交（创建/拷贝文件并使用 "git add" 建立跟踪）

Git命令常规操作

　　1、常用操作示意图

　　2、文件的状态变化周期

　　3、git操作练习->创建文件

1、创建文件

[root@gitlab git_data]# touch README
[root@gitlab git_data]# git status
# 位于分支 master    //有可能是英文的对应着解释
#
# 初始提交
#
# 未跟踪的文件:
#   （使用 "git add <file>..." 以包含要提交的内容）
#
#    README
提交为空，但是存在尚未跟踪的文件（使用 "git add" 建立跟踪）

2、添加文件跟踪

[root@gitlab git_data]# git add ./*
[root@gitlab git_data]# git status
# 位于分支 master
#
# 初始提交
#
# 要提交的变更：
#   （使用 "git rm --cached <file>..." 撤出暂存区）
#
#    新文件：    README

文件会添加到.git的隐藏目录

[root@gitlab git_data]# tree  .git/
.git/
├── branches
├── config
├── description
├── HEAD
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── prepare-commit-msg.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   └── update.sample
├── index
├── info
│   └── exclude
├── objects
│   ├── e6
│   │   └── 9de29bb2d1d6434b8b29ae775ad8c2e48c5391
│   ├── info
│   └── pack
└── refs
    ├── heads
    └── tags

3、由工作区提交到本地仓库

[root@gitlab git_data]# git commit  -m 'first commit'  
[master（根提交） bb963eb] first commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README

4、查看git的状态

[root@gitlab git_data]# git status
# 位于分支 master
无文件要提交，干净的工作区

提交后的git目录状态

[root@gitlab git_data]# tree  .git/
.git/
├── branches
├── COMMIT_EDITMSG
├── config
├── description
├── HEAD
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── prepare-commit-msg.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   └── update.sample
├── index
├── info
│   └── exclude
├── logs
│   ├── HEAD
│   └── refs
│       └── heads
│           └── master
├── objects
│   ├── 54
│   │   └── 3b9bebdc6bd5c4b22136034a95dd097a57d3dd
│   ├── bb
│   │   └── 963eb32ad93a72d9ce93e4bb55105087f1227d
│   ├── e6
│   │   └── 9de29bb2d1d6434b8b29ae775ad8c2e48c5391
│   ├── info
│   └── pack
└── refs
    ├── heads
    │   └── master
    └── tags

　　4、添加新文件

git add  * 添加到暂存区域
git commit  提交git仓库 -m 后面接上注释信息，内容关于本次提交的说明，方便自己或他人查看
修改或删除原有文件

//常规方法
git add  *
git commit

//简便方法
git commit -a  -m "注释信息"

-a 表示直接提交
Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are
not affected.

　　5、删除git内的文件

命令说明：

• 没有添加到暂存区的数据直接rm删除即可。
• 已经添加到暂存区数据：

git rm --cached database 
#→将文件从git暂存区域的追踪列表移除(并不会删除当前工作目录内的数据文件)

git rm -f database
#→将文件数据从git暂存区和工作目录一起删除

命令实践：

# 创建新文件
[root@gitlab git_data]# touch 123
[root@gitlab git_data]# git status
# 位于分支 master
# 未跟踪的文件:
#   （使用 "git add <file>..." 以包含要提交的内容）
#
#    123
提交为空，但是存在尚未跟踪的文件（使用 "git add" 建立跟踪）
# 将文件添加到暂存区域

[root@gitlab git_data]# git add 123
[root@gitlab git_data]# git status
# 位于分支 master
# 要提交的变更：
#   （使用 "git reset HEAD <file>..." 撤出暂存区）
#
#    新文件：    123
#  删除文件

[root@gitlab git_data]# rm 123 -f
[root@gitlab git_data]# ls
[root@gitlab git_data]# git status
# 位于分支 master
# 要提交的变更：
#   （使用 "git reset HEAD <file>..." 撤出暂存区）
#
#    新文件：    123
#
# 尚未暂存以备提交的变更：
#   （使用 "git add/rm <file>..." 更新要提交的内容）
#   （使用 "git checkout -- <file>..." 丢弃工作区的改动）
#
#    删除：      123
# 
[root@gitlab git_data]# git reset HEAD  ./* 
[root@gitlab git_data]# git status
# 位于分支 master
无文件要提交，干净的工作区

　　6、查看历史记录

• git log   #→查看提交历史记录

• git log -2   #→查看最近几条记录

• git log -p -1  #→-p显示每次提交的内容差异,例如仅查看最近一次差异

• git log --stat -2 #→--stat简要显示数据增改行数，这样能够看到提交中修改过的内容，对文件添加或移动的行数，并在最后列出所有增减行的概要信息

• git log --pretty=oneline #→--pretty根据不同的格式展示提交的历史信息

• git log --pretty=fuller -2 #→以更详细的模式输出提交的历史记录

• git log --pretty=fomat:"%h %cn"  #→查看当前所有提交记录的简短SHA-1哈希字串与提交着的姓名。

　　7、还原历史数据

Git服务程序中有一个叫做HEAD的版本指针，当用户申请还原数据时，其实就是将HEAD指针指向到某个特定的提交版本，但是因为Git是分布式版本控制系统，为了避免历史记录冲突，故使用了SHA-1计算出十六进制的哈希字串来区分每个提交版本，另外默认的HEAD版本指针会指向到最近的一次提交版本记录，而上一个提交版本会叫HEAD^，上上一个版本则会叫做HEAD^^，当然一般会用HEAD~5来表示往上数第五个提交版本。

git reset --hard   hash

git reset --hard HEAD^  #→还原历史提交版本上一次

git reset --hard 3de15d4 #→找到历史还原点的SHA-1值后，就可以还原(值不写全,系统会自动匹配)

测试命令

[root@gitlab git_data]# git log
commit a409fc46f792228a8119705e9cc97c2a013534ab
Author: clsn <13835544305@163.com>
Date:   Wed Nov 29 11:44:14 2017 +0800

    test

commit bb963eb32ad93a72d9ce93e4bb55105087f1227d
Author: clsn <13835544305@163.com>
Date:   Wed Nov 29 10:57:02 2017 +0800

    first commit

还原数据

[root@gitlab git_data]# git reset --hard  bb963
HEAD 现在位于 bb963eb first commit
# 查看数据
[root@gitlab git_data]# ls
README

　　8、标签使用

前面回滚使用的是一串字符串，又长又难记。

git tag v1.0   #→当前提交内容打一个标签(方便快速回滚)，每次提交都可以打个tag。

git tag          #→查看当前所有的标签

git show v1.0   #→查看当前1.0版本的详细信息

git tag v1.2 -m "version 1.2 release is test"  #→创建带有说明的标签,-a指定标签名字，-m指定说明文字

git tag -d v1.0   #→我们为同一个提交版本设置了两次标签,删除之前的v1.0

测试命令

[root@gitlab git_data]# git reset --hard 0bdf2e7
HEAD is now at 0bdf2e7 modified README file
[root@gitlab git_data]# git reset --hard V1.0
HEAD is now at a66370a add test dir

[root@gitlab git_data]# git tag  v20171129
[root@gitlab git_data]# git tag 
v20171129

　　9、对比数据

git diff可以对比当前文件与仓库已保存文件的区别，知道了对README作了什么修改后，再把它提交到仓库就放⼼多了。

git diff README

分支结构

在实际的项目开发中，尽量保证master分支稳定，仅用于发布新版本，平时不要随便直接修改里面的数据文件。

那在哪干活呢？干活都在dev分支上。每个人从dev分支创建自己个人分支，开发完合并到dev分支，最后dev分支合并到master分支。所以团队的合作分支看起来会像下图那样。

　　1、分支切换

[root@gitlab git_data]# git branch linux
[root@gitlab git_data]# git branch 
      linux
    * master
    [root@gitlab git_data]# git checkout linux 

    切换到分支 'linux'
    [root@gitlab git_data]# git branch 
    * linux
      master

在linux分支进行修改
    [root@gitlab git_data]# cat README 
    [root@gitlab git_data]# echo "2017年11月30日" >> README 
    [root@gitlab git_data]# git add .
    [root@gitlab git_data]# git commit -m "2017年11月30日09点10分"
    [linux 5a6c037] 2017年11月30日09点10分
     1 file changed, 1 insertion(+)
    [root@gitlab git_data]# git status 
    # 位于分支 linux
    无文件要提交，干净的工作区

回到master分支
    [root@gitlab git_data]# git checkout master 
    切换到分支 'master'
    [root@gitlab git_data]# cat README 
    [root@gitlab git_data]# git log  -1
    commit 7015bc7b316cc95e2dfe6c53e06e3900b2edf427
    Author: clsn <admin@znix.top>
    Date:   Wed Nov 29 19:30:57 2017 +0800

        123

合并代码
    [root@gitlab git_data]# git merge linux 
    更新 7015bc7..5a6c037
    Fast-forward
     README | 1 +
     1 file changed, 1 insertion(+)
    [root@gitlab git_data]# git status 
    # 位于分支 master
    无文件要提交，干净的工作区
    [root@gitlab git_data]# cat README 
    2017年11月30日

　　2、合并失败解决

模拟冲突，在文件的同一行做不同修改

//在master 分支进行修改
[root@gitlab git_data]# cat README 
2017年11月30日
[root@gitlab git_data]# echo  "clsn in master">> README 
[root@gitlab git_data]# git commit -a -m "clsn 2017年11月30日 09点20分 "
[master 7ab71d4] clsn 2017年11月30日 09点20分
 1 file changed, 1 insertion(+)

//切换到linux分支
[root@gitlab git_data]# git checkout linux 
切换到分支 'linux'
[root@gitlab git_data]# cat README 
2017年11月30日
[root@gitlab git_data]# echo "clsn in linux" >> README 
[root@gitlab git_data]# git commit -a -m "2017年11月30日 03"
[linux 20f1a13] 2017年11月30日 03
 1 file changed, 1 insertion(+)

//回到master分区，进行合并，出现冲突
[root@gitlab git_data]# git checkout master 
切换到分支 'master'
[root@gitlab git_data]# git merge linux
自动合并 README
冲突（内容）：合并冲突于 README
自动合并失败，修正冲突然后提交修正的结果。

//解决冲突
[root@gitlab git_data]# vim README 
2017年11月30日
clsn in master
clsn in linux

# //手工解决冲突
[root@gitlab git_data]# git commit -a -m "2017年11月30日 03"
[master b6a097f] 2017年11月30日 03

　　3、删除分支

因为之前已经合并了linux分支，所以现在看到它在列表中。在这个列表中分支名字前没有 * 号的分支通常可以使用 git branch -d 删除掉；你已经将它们的工作整合到了另一个分支，所以并不会失去任何东西。

查看所有包含未合并工作的分支，可以运行 git branch --no-merged：

git branch --no-merged
  testing

这里显示了其他分支。因为它包含了还未合并的工作，尝试使用 git branch -d 命令删除它时会失败：

git branch -d testing
error: The branch 'testing' is not fully merged.
If you are sure you want to delete it, run 'git branch -D testing'.

如果真的想要删除分支并丢掉那些工作，如同帮助信息里所指出的，可以使用 -D 选项强制删除它。　

git详细讲解：https://git-scm.com/book/en/v2

posted @ 2018-11-02 12:30 少校的小木屋阅读(310) 评论(0) 编辑收藏举报

刷新页面返回顶部

Tim's blog

难在坚持，贵在坚持，成在坚持。