Git的优势
- 大部分操作都是在本地完成,不需要联网
- 完整性保证(哈希函数)
- 尽可能的添加数据而不是删除数据
- 分支操作非常快捷流畅
- 与Linux命令全面兼容
三个区域
- 工作区(写代码)
- 暂存区(临时存储)
- 本地库(历史版本)
工作区-->暂存区(git add)
暂存区-->本地区(git commit)
本地库-->远程库(push)
远程库-->本地库(clone、pull)
Git和代码托管中心
代码托管中心的任务:维护远程库
局域网环境下:GitLab服务器
外网环境下:GitHub、码云
本地库初始化
命令:git init
注意:.git目录中存放的是本地库相关的子目录和文件,不要删除,也不要胡乱进行修改
设置签名
- 用户名
- 密码
这里设置的用户名和密码只是为了起到一个表示的作用,为的是区分不同开发人员的身份
注意:这里的用户名和密码和远程登录库(代码托管中心)用户名、密码没有任何的关系
命令:通过参数可以区分级别
- 项目级别/仓库级别;仅在当前本地库分为有效(git config user.name torn_pro)(git config user.email [email protected])
- 系统用户级别:登录当前操作系统的用户范围(git config --global user.name torn_glb)(git config --global user.email [email protected])
级别优先级:
就近原则:项目级别优先于系统用户级别,二者都有时采用项目级别;如果只有系统用户级别的签名,就以系统用户级别的签名为准;二者都没有是不允许的
查看配置(信息保存目录):
cat .git/config
cd ~ --> ls -lA|less --> cat .gitconfig
没有什么特殊需求就设置系统用户级别就可以了
基本操作
状态查看操作
git status
查看工作区、暂存区状态
添加操作
git add【file name】
将工作区的“新建/修改”添加到暂存区
提交操作
git commit -m "commit message" [file name]
将暂存区的内容提交到本地库中
查看历史记录
git log(全部显示出来了)
多屏显示控制方式:
- 空格向下翻页
- b 向上翻页
- q 退出
git log --pretty=oneline
git log --oneline
git reflog(在oneline的基础上 HEAD@{移动到当前版本需要多少步数} )
版本前进后退
本质
有一个指针(HEAD)指向当前版本,移动指针就可以指向想要的版本号
基于索引值操作
git reset [--hard [局部索引值]]
git reset --hard 0744434
使用^操作
只能后退,不能往前,后退多少步,就写多少^
使用~操作
只能后退,git reset --hard HEAD~3
reset命令三个参数对比
- --soft参数 (仅仅在本地库移动HEAD指针)
- --mixed参数 (在本地库移动HEAD指针、重置暂存区)
- --hard参数 (在本地库移动HEAD指针、重置暂存区、重置工作区)
删除文件并且找回
前提:删除前,文件存在时候的状态提交到了本地库
操作:git reset --hard [指针位置] (删除操作已经提交到本地库:指针位置指向了历史记录;删除操作尚未提交到本地库:指针位置使用HEAD)
比较文件差异
- git diff [文件名] (将工作区中的文件和暂存区进行比较)
- git diff [本地库中的历史版本][文件名] (将工作区中的文件和本地库历史记录比较)
- 不带文件名进行比较多个文件
分支管理
什么是分支
在版本控制过程中,使用多条线同时推进多个任务
分支就是add commit之后,然后切换到被合并的master上面合并hot_fix的操作
分支的好处
- 同时并行推进多个功能开发,提高开发效率
- 各个分支在开发过程中,如果某一个分支开发失败,不会对其他分支有任何影响。失败的分支删除重新开始即可。
分支操作
- 创建分支
- 查看分支
- 切换分支
- 合并分支
- 第一步:切换到接收修改的分支(被合并,增加新内容)上 (git checkout [被合并分支名])
- 执行merge命令(合并命令)(git merge [有新内容分支名])
- 解决冲突
- 冲突的表现
- 冲突的解决
- 第一步:编辑文件,删除特殊符号
- 第二步:把文件修改到满意的程度,保存退出
- 第三部:git add [文件名]
- 第四部:git commit -m "日志信息"
Git基本原理
哈希
哈希是一个系列的加密算法,各个不同的哈希算法虽然加密强度不同,但是有以下几个共同点:
- 不管输入数据的数据量有多大,输入同一个哈希算法,得到加密结果长度固定。
- 哈希算法确定,输入数据确定,输入数据能够保证不变
- 哈希算法确定,输入数据有变化,输出数据一定有变化,而且通常变化很大
- 哈希算法不可逆
Git底层采用的是SHA-1算法
哈希算法可以被用来验证文件,原理如下所示:
Git就是靠这种机制来从根本上来保证数据的完整性的。
Git保存版本的机制
集中式版本控制工具的文件管理机制
以每个变更列表的方式存储信息。这类系统将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。
SVM是增量式的版本控制,每个版本都是保存有变化的一点,这个做法能很好地节约服务器的存储空间。
Git的文件管理机制
Git吧数据看做是小型文件系统的一组快照,每次提交更新时Git都会对当前的全部文件制作一个快照的索引。为了高效,如果文件没有修改,Git不再重新存储该文件,而只是保留一个链接指向之前存储的文件。所以Git的工作方式可以称之为快照流。
Git文件管理机制细节
Git的“提交对象“
提交对象及其父对象形成的链条
Git分支管理机制
分支的创建
分支的切换
只是切换的指针的指向
这相当于往前走了一步
切换为master的时候,就让HEAD指针重新指向master就可以了。效率很高的切换,不涉及文件复制的方面
这个时候master在提交一个,这时候testing和master就指向了两个不同的版本,这两个新的版本都是以f30ab作为父版本的,这个时候从数据方面来说才真正有了分叉,
回顾本地库和远程库之间是怎么交互的
在本地库创建远程库地址别名
git remote -v 查看当前所有远程地址别名
git remote add [别名][远程地址]
推送
git push [别名][分支名]
克隆
这里是团队里面另外的人的目录,不需要git init,因为clone下来的就是一个完整的库
- 命令
- git clone [远程地址]
- 效果
- 完整的把远程库下载到本地
- 创建origin远程地址别名
- 初始化本地库
团队成员邀请
拉取
- pull = fetch + merge
- git fetch [远程库地址别名] [远程分支名]
- git merge [远程库地址别名/远程分支名]
- 拉取下来以后本地文件并没有变化,只是把远程库下载到本地,因为因为可以先自己看看,觉得没有什么问题就可以进行合并了
- 如果想看一下 下载下来的文件长什么样子,就需要切换用户(记得后面要切换回master)
- 看好以后,没有什么问题就可以进行合并了
- 这里插入一下,填了一次github之后就不用再填写的原因
- 下面直接进行拉取的操作,相当于fetch和merge同时都做(这是只读的操作也不会登录的)(当数据比较简单,不太容易造成冲突的时候,就直接使用pull就可以了)
解决冲突
- 要点
- 如果不是基于Github远程库的最新版本所做的修改,不能推送,必须先拉取
- 拉取下来如果进入冲突状态,则按照“分支冲突解决"操作即可
- 类比
- 债权人:老王
- 债务人:小刘(像github远程库一样)
- 老王说:10天后归还,小刘接受,双方达成一致
- 老王媳妇说:5天后归还,小刘不接受,老王媳妇需要找老王确认后再执行。
跨团队协作
- fork
- 本地修改,推送到远程
- pull request
- 对话
- 审核代码
- 合并代码
- 将远程库修改拉取到本地
SSH登录
局限性:只能为一个账号设置这个
Eclipse操作
工程初始化为本地库
- 工程->右键->Team->Share Prohect->Git
- Create Repository
- Finish
Eclipse中忽略文件
- 概念 Eclipse特定文件(和开发的代码没有直接关系,是Eclipse为了管理我们创建的工程为维护的文件。最好不要再Git中进行追踪,也就是把他们忽略)
- .classpath文件
- .project文件
- .settings目录下所有文件
- 为什么要忽略Eclipse特定文件呢?
- 版本不一样的话,特定文件可能也会不一样的
- 因为同一个团队中很难保证大家使用相同的IDE工具,而IDE工具不同时,相关工程特定文件就有可能不同。如果这些文件加入版本控制,那么开发时就可能需要为这些文件解决冲突。
- GitHub官网样例文件
- 编辑本地忽略配置文件,文件名任意,注意,这里在路径中一定要使用“/”,不能使用“\”
推送到远程库
推送的前提——github上面也要有对应的远程库
Oxygen Eclipse克隆工程操作
(版本高点)
- Import……导入工程
- 要转换为一个正常的工程文件
-
Kepler Eclipse克隆工程操作
(版本低点)
问题:不能保存到当前的Eclipse工作区目录
正确做法:保存到工作区以外目录中
Git工作流
概念
在项目开发过程中使用Git的方式
分类
集中式工作流
像SVN一样,集中式工作流以中央仓库作为项目所有修改的单点实体。左右修改都提交到Master这个分支上。
这种方式与SVN的主要区别就是开发人员有本地库。Git很多特性并没有用到。
GitFlow工作流
Gitflow工作流通过为功能开发、发布准备和维护设立了独立的分支,让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。
Forking工作流
Forking工作流是在Gitflow基础上,充分利用了Git的Fork和pull request的功能以达到代码审核的目的。更适合安全可靠的管理大团队的开发者,而且能接受不信任贡献者的提交。
GitFlow工作流详解
分支种类
GitFlow工作流举例
分支实战
具体操作
- 创建分支
- 切换分支审核代码
- 检出远程新分支
- 合并分支
- 要想将hot_fix合并,就要先切换到master上面
-
- 合并结果
- 合并成功后,把master推送到远程库中
Gitlab服务器搭建过程
官网地址
安装命令摘录
调整后的安装命令
当前步骤完成后重启
gitlab服务操作
浏览器访问
应该会需要停止防火墙服务
service firewalld stop