企业应用学习-git学习

1.git的基本使用

git与svn的区别

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

1.1 git的安装以及初始化

1.1.1 git的安装

以centos为例

（1.）yum方式来安装git

root@ci‐node1 ~]# yum install git –y
root@ci‐node1 ~]# git version
git version 1.8.3.1

（2.）编译安装

root@ci‐node1 ~]# yum install curl‐devel expat‐devel gettext‐devel openssl‐devel zlib‐devel gcc
perl‐ExtUtils‐MakeMaker ‐y
下载最新的源码包
root@ci‐node1 src]# cd /usr/local/src/
root@ci‐node1 src]# wget https://www.kernel.org/pub/software/scm/git/git‐2.9.5.tar.gz
root@ci‐node1 src]# ll
total 5792 ‐rw‐r‐‐r‐‐ 1 root root 5928730 Aug 11 01:57 git‐2.9.5.tar.gz
解压安装：
root@ci‐node1 src]# tar xf git‐2.9.5.tar.gz
root@ci‐node1 src]# cd git‐2.9.5
root@ci‐node1 git‐2.9.5]# make prefix=/usr/local/git all
root@ci‐node1 git‐2.9.5]# make prefix=/usr/local/git install
root@ci‐node1 git‐2.9.5]# rm ‐rf /usr/bin/git
root@ci‐node1 git‐2.9.5]# ln ‐s /usr/local/git/bin/git /usr/bin/git
root@ci‐node1 git‐2.9.5]# git ‐‐version
git version 2.9.5

至此，我们已经完成了 Git 的编译安装

1.1.2 git的配置

Git 的配置从上到下分三层 system/global/local,使用三个不同参数进行设置，每个层次的配置存储在不同的位置，

./etc/gitconfig 文件：包含了适用于系统所有用户和所有库的值。如果你传递参数选项’--system’ 给 git config，它将明确的读和写这个文件。
.~/.gitconfig 文件：具体到你的用户。你可以通过传递--global 选项使 Git 读或写这个特定的文件。
.位于 git 目录的 config 文件 (也就是 .git/config) ：无论你当前在用的库是什么，特定指向该单一的库。每个级别重写前一个级别的值。因此，在.git/config 中的值覆盖在/etc/gitconfig 中的同一个值。

通常我们只配置 global 级别。

[root@ci‐node1~]# git config ‐‐global user.name xxxx
[root@ci‐node1 ~]# git config ‐‐global user.email xxxx@xxx.com
[root@ci‐node1 ~]# git config ‐‐list
user.name=xxxx
user.email=xxxx@xxxx.com

1.1.3 git仓库的初始化

（1.）建仓库

[root@ci-node1 ~]# mkdir git_test
// 切换到 git_test 目录下
[root@ci-node1 ~]# cd git_test/
[root@ci-node1 git_test]# pwd
/root/git_test
// 使用 git init 命令创建一个空仓库// 使用 git init 命令创建一个空仓库
[root@ci-node1 git_test]# git init
Initialized empty Git repository in /root/git_test/.git/
// 空仓库创建完成后 gittest 文件夹下会生成一个.git 隐藏文件夹。仓库默认包含一个主
支，即 master，默认操作都是在主分支 master 上进行的。

（2.）设置过滤文件

有了仓库，我们便可以在 git_test 文件夹下的工作区做文件增删修改工作了，但很多时候，我们只在意开发过程中的源文件，并不需要管理自动产生的其他临时文件。这时候我们便需要一个过滤文件，在这个文件中设置过滤规则，让 Git 能够自动过滤掉那些临时文件，这个文是.gitignore 件。

//在仓库目录下创建.gitignore 文件
[root@ci-node1 git_test]# touch .gitignore
[root@ci-node1 git_test]# vim .gitignore
[root@ci-node1 git_test]# cat .gitignore
test.txt //过滤 test.txt 文件
/test/ //过滤 test 目录
*.txt //过滤所有以.txt 结尾的文件

常用的通配规则：
以斜杠“/”开头表示目录
以星号“*”通配多个字符
以问号“?”通配单个字符
以方括号“[]”包含单个字符的匹配列表
以叹号“!”表示不忽略(跟踪)匹配到的文件或目录

（3.）git的仓库或者四种状态

git的四个区域

工作目录：当前仓库目录
暂存区域：缓存区域--index文件夹
本地仓库：.git文件夹
远程仓库：github或者私有gitlab

git的四种状态

Untracked：新增的文件的状态，未受 Git 管理，记录在工作区
Modified：受 Git 管理过的文件的改动状态（包括改动内容、删除文件），记录在工作区
Staged：将记录在工作区的文件变动状态通知了 Git，记录在暂存区
Unmodified：受 Git 管理中的文件状态（没有变动），记录在本地仓库/远程仓库

