Git & GitHub

1.Git概述

1.1 Git结构

1.2 Git和代码托管中心

代码托管中心的任务：维护远程库
局域网环境下：

• GitLab 服务器

外网环境下：

• GitHub
• 码云

1.3 本地库和远程库

1.3.1 团队内部协作

1.3.2 跨团队协作

2 Git命令

2.1本地初始化

命令：git init 

效果：在当前工作目录下创建了一个  .git   的文件夹，内容如下所示：

2.2设置签名

形式

• 用户名：WnBoy
• Email 地址：*****@163.com

作用：区分不同开发人员的身份
辨析：这里设置的签名和登录远程库(代码托管中心)的账号、密码没有任何关系。
命令
        项目级别/仓库级别：仅在当前本地库范围内有效
               git config user.name WnBoy_pro
               git config user.email goodMorning_pro@163.com
               信息保存位置：./.git/config 文件

系统用户级别：登录当前操作系统的用户范围
    git config --global user.name WnBoy
    git config --global goodMorning@163.com
    信息保存位置：~/.gitconfig 文件

级别优先级
       就近原则：项目级别优先于系统用户级别，二者都有时采用项目级别的签名
       如果只有系统用户级别的签名，就以系统用户级别的签名为准
       二者都没有不允许

2.3 基本操作

2.3.1 状态查看

• git status

    查看工作区、暂存区状态

2.3.2 添加

• git add [file name]

     将工作区的“新建/修改”添加到暂存区
2.3.3 提交

• git commit -m "commit message" [file name]

    将暂存区的内容提交到本地库

2.3.4 查看历史记录

• git log

多屏显示控制方式：
空格向下翻页
b 向上翻页
q 退出

• git log --pretty=oneline

•  git log --oneline

• git reflog

HEAD@{移动到当前版本需要多少步}

2.3.5 前进后退

本质：

• 基于索引值操作[推荐]

           git reset --hard [局部索引值]
           git reset --hard f74f325

• 使用^符号：只能后退

          git reset --hard HEAD^
          注：一个^表示后退一步，n 个表示后退n 步

• 使用~符号：只能后退

         git reset --hard HEAD~n
         注：表示后退n 步

2.3.6  reset 命令的三个参数对比

• soft 参数：
  • 仅仅在本地库移动HEAD 指针

• mixed 参数
  • 在本地库移动HEAD 指针
  • 重置暂存区

• hard 参数
  • 在本地库移动HEAD 指针
  • 重置暂存区
  • 重置工作区

2.3.7 删除文件并找回

• 前提：删除前，文件存在时的状态提交到了本地库。
• 操作：git reset --hard [指针位置]
  • 删除操作已经提交到本地库：指针位置指向历史记录
  • 删除操作尚未提交到本地库：指针位置使用HEAD

2.3.8 比较文件差异

• git diff [文件名]
  • 将工作区中的文件和暂存区进行比较
• git diff [本地库中历史版本] [文件名]
  • 将工作区中的文件和本地库历史记录比较
• 不带文件名比较多个文件

2.4 分支管理

2.4.1 什么是分支

在版本控制过程中，使用多条线同时推进多个任务。

2.4.2 分支的好处？

• 同时并行推进多个功能开发，提高开发效率
• 各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响。失败的分支删除重新开始即可。

2.4.3 分支操作

• 创建分支
  • git branch [分支名]
• 查看分支
  • git branch -v
• 切换分支
  • git checkout [分支名]
• 合并分支（使用hot_fix分支修改了文件的内容，然后切换到master分支进行合并）
  • 第一步：切换到接受修改的分支（被合并，增加新内容）上：git checkout [被合并分支名]
  • 第二步：执行merge 命令 ：git merge [有新内容分支名]

 

 

• 合并分支引起冲突--解决冲突

 首先是分支master对aaa.txt文件进行修改，并提交

其次是hot_fix对aaa.txt文件相同的位置进行修改并提交

 

 自动合并出错，出现冲突

冲突的表现

• 冲突的解决
  • 第一步：编辑文件，删除特殊符号
  • 第二步：把文件修改到满意的程度，保存退出
  • 第三步：git add [文件名]
  • 第四步：git commit -m "日志信息"
    • 注意：此时commit 一定不能带具体文件名

第 一、二 步： 

第三、四 步：

3.Git 基本原理

3.1 哈希

哈希是一个系列的加密算法，各个不同的哈希算法虽然加密强度不同，但是有以下
几个共同点：
①不管输入数据的数据量有多大，输入同一个哈希算法，得到的加密结果长度固定。
②哈希算法确定，输入数据确定，输出数据能够保证不变
③哈希算法确定，输入数据有变化，输出数据一定有变化，而且通常变化很大
④哈希算法不可逆
Git 底层采用的是SHA-1 算法。
哈希算法可以被用来验证文件。原理如下图所示：

Git 就是靠这种机制来从根本上保证数据完整性的。

3.2 Git保存版本的机制

3.2.1 集中式版本控制工具的文件管理机制
       以文件变更列表的方式存储信息。这类系统将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。

3.2.2 Git 的文件管理机制
      Git 把数据看作是小型文件系统的一组快照。每次提交更新时Git 都会对当前的全部文件制作一个快照并保存这个快照的索引。为了高效，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。所以Git 的工作方式可以称之为快照流。

4.GitHub的使用

4.1账号信息

WnBoy

4.2创建远程库

4.3 创建本地库和文件

4.4 创建远程库地址别名

git remote -v 查看当前所有远程地址别名
git remote add [别名] [远程地址]

4.5 推送

git push [别名] [分支名]

4.6 克隆（另外一名队员WnBoy1024克隆）

