Git&GitHub
idea的操作可以查看idea操作Git、交互Github和码云
Git结构
Git 和代码托管中心
代码托管中心的任务:维护远程库
局域网环境下
- GitLab 服务器
外网环境下
- GitHub
- 码云
Git操作
本地库操作
本地库初始化
命令:git init
效果: 在该文件下创建了一个叫.git的隐藏文件
注意:.git 目录中存放的是本地库相关的子目录和文件,不要删除,也不要胡乱修改
设置签名
形式:用户名:tom Email 地址:goodMorning@atguigu.com
作用:区分不同开发人员的身份
辨析:这里设置的签名和登录远程库(代码托管中心)的账号、密码没有任何关系。
命令:
-
项目级别/仓库级别:仅在当前本地库范围内有效
git config user.name yzl_pro
git config user.email hello_pro@qq.com
信息保存在:
.git/config
-
系统用户级别:登录当前操作系统的用户范围
git config --global user.name yzl_glb
git config --global user.email hello_glb@qq.com
信息保存在:
~/.gitconfig
(linux中的~代表的是系统中当前用户的家目录,相当于windows中的c:/users/用户名) -
级别优先级
- 就近原则:项目级别优先于系统用户级别,二者都有时采用项目级别 的签名
- 如果只有系统用户级别的签名,就以系统用户级别的签名为准
- 二者都没有不允许
基本操作
状态查看
git status
查看工作区、暂存区状态
添加进暂存区
git add [file name]
将工作区的“新建/修改”添加到暂存区
可以进vim模式,esc进入末行模式,:wq保存并退出
暂存区删除文件
git rm --cached [file name]
提交
git commit -m “commit message” [file name]
将暂存区的内容提交到本地库
再简单提一些常见场景, 比如说commit完之后,突然发现一些错别字需要修改,又不想为改几个错别字而新开一个commit到history区,那么就可以使用下面这个命令:
git commit --amend
这样就是把错别字的修改和之前的那个commit中的修改合并,作为一个commit提交到history区。
查看历史记录
git log
head类似于指针,指向的当前的主分支
多屏显示控制方式:
- 空格向下翻页
- b 向上翻页
- q 退出
git log --pretty=oneline
以一个简洁的形式显示
git log --oneline
更简洁,hash只显示部分
git reflog
HEAD@{移动到当前版本需要多少步}
前进后退
本质:
基于索引值操作[推荐]
git reset --hard [局部索引值]
例子:git reset --hard a6ace91
使用^符号:只能后退
git reset --hard HEAD^
注:一个^表示后退一步,n 个表示后退 n 步
使用~符号:只能后退
git reset --hard HEAD~n
注:表示后退 n 步
reset 命令的三个参数对比
–soft 参数
- 仅仅在本地库移动 HEAD 指针
–mixed 参数
- 在本地库移动 HEAD 指针
- 重置暂存区
–hard 参数
- 在本地库移动 HEAD 指针
- 重置暂存区
- 重置工作区
soft 和 mixed 都不会修改本地文件
soft相当于撤销了commit命令,mixed相当于撤销了add和commit命令
删除文件并找回
ps:rm [filename]删除文件
前提:删除前,文件存在时的状态提交到了本地库
操作:
git reset --hard [指针位置]
- 删除操作已经提交到本地库:指针位置指向历史记录(局部索引值)
- 删除操作尚未提交到本地库:指针位置使用 HEAD
比较文件差异
git diff [文件名]
将工作区中的文件和暂存区进行比较
git diff [本地库中历史版本] [文件名]
将工作区中的文件和本地库历史记录比较 git diff HEAD^
不带文件名比较多个文件
分支管理
什么是分支?
分支就是在版本控制过程中,使用多条线同时推进多个任务。
分支的好处
- 同时并行推进多个功能开发,提高开发效率
- 各个分支在开发过程中,如果某一个分支开发失败,不会对其他分支有任 何影响。失败的分支删除重新开始即可。
分支操作
-
创建分支
git branch [分支名]
-
查看分支
git branch -v
-
切换分支
git checkout [分支名]
-
合并分支
-
第一步:切换到接受修改的分支(被合并,增加新内容)上
git checkout [被合并分支名] (主分支)
-
第二步:执行 merge 命令
git merge [有新内容分支名] (次分支)
-
-
解决冲突
-
冲突的表现(比如两个同时修改了同一行)
-
冲突的解决
- 第一步:编辑文件,删除特殊符号
- 第二步:把文件修改到满意的程度,保存退出
- 第三步:git add [文件名]
- 第四步:git commit -m “日志信息”
- 注意:此时 commit 一定不能带具体文件名
-
远程库操作
直接看github那里,那里就是远程库的操作
Git原理
哈希
哈希是一个系列的加密算法,各个不同的哈希算法虽然加密强度不同,但是有以下 几个共同点:
①不管输入数据的数据量有多大,输入同一个哈希算法,得到的加密结果长度固定。
②哈希算法确定,输入数据确定,输出数据能够保证不变
③哈希算法确定,输入数据有变化,输出数据一定有变化,而且通常变化很大
④哈希算法不可逆 Git 底层采用的是 SHA-1 算法。
哈希算法可以被用来验证文件。原理如下图所示:
Git 保存版本的机制
集中式版本控制工具的文件管理机制
以文件变更列表的方式存储信息。这类系统将它们保存的信息看作是一组基本 文件和每个文件随时间逐步累积的差异
只是把修改的地方保存起来,到时候回来对比
Git 的文件管理机制
Git 把数据看作是小型文件系统的一组快照。每次提交更新时 Git 都会对当前 的全部文件制作一个快照并保存这个快照的索引。为了高效,如果文件没有修改, Git 不再重新存储该文件,而是只保留一个链接指向之前存储的文件。所以 Git 的 工作方式可以称之为快照流
Git 文件管理机制细节
Git的“提交对象”(每次修改都有不同的hash,把他们保存在tree里面,tree保存在对象里面)
提交对象及其父对象形成的链条
Git 分支管理机制
分支的创建
其实就是使一个节点,使其也指向对象
分支的切换
把head指针,指向新的分支
当分支进行了对象的变更后:
在切换回主分支时:
当两个分支都产生了新的对象时:
Github
创建远程库地址别名
git remote -v
查看当前所有远程地址别名
git remote add [别名] [远程地址]
添加远程地址的别名
推送
git push [别名] [分支名]
克隆
git clone [远程地址]
效果:
- 完整的把远程库下载到本地
- 创建 origin 远程地址别名
- 初始化本地库
团队成员的邀请
成员前往与账户关联的主邮箱,同意加入即可
拉取
pull=fetch+merge
- git fetch [远程库地址别名] [远程分支名]
- git merge [远程库地址别名/远程分支名]
- git pull [远程库地址别名] [远程分支名]
比较复杂的情况,我们可以先fetch到本地,我们checkout切换分支看看有没有问题,然后再merge合并分支
解决冲突
如果一个人提交了,另一个人也要提交,提交的途中发现报错,因为远程仓库的hash不是原来的那个了,匹配不上了,所以需要先拉取,再提交
要点:
- 如果不是基于 GitHub 远程库的最新版所做的修改,不能推送,必须先拉取。
- 拉取下来后如果进入冲突状态,则按照“分支冲突解决”操作解决即可。
类比 :
- 债权人:老王
- 债务人:小刘
- 老王说:10 天后归还。小刘接受,双方达成一致。
- 老王媳妇说:5 天后归还。小刘不能接受。老王媳妇需要找老王确认后再执行。
跨团队合作
别的团队会多出一个仓库
观看仓库的名字,可以知道下图的结论:
别的团队可以将仓库clone到本地,然后进行对应的操作。本地修改,然后推送到远程。
等到推送到远程后,别的团队如图点击,进行pull request和发送信息
原仓库的主人,查看pull request
原仓库主人可以查看提交和具体文件的修改
如果原主人觉得没问题,点击下图进行合并:并填写本次操作的日志信息
最后再将远程库修改拉取到本地
SSH登录
进入当前用户的家目录
$ cd ~
删除.ssh 目录
$ rm -rvf .ssh
运行命令生成.ssh 密钥目录
$ ssh-keygen -t rsa -C [github登录邮箱]
[注意:这里-C 这个参数是大写的 C]
进入.ssh 目录查看文件列表
$ cd .ssh
$ ls -lF
查看 id_rsa.pub 文件内容
$ cat id_rsa.pub
复制 id_rsa.pub 文件内容,登录 GitHub,点击用户头像→Settings→SSH and GPG keys
New SSH Key
输入复制的密钥信息
回到 Git bash 创建远程地址别名(记得用ssh的)
git remote add origin_ssh git@github.com:atguigu2018ybuq/huashan.git
推送文件进行测试
Git工作流
在项目开发过程中使用 Git 的方式
分类
集中式工作流
像 SVN 一样,集中式工作流以中央仓库作为项目所有修改的单点实体。所有 修改都提交到 Master 这个分支上。 这种方式与 SVN 的主要区别就是开发人员有本地库。Git 很多特性并没有用到。
GitFlow 工作流
Gitflow 工作流通过为功能开发、发布准备和维护设立了独立的分支,让发布 迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。
Forking 工作流
Forking 工作流是在 GitFlow 基础上,充分利用了 Git 的 Fork 和 pull request 的 功能以达到代码审核的目的。更适合安全可靠地管理大团队的开发者,而且能接受不信任贡献者的提交。
GitFlow 工作流详解
分支种类
-
主干分支 master
主要负责管理正在运行的生产环境代码。永远保持与正在运行的生产环境 完全一致。
-
开发分支 develop
主要负责管理正在开发过程中的代码。一般情况下应该是最新的代码。
-
bug 修理分支 hotfix
主要负责管理生产环境下出现的紧急修复的代码。 从主干分支分出,修 理完毕并测试上线后,并回主干分支。并回后,视情况可以删除该分支。
-
准生产分支(预发布分支) release
较大的版本上线前,会从开发分支中分出准生产分支,进行最后阶段的集成测试。该版本上线后,会合并到主干分支。生产环境运行一段阶段较稳定后 可以视情况删除。
-
功能分支 feature
为了不影响较短周期的开发工作,一般把中长期开发模块,会从开发分支 中独立出来。 开发完成后会合并到开发分支。
GitFlow 工作流举例
分支实战
具体实战
创建分支
切换分支审查代码
检出远程新分支
切换回 master
合并结果