1.2 git的基础命令

1.2.1 git的状态以及上传基本命令

1. git status -->看状态，除了unmodified之外，其他文件改动状态
[root@ci-node1 git_test]# git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .gitignore
# a
# b
# c
nothing added to commit but untracked files present (use "git add" to track)

2. git add -->将工作目录内的文件提交到暂存区

3 git rm --cache --> 将缓存区文件回退到本地目录

4.git rm -f xx -->从暂存区以及本地目录中删除数据

5.git commit -m  '描述'  --> 在仓库工作区下完成了文件的增删改操作后，提交到git本地仓库，git会对文件管理

6. git mv xx xx.xx --> 把之前用 git add 添加的文件直接在暂存区里重新命
名或移动到新位置
//将 a 文件改名为 a.txt
[root@ci-node1 git_test]# git mv a a.txt
[root@ci-node1 git_test]# git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: a.txt
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .gitignore
# b

1.2.2git版本对比以及log操作

git版本对比以及log操作

1. git diff a -->查看a文件暂存区和本地仓库之间的差异

2. git diff --cached a -->查看a文件本地仓库与暂存区之间具体的区别
[root@ci-node1 git_test]# git diff --cached a.txt
diff --git a/a.txt b/a.txt
index e69de29..9daeafb 100644
--- a/a.txt
+++ b/a.txt
@@ -0,0 +1 @@
+test

3.git logo  标准查看log变更

4. git log --online  精简查看一行展示

5.git log --online  --deorate 查看分支以及其他

6.git log -p   完整查看

7. git reflog   查看本地历史操作，可以看到本地具体操作
[root@ci-node1 git_test]# git reflog
8982c79 HEAD@{0}: commit: commit b
1f5fb04 HEAD@{1}: commit (initial): commit a

8. git --checkout  撤回到之前的版本，暂存区域本地目录之间

9. git  HEAD  暂存区与仓库保持一致

10.git reset --hard   回退到某次commit操作
原理就是放弃工作区和 index 的改动，同时 HEAD 指针指向前一个 commit 对象。
git reset –hard HEAD ^1
//要通过 git log 查看提交日志，也可直接指定提交编号或序号
[root@ci-node1 git_test]# git log --oneline
8982c79 commit b
1f5fb04 commit a
[root@ci-node1 git_test]# git reset --hard 8982c79

1.3 git的分支和标签

1.3.1 git的分支

Git 中的分支，其实本质上仅仅是个指向 commit 对象的可变指针。Git 会使用 master作为分支的默认名字。在若干次提交后，你其实已经有了一个指向最后一次提交对象的master 分支，它在每次提交的时候都会自动向前移动。

（1.）创建分支

git log --online --decrote     #查看当前分支的log
#常用我们认为master为稳定版本分支，dev为开发分支

git brance testing  #创建一个brance的分支

git brance  #查看当前所有分支，展示数据中加*为当前所在分支

Git 保存着一个名为 HEAD 的特别指针。在 Git 中，它是一个指向你正在工作中的本地分支的指针（译注：将 HEAD 想象为当前分支的别名。）。运行 git branch 命令，仅仅是建立了一个新的分支，但不会自动切换到这个分支中去，所以在这个例子中，我们依然还在master 分支里工作。

（2.）切换当前分支结构

要切换到其他分支，可以执行 git checkout 命令。我们现在转换到新建的 testing

[root@ci-node1 git_test]# git checkout testing
Switched to branch 'testing'
[root@ci-node1 git_test]# git branch
master
* testing

（3.）分支合并

在前面基础上，在testing分支创建新的文件，然后做一次commit

提交后的结果：

现在 testing 分支向前移动了一格，而 master 分支仍然指向原先 git checkout 时所在的 commit 对象。

如果这个时候回到master分支对文件进行修改，就会出现以下情况

现在我们的仓库提交历史产生了分叉，我们可以在不同分支之间来回切换，做修改相互不影响，也可以在适当的时机把他们合并到一起。现在我们把 testing 分支的内容合并到master 分支上。

//切换到 master 分支
[root@ci-node1 git_test]# git checkout master
Already on 'master'
[root@ci-node1 git_test]# git branch
* master
Testing
//合并 testing 分支到 master，输入提示信息
[root@ci-node1 git_test]# git merge testing
Merge made by the 'recursive' strategy.
c | 0
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 c
//我们看到 testing 分支的内容已经合并到 master 分支。
[root@ci-node1 git_test]# ll
total 4
-rw-r--r-- 1 root root 5 Aug 1 00:12 a.txt
-rw-r--r-- 1 root root 0 Jul 31 22:05 b
-rw-r--r-- 1 root root 0 Aug 1 17:28 c
-rw-r--r-- 1 root root 0 Aug 1 16:54 d
//通过查看 commit 信息我们可以看到，testing 分支做的那次 commit 已经合并到了
master 的 commit 日志中了，而且合并后重新生成了一次 commit。
[root@ci-node1 git_test]# git log --oneline
2c56b27 Merge branch 'testing'
286061a commit d on branch master
b3f92ea commit c on branch testing
8982c79 commit b
1f5fb04 commit a

