Git&GitHub

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

合并结果

GitLab服务器搭建流程