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 #将远端与本地进行合并,如果需要将本地的代码上传到云端,则需要拉云端最新的代码到本地,然后再将本地与云端进行合并
3.gitlab的部署(待学习和整理)
ok