结果如下

注意：有时候合并操作并不会如此顺利，如果在不同的分支中都修改同一个文件的同一部分，Git 就无法干静地把两者合并了。这时 Git 做了合并，但没有提交，它会停下来等你解决冲突。要看看哪些文件在合并时发生冲突，我们使用 git status 查阅

[root@ci-node1 git_test]# echo "111">>a.txt
[root@ci-node1 git_test]# git add .
[root@ci-node1 git_test]# git commit -m "modify a.txt on master"
[master 0d2d2a5] modify a.txt on master
1 file changed, 1 insertion(+)
[root@ci-node1 git_test]# git checkout testing
Switched to branch 'testing'
[root@ci-node1 git_test]# echo "222">>a.txt
[root@ci-node1 git_test]# git add .
[root@ci-node1 git_test]# git commit -m "modify a.txt on testing"
[testing 3da0eb7] modify a.txt on testing
1 file changed, 1 insertion(+)
[root@ci-node1 git_test]# cat a.txt
test
222
[root@ci-node1 git_test]# git checkout master
Switched to branch 'master'
[root@ci-node1 git_test]# cat a.txt
test
111
[root@ci-node1 git_test]# git merge testing
Auto-merging a.txt
CONFLICT (content): Merge conflict in a.txt
Automatic merge failed; fix conflicts and then commit the result.
[root@ci-node1 git_test]# cat a.txt
test
<<<<<<< HEAD
111
=======
222
>>>>>>> testing
[root@ci-node1 git_test]#
//修改合并后的冲突文件 a.txt，然后再做一次 commit，即完成了本次合并。
[root@ci-node1 git_test]# cat a.txt
test
111
222
[root@ci-node1 git_test]# git add .
[root@ci-node1 git_test]# git commit -m "commit modify a.txt"
[root@ci-node1 git_test]# git log --oneline
9740430 commit modify a.txt
3da0eb7 modify a.txt on testing
0d2d2a5 modify a.txt on master
2c56b27 Merge branch 'testing'
286061a commit d on branch master
b3f92ea commit c on branch testing
8982c79 commit b
1f5fb04 commit a

（4.）分支删除

git brach -d xxx #删除某个分支

1.3.2 git的标签

标签也是版本库的一个快照。Git 的标签虽然是版本库的快照，但其实它就是指向某个commit 的指针
如果你达到一个重要的阶段，并希望永远记住那个特别的提交快照，你可以使用 git tag 给它打上标签。
比如说，我们想为我们的项目发布一个"1.0"版本。我们可以用 git tag -a v1.0 命令给最新一次提交打上（HEAD）"v1.0"的标签。-a 选项意为"创建一个带注解的标签"。不用 -a 选项也可以执行的，但它不会记录这标签是啥时候打的，谁打的，也不会让你添加个标签的注解。

1. 创建标签
[root@ci-node1 git_test]# git tag -a v1.0
2.查看标签
[root@ci-node1 git_test]# git tag
v1.0
3.查看标签
[root@ci-node1 git_test]# git show v1.0
tag v1.0
Tagger: wendong <wendong866@163.com>
Date: Wed Aug 1 19:10:23 2018 +0800
merge testing after
commit 97404309c95d7344f23bffc8f3f17480698895ae
Merge: 0d2d2a5 3da0eb7
Author: wendong <wendong866@163.com>
Date: Wed Aug 1 18:42:46 2018 +0800
commit modify a.txt
diff --cc a.txt
index 72167ef,3c4f069..732fac4
--- a/a.txt
+++ b/a.txt
@@@ -1,2 -1,2 +1,3 @@@
test
+111
+ 222
4.删除标签
[root@ci-node1 git_test]# git tag -d v1.0
Deleted tag 'v1.0' (was 919d2a3)

2. github的使用

github的常用

git remote add origin ‘xxx’  #和远端git 进行连接
git push -u origin master   #将本地master分支推送到远端
git clone xxx   #将远端项目克隆到本地，分https模式和ssh模式，ssh模式需要上传公钥
git fetch  #将远端最新版本拉倒本地仓库
git merge origin master #将远端与本地进行合并，如果需要将本地的代码上传到云端，则需要拉云端最新的代码到本地，然后再将本地与云端进行合并