4.6.1 命令

git clone [远程地址]

4.6.2 过程

① 创建另外一个工作区（GitHubTest2）

② 执行 git clone [远程地址]     地址从WnBoy的GitHub上的TestGitHub项目上复制

4.6.3 效果

• 完整的把远程库下载到本地
• 创建origin 远程地址别名
• 初始化本地库

队员WnBoy对 clone下来的文件进行修改，然后想用自己的账户push上GitHub，发现并不能成功

此时需要  WnBoy 在 GitHub上邀请  WnBoy1024  才可以 

4.7 团队邀请（团队的发起A者邀请这名新队员B）

团队协作：

4.7.1 WnBoy发起邀请

4.7.2 WnBoy1024接受邀请，成为WnBoy的队员

4.7.3 WnBoy添加新队员WnBoy1024之后，新队员WnBoy1024就可以把自己的修改使用自己的账户密码push上GitHub去。

4.8 拉取

4.8.1 pull=fetch+merge

• git fetch [远程库地址别名] [远程分支名]
• git merge [远程库地址别名/远程分支名]
• git pull [远程库地址别名] [远程分支名]

 

4.8.2 WnBoy在本地库里面的文件还是旧的文件，没有WnBoy的修改记录

4.8.3 WnBoy将GitHub上的文件抓取下来

4.8.4 对抓取的文件进行分析

4.8.5 将抓取的GitHub文件和本地库文件进行合并

4.9 解决冲突

要点

• 如果不是基于GitHub 远程库的最新版所做的修改，不能推送，必须先拉取。
• 拉取下来后如果进入冲突状态，则按照“分支冲突解决”操作解决即可。（commit时不能带文件名）

实例：

4.9.1 首先是WnBoy对项目进行修改，然后保存，添加到暂存区，提交到本地库，最后推送到GitHub上。

4.9.2 接下来WnBoy1024也对自己本地的文件进行修改，add到缓存区，commit到本地库

然后push到GitHub发生报错

4.9.3 WnBoy1024对其进行pull，自动合并失败，需要手动处理冲突

4.9.4 进入冲突文件，删除特殊标记，进行修改到满意为止，add到暂存区，commit到本地库，然后进行push

4.10 跨团队协作

4.10.1 WnlifeTDOA1024:  fork这个项目到自己的仓库

详解： 

4.10.2 WnlifeTDOA1024 : clone这个项目到本地:项目的地址时自己的GitHub上fork的项目的地址

4.10.3 WnlifeTDOA1024: 对这个项目进行一番自己的修改，然后add到暂存区，commit到本地库，最后push到自己的GitHub

4.10.4 WnlifeTDOA1024 :发起 Pull Request 

4.10.5 WnBoy：接受 Pull Request ，并且对其处理审核

4.10.6 两个人交流

4.10.7 WnBoy进行审核WnlifeTDOA1024的修改文件

4.10.8 WnBoy合并WnlifeTDOA1024的修改

 

4.10.9 WnBoy pull合并后的GitHub到本地库，内容包含WnlifeTDOA1024的修改

4.11 SSH实现免密登录

4.11.1 进入当前用户的家目录
$ cd ~

4.11.2 删除原先的.ssh 目录
$ rm -rvf .ssh

4.11.3 运行命令生成.ssh 密钥目录
$ ssh-keygen -t rsa -C [当前GitHub的邮箱地址]         [注意：这里-C 这个参数是大写的C]    一路回车

4.11.4 进入.ssh 目录查看文件列表
$ cd .ssh
$ ls -lF
4.11.5 查看id_rsa.pub 文件内容

$ cat id_rsa.pub

4.11.6 复制id_rsa.pub 文件内容，登录GitHub，点击用户头像→Settings→SSH and GPG keys
New SSH Key
4.11.7 输入复制的密钥信息

4.11.8 回到Git bash 创建远程地址别名
git remote add origin_ssh gitgit@github.com:WnBoy/TestGitHub.git

4.11.9 推送文件进行测试

5 Git 工作流

5.1概念

在项目开发过程中使用Git 的方式

5.2分类

5.2.1 集中式工作流

像SVN 一样，集中式工作流以中央仓库作为项目所有修改的单点实体。所有修改都提交到Master 这个分支上。
这种方式与SVN 的主要区别就是开发人员有本地库。Git 很多特性并没有用到。

5.2.2 GitFlow 工作流

Gitflow 工作流通过为功能开发、发布准备和维护设立了独立的分支，

让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。

5.2.3 Forking 工作流

Forking 工作流是在GitFlow 基础上，充分利用了Git 的Fork 和pull request 的功能以达到代码审核的目的。更适合安全可靠地管理大团队的开发者，而且能接受不信任贡献者的提交。

5.3GitFlow 工作流详解

5.3.1 分支种类

• 主干分支master

主要负责管理正在运行的生产环境代码。永远保持与正在运行的生产环境完全一致。

• 开发分支develop

主要负责管理正在开发过程中的代码。一般情况下应该是最新的代码。

• bug 修理分支hotfix

主要负责管理生产环境下出现的紧急修复的代码。从主干分支分出，修理完毕并测试上线后，并回主干分支。并回后，视情况可以删除该分支。

• 准生产分支（预发布分支） release

较大的版本上线前，会从开发分支中分出准生产分支，进行最后阶段的集成测试。该版本上线后，会合并到主干分支。生产环境运行一段阶段较稳定后可以视情况删除。

• 功能分支feature

为了不影响较短周期的开发工作，一般把中长期开发模块，会从开发分支中独立出来。开发完成后会合并到开发分支。

5.3.2 GitFlow 工作流举例