Git & GitHub图文详解(不详细叫人打我)

心心相印 → 印贼作父 → 父相伤害 → 害想咋滴
一篇文章让你0基础精通git,害想咋滴?(白嫖有罪,记得点赞)

不详细记得叫人打我
不详细一定要叫人打我
不详细千万记得叫人打我
Git & GitHub图文详解(不详细叫人打我)_第1张图片


文章目录

  • 一、Git安装
    • 1.1、Git 的优势
    • 1.2、下载安装Git
  • 二、Git基本工作流程
    • 2.1、工作区
    • 2.2、本地库和远程库
  • 三、Git 命令行操作
    • Git常用命令
    • 3.1、本地库初始化
    • 3.2、设置签名
    • 3.3、查看文件提交到暂存区状态
    • 3.4、提交文件到暂存区
    • 3.5、提交文件到本地库
    • 3.6、修改文件到本地库
    • 3.7、查看文件修改内容和时间
    • 3.7、查看提交历史
    • 3.8、历史版本前进与回退
    • 3.9、reset 命令的三个参数对比
    • 3.10、删除操作
    • 3.11、找回本地库已删除文件
    • 3.12、比较文件差异
    • 3.12、三个常用的撤销命令
    • 3.13、文件重新命名
  • 四、分支管理
    • 4.1、分支简介
    • 4.2、分支操作
      • 4.2.1、查看所有分支
      • 4.2.2、新增分支
      • 4.2.3、重新命名分支
      • 4.2.4、切换分支
      • 4.2.5、合并分支
      • 4.2.6、合并分支冲突解决
      • 4.2.7、删除分支
      • 4.2.8、恢复分支
      • 4.2.9、分支应用场景模拟
  • 五、 Git基本原理
    • 5.1、哈希
    • 5.2、Git 保存版本的机制
      • 5.2.1 集中式版本控制工具的文件管理机制
      • 5.2.2 Git 的文件管理机制
      • 5.2.3、 Git 文件管理机制细节
    • 5.3、Git 分支管理机制
  • 六、Git & GitHub团队协作
    • 6.1、团队内协作
      • 项目经理创建远程仓库:
      • 项目经理创建本地仓库
      • 项目经理为远程仓库配置别名与其对应的URL
      • 项目经理推送本地仓库到远程仓库
      • 成员克隆远程仓库到本地
      • 项目经理邀请成员加入团队
      • 成员推送内容到远程库
      • 项目经理更新成员提交的内容
    • 6.2 深入远程跟踪分支
      • 远程跟踪分支
      • git pull和git fetch的区别:
      • 删除远程分支
    • 6.3、远程协作冲突
    • 6.4、团队外协作
  • 七、Git中.gitignore的配置语法
  • 八、idea中使用Git
    • 8.1、修改IntelliJ IDEA的maven插件默认仓库地址
    • 8.2、安装Git核心程序
    • 8.3、设置github账号
    • 8.4、初始化本地仓库
    • 8.5、添加Git忽略文件
    • 8.6、添加文件到暂存区
    • 8.7、取消暂存区文件的添加或者修
    • 8.8、添加文件到本地库并提交的远程库
    • 8.9、切换Git历史提交版本
    • 8.10、创建分支以及合并分支
    • 8.11、Git解决冲突
    • 8.12、Git更新当前最新的本地库
    • 8.13、idea克隆项目到本地库


一、Git安装

1.1、Git 的优势

Git是先进的分布式版本控制系统,而Github是常用的Git代码托管中心。

  1. 大部分操作在本地完成,不需要联网
  2. 完整性保证
  3. 尽可能添加数据而不是删除或修改数据
  4. 分支操作非常快捷流畅
  5. 与Linux 命令全面兼容

1.2、下载安装Git

(Git命令的学习推荐网站:https://www.softwhy.com/article-8488-1.html)
下载Git 官方地址为:https://git-scm.com/download/win
Git & GitHub图文详解(不详细叫人打我)_第2张图片

2、下载完之后,双击安装
Git & GitHub图文详解(不详细叫人打我)_第3张图片

3、选择安装目录
在这里插入图片描述

4、选择组件
Git & GitHub图文详解(不详细叫人打我)_第4张图片

5、加入开始菜单目录名设置
Git & GitHub图文详解(不详细叫人打我)_第5张图片

6、选择使用命令行环境
Git & GitHub图文详解(不详细叫人打我)_第6张图片

7、以下三步默认,直接点击下一步
Git & GitHub图文详解(不详细叫人打我)_第7张图片
Git & GitHub图文详解(不详细叫人打我)_第8张图片
Git & GitHub图文详解(不详细叫人打我)_第9张图片
Git & GitHub图文详解(不详细叫人打我)_第10张图片

9、检验是否安装成功
回到电脑桌面,鼠标右击如果看到有两个git单词则安装成功
Git & GitHub图文详解(不详细叫人打我)_第11张图片
也可以在命令窗口输入git命令
Git & GitHub图文详解(不详细叫人打我)_第12张图片


二、Git基本工作流程

2.1、工作区

1、Git不联网下的三个工作区域
Git & GitHub图文详解(不详细叫人打我)_第13张图片

2、Git 和代码托管中心

代码托管中心的任务:维护远程库

局域网环境开发:大公司一般有GitLab 服务器

外网环境下: GitHub(外国服务器,访问稍慢)
       码云(国内服务器,访问较快)


2.2、本地库和远程库

1、公司团队内部协作
Git & GitHub图文详解(不详细叫人打我)_第14张图片

2、跨团队协作
Git & GitHub图文详解(不详细叫人打我)_第15张图片


三、Git 命令行操作

在使用Bash命令窗口的时候,讲两个细节:

  1. Liunx命令在Bash里面通用
  2. 在Bash里面想复制东西,直接鼠标选中内容,Bash默认就执行了 复制
  3. Git只会增加版本记录,不会删除,哪怕本地库做了删除操作都会增加版本记录。
    所以即便是后退到了一开始的版本,最终修改后的版本也会存在,可以随便进、退。

Git & GitHub图文详解(不详细叫人打我)_第16张图片

Git常用命令

3.1、本地库初始化

本地库初始化(创建本地库)

命令:git init
效果:
Git & GitHub图文详解(不详细叫人打我)_第17张图片
执行git init之后就创建了工作区和本地库:
Git & GitHub图文详解(不详细叫人打我)_第18张图片
Git & GitHub图文详解(不详细叫人打我)_第19张图片


3.2、设置签名

Git安装之后需要进行一些签名基本信息设置

作用:区分不同开发人员的身份
辨析:这里设置的签名和登录远程库(代码托管中心)的账号、密码没有任何关
系。
设置签名有两种方式:一种是为单个仓库单独设置,这种方式只针对单个仓库有效;另一种是全局配置,采用这种方式配置后,所有仓库都有效。如果对两种方式都进行了配置,那么会优先使用单个仓库配置方式的配置信息。

项目级别(仓库级别)签名:仅在当前本地库范围内有效
a、设置用户名:git config user.name [用户名]
b、设置用户邮箱:git config user.email [邮箱]
c、取消设置用户名:git config --unset user.name
d、取消设置用户名:git config --unset user.email

签名信息保存位置:./.git/config 文件
如:
Git & GitHub图文详解(不详细叫人打我)_第20张图片
设置完成之后可以再使用git config --list命令进行查看


系统用户级别:登录当前操作系统的用户范围
a、设置用户名:git config -- global user.name [用户名] ‘你在github上注册的用户名’;
b、设置用户邮箱:git config -- global user.email [邮箱] ‘注册时候的邮箱’;
c、取消设置用户名:git config -- globa --unset user.name
d、取消设置用户名:git config -- globa --unset user.email
签名信息保存位置:~/.gitconfig 文件

注意:git config --global 参数,有了这个参数表示你这台机器上所有的git仓库都会使用这个配置,当然你也可以对某个仓库指定不同的用户名和邮箱
Git & GitHub图文详解(不详细叫人打我)_第21张图片

签名级别优先级:

  1. 就近原则:项目级别优先于系统用户级别,二者都有时采用项目级别的签名
  2. 如果只有系统用户级别的签名,就以系统用户级别的签名为准
  3. 二者都没有是不允许,至少要设置一个签名。

3.3、查看文件提交到暂存区状态

命令:git status

本章节我们要用到vim编辑器,如果对vim命令不熟的同学可以参看文章:
vim 命令使用小结

演示:
1、使用命令查看文件提交状态
Git & GitHub图文详解(不详细叫人打我)_第22张图片

2、新建一个文件,再查看状态

新建文件可以用touch [文件名]也可以用vim [文件名]
还可以用echo ,例如:
在这里插入图片描述
该命令和vim一样,可以直接生成一个txt文件,且能将文本内容直接写入txt文件。

这里我们就使用vim编辑器来创建文件:
在这里插入图片描述
写入文件内容:
Git & GitHub图文详解(不详细叫人打我)_第23张图片
再次查看状态:
暂存区对比工作区,发现一个未提交的文件
Git & GitHub图文详解(不详细叫人打我)_第24张图片


3.4、提交文件到暂存区

查看暂存区是否有文件,可以使用命令git ls-files -s(不要求掌握)

命令:git add [文件名] #提交指定文件到暂存区
   git add ./    #提交所有内容到暂存区

Demo.txt文件提交到暂存区:
Git & GitHub图文详解(不详细叫人打我)_第25张图片

注 1:如果执行了git add以后,可以使用git ls-files -s命令来查看缓存区是否存在git对象,或者是否有东西。
在这里插入图片描述
注 2:如果想要查看git对象文本里面的内容,可以使用命令git cat-file -p [git对象哈希值]
例如:
Git & GitHub图文详解(不详细叫人打我)_第26张图片
其中这个哈希值其实就是object文件夹中的
Git & GitHub图文详解(不详细叫人打我)_第27张图片

只要执行了git add,此时该文件就是一个已跟踪文件,已经执行了快照,能通过哈希值找到。存在于暂存区的Demo.txt文件此时状态为已暂存(stage),如果想要删除该文件,可使用命令git rm --cached Demo.txt删除暂存区文件,此时文件状态就变成了未暂存(unstage)


3.5、提交文件到本地库

命令: git commit [文件名]

在这里插入图片描述
Git & GitHub图文详解(不详细叫人打我)_第28张图片
Git & GitHub图文详解(不详细叫人打我)_第29张图片
提交完成以后:
Git & GitHub图文详解(不详细叫人打我)_第30张图片
在工作区查看提交的文件:
Git & GitHub图文详解(不详细叫人打我)_第31张图片


3.6、修改文件到本地库

在原有的Demo.txt文件上修改东西增加点东西:
在这里插入图片描述
Git & GitHub图文详解(不详细叫人打我)_第32张图片
查看状态:
Git & GitHub图文详解(不详细叫人打我)_第33张图片
此时git在工作区检测到一个未提交的文件,并提示:
可以使用 git add [文件名]命令提交到暂存区
可以使用git checkout [文件名] 去放弃(取消)本次修改

可以使用git commit -a [文件名] 直接提交到本地库

也可以加上提交备注:git commit -a -m [备注] [文件名]
其实该命令的底层也是先执行了git add ,然后才提交到本地库
-a 就是 git add的简写

现在我们将修改的文件放到暂存区
Git & GitHub图文详解(不详细叫人打我)_第34张图片
添加文件到本地库,并机上注释:

命令:git commit -m [备注内容] [要提交的文件]
在这里插入图片描述


3.7、查看文件修改内容和时间

命令:git blame [文件名]
Git & GitHub图文详解(不详细叫人打我)_第35张图片

3.7、查看提交历史

命令:git log 显示提交的详细信息。
包括:哈希值(版本码)、签名用户和邮箱,提交时间,备注

Git & GitHub图文详解(不详细叫人打我)_第36张图片

命令:git log --pretty=oneline
显示版本哈希值、备注
Git & GitHub图文详解(不详细叫人打我)_第37张图片

命令:git log --oneline
显示部分哈希值和备注
Git & GitHub图文详解(不详细叫人打我)_第38张图片

命令:git reflog
除了显示版本哈细值,备注,还显示当前指针需要移动的步数才能回到指定版本。
Git & GitHub图文详解(不详细叫人打我)_第39张图片


3.8、历史版本前进与回退

命令:git reset --hard [版本号]
该命令可用于git历史版本的前进与后退
Git & GitHub图文详解(不详细叫人打我)_第40张图片
同样,该命令都可以用于版本前进与后退

使用^符合,该符合只能往后,不能往前
命令:git reset --hard HEAD^
如果想要后退两步,三步可以这样写:
  git reset --hard HEAD^^
  git reset --hard HEAD^^^
Git & GitHub图文详解(不详细叫人打我)_第41张图片

如果我们想要回退到第20个版本,我们不可能写20个^,此时我们可以使用~
同样该符号只能回退,不能前进
命令:git reset --hard HEAD~[后退次数]
Git & GitHub图文详解(不详细叫人打我)_第42张图片

3.9、reset 命令的三个参数对比

控制指针的命令:git reset 有三个参数:

--soft 参数
  1、仅仅在本地库移动HEAD 指针
解释:本地库虽然移动了版本指针,此时暂存区和本地仓库的的历史版本还是移动指针之前的。此时使用git status查看暂存区状态,由于工作区和暂存区内容一致,暂存区可以等待执行git commit [文件名]提交内容到本地库

--mixed参数:
  1、在本地库移动HEAD 指针
  2、重置暂存区
解释:本地库移动了版本指针,暂存区的内容也随着指定版本更新内容,此时由于工作区与暂存区文件内容不同,所以用户可以选择执行git add [文件名]直接提交更新到暂存区

--hard参数:
  1、在本地库移动HEAD 指针
  2、重置暂存区
  3、重置工作区
解释:本地库移动了版本指针,工作区和暂存区也随着指定版本更新内容。


3.10、删除操作

命令:rm [文件名] #删除工作区文件,需要执行git addgit commit才能提交到本地库
命令:git rm [文件名] #删除工作区文件,并执行git add提交到了暂存区,修改成了暂存状态,此时只需要直接使用git commit -m [备注] [文件名]即可提交到本地库


3.11、找回本地库已删除文件

提示1
  Git只会增加版本记录,不会删除,哪怕本地库做了删除操作都会增加版本记录。
所以即便是后退到了一开始的版本,最终修改后的版本也会存在,可以随便进、退。
提示2
  缓存区删除的文件,可以在工作区重新提交。

问题:本地库删除的文件怎么找回呢?
答案因为git不会删除版本记录,所以使用指针回退到未删除的版本即可。
1、新建一个文件并提交到本地库:
Git & GitHub图文详解(不详细叫人打我)_第43张图片
2、从本地库删除文件
Git & GitHub图文详解(不详细叫人打我)_第44张图片
3、从本地库找回文件:
Git & GitHub图文详解(不详细叫人打我)_第45张图片


3.12、比较文件差异

命令:git diff [文件名] 工作区的文件内容和暂存区进行比较

修改文件内容:
在这里插入图片描述
Git & GitHub图文详解(不详细叫人打我)_第46张图片
2、工作区内容和暂存区进行比较:
在这里插入图片描述

命令:git diff HEAD [文件名] 工作区的文件内容和本地库进行比较
Git & GitHub图文详解(不详细叫人打我)_第47张图片
也可以指定和某个历史版本进行比较:
Git & GitHub图文详解(不详细叫人打我)_第48张图片

如果不写比较的文件名称,那么就会列出所有的所有 有差异的文件:
命令:git diffgit diff HEAD
Git & GitHub图文详解(不详细叫人打我)_第49张图片


3.12、三个常用的撤销命令

git commit --amend 撤销上一次提交 ,并将暂存区文件重新提交
git checkout -- 拉取暂存区文件 并将其替换成工作区文件
git reset HEAD -- 拉取最近一次提交到本地库的文件,到暂存区 改操作不影响工作区

简单的来说 就是可以帮我们从版本库中 拉取文件到 暂存区 当我们把工作区的某个文件弄乱了 我们就可以使用该命令 把版本库中的那个文件拉到暂存区 然后在拉回工作区
详细参考:https://blog.csdn.net/qq_36431213/article/details/78858848


3.13、文件重新命名

命令:mv [原文件名] [新文件名] #修改工作区文件名
   git mv [原文件名] [新文件名] #重命名工作区文件,并执行了git add提交到暂存区。


四、分支管理

4.1、分支简介

  假如某某游戏公司要开发王者荣耀,在游戏框架和英雄角色模型确定的情况下进行开发。接下来要做的事情是游戏团队设计英雄技能,美工负责设计英雄皮肤,文案负责设置英雄背景故事。那么此时是不是需要等文案写完所有英雄故事,然后游戏开发才开始设计英雄技能,完了美工才开始英雄皮肤。如此下来整个游戏的开发周期会大大增加。而分支管理就可以实现这一需求,将整个游戏开发设计为一下分支同时进行:

  游戏框架和已的所有角色模型确定为master主干分支
  英雄文案策划为子分支分支A
  英雄皮肤设置为子分支分支B
  游戏上线如果存在Bug需要在不停止服务情况下修复分支hot_fix
然后几个子分支在主干分支的基础上,各自完成各自的开发工作,使游戏正常运营。
Git & GitHub图文详解(不详细叫人打我)_第50张图片
作用:

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

4.2、分支操作

在使用git init初始化完本地库之后,就创建了master主干分支。

4.2.1、查看所有分支

查看当前所有分支

命令:git branch #查看所有分支,* 号代表当前工作分支
git branch -v #查看分支详情,包括分支指向的commitId及提交信息
Git & GitHub图文详解(不详细叫人打我)_第51张图片


4.2.2、新增分支

命令:git branch [分支名]
Git & GitHub图文详解(不详细叫人打我)_第52张图片


4.2.3、重新命名分支

命令:git branch -m [新分支名称]
Git & GitHub图文详解(不详细叫人打我)_第53张图片


4.2.4、切换分支

命令: git checkout [分支名] 切换到指定分支
git checkout -b [分支名] 创建并切换到指定分支
Git & GitHub图文详解(不详细叫人打我)_第54张图片
注意很严重的坑
  使用git check的之前最好使用git status查看一下项目是否有未暂存的修改 或 有未提交的暂存,如果当前分支的工作区上存在以上其中一种情况,且此时又执行了git check切换到主分支,git为了不让子分支上工作区中的文件丢失,会保存到主分支。那么此时主分支上会看到这个文件,此时主分支相当于受到了污染,当主分支执行commit之后就会将污染提交到版本库。


4.2.5、合并分支

  如果两个分支没有产生分叉情况,那么会进行快速合并,即fast-forward方式,它并不会产生新的commitId,只是改变了指针的指向,产生分叉合并可能会有冲突情况。

合并分支:
第一步:1、切换到接受修改的分支(被合并,增加新内容)上
    命令:git checkout [被合并分支名]
第二步:执行merge 命令
    命令:git merge [有新内容分支名]

演示:合并hot_fix分支到master分支,此时合并为fast-forward方式
Git & GitHub图文详解(不详细叫人打我)_第55张图片
Git & GitHub图文详解(不详细叫人打我)_第56张图片
Git & GitHub图文详解(不详细叫人打我)_第57张图片

合并分支:
第一步:1、切换到接受修改的分支(被合并,增加新内容)上
    命令:git checkout [被合并分支名]
第二步:执行merge 命令
    命令:git merge [有新内容分支名]
Git & GitHub图文详解(不详细叫人打我)_第58张图片

分支合并细节

git merge --no-ff -m "msg" #合并分支时禁用Fast forward模式

  我们知道如果使用fast-forward方式进行分支合并,只是简单改变了分支指针,而不会产生新的commit记录。
  为了保证合并数据的完整性,我们也可以在合并时指定不使用fast-forward方式,使用 --no-ff 选项。这样,在merge时就会生成一个新的commit,从日志上就可以看到分支合并记录了。
例子:
Git & GitHub图文详解(不详细叫人打我)_第59张图片
Git & GitHub图文详解(不详细叫人打我)_第60张图片


4.2.6、合并分支冲突解决

  当对分叉分支进行合并时,如果两个分支都对同一文件进行了修改,那么合并时就有可能会产生冲突情况。
  如果两个分支对同一文件的修改是有规律的,比如对不同地方的修改,那么git工具可以实现自动合并,如果无法自动合并,则需要对冲突文件进行手动修改,修改完成后使用git add表示冲突已经解决,然后使用git commit进行提交

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

演示:

Git & GitHub图文详解(不详细叫人打我)_第61张图片
Git & GitHub图文详解(不详细叫人打我)_第62张图片
Git & GitHub图文详解(不详细叫人打我)_第63张图片
同样,主干分支也对该文件进行操作:
Git & GitHub图文详解(不详细叫人打我)_第64张图片
在这里插入图片描述
Git & GitHub图文详解(不详细叫人打我)_第65张图片
在svn里面,如果合并产生冲突,是会产生一个冲突文件的,但是git里面不会产生冲突文件,而是在冲突文件中的内容作了特殊标识:
在这里插入图片描述
Git & GitHub图文详解(不详细叫人打我)_第66张图片
此时我们主要对该文件就行修改,修改成自己想要的效果,然后提交到本地库即可解决冲突:
Git & GitHub图文详解(不详细叫人打我)_第67张图片
Git & GitHub图文详解(不详细叫人打我)_第68张图片
Git & GitHub图文详解(不详细叫人打我)_第69张图片


4.2.7、删除分支

注意:删除分支前都需要先切换到其他分支才能进行删除操作

命令:git branch -d [分支名]
删除一个干净的分支(即 相对当前分支而言该分支没有过提交记录就为干净的分支)Git & GitHub图文详解(不详细叫人打我)_第70张图片

命令:git branch -D
#强制删除一个分支,该分支如果存在过提交记录,想要删除就必须使用 -D
Git & GitHub图文详解(不详细叫人打我)_第71张图片


4.2.8、恢复分支

思路
  对于已经有提交记录的分支删除后,实际上只是删除指针,commit记录还保留,如果想恢复,需要使用git reflog查找该分支指向的commitId,然后根据commitId创建新的分支

命令:git branch #根据指定commit创建新分支
Git & GitHub图文详解(不详细叫人打我)_第72张图片
Git & GitHub图文详解(不详细叫人打我)_第73张图片
注意回退指针的方式是不能恢复分支的
如:
Git & GitHub图文详解(不详细叫人打我)_第74张图片


4.2.9、分支应用场景模拟

场景:
  公司的商城系统存在一个bug,bug代号为 [53],此时需要在不停止项目服务的情况修复bug,测试通过后合并的主分支上。
  正在修复【53】bug的过程中,这时候老板突然打电话给你,让你紧急去解决【68】bug,此时该怎么做?

1、新创建一个分支去修复[53]bug
Git & GitHub图文详解(不详细叫人打我)_第75张图片

2、此时你接到老板的电话,紧急处理【68】bug,也就意味的需要去创建一个分支先处理【68】bug,为了不让【53】bug的工作白做,需要先将【53】bug提交:
Git & GitHub图文详解(不详细叫人打我)_第76张图片
3、创在【68】Bug分支来紧急出来68Bug:
Git & GitHub图文详解(不详细叫人打我)_第77张图片

查看一下此时的分支图:Git & GitHub图文详解(不详细叫人打我)_第78张图片
当然也可以使用gitk工具来查看:
在这里插入图片描述
Git & GitHub图文详解(不详细叫人打我)_第79张图片

4、处理完成以后进行合并:
Git & GitHub图文详解(不详细叫人打我)_第80张图片
合并完成之后可以删除分支:
Git & GitHub图文详解(不详细叫人打我)_第81张图片

4、完成提交:
Git & GitHub图文详解(不详细叫人打我)_第82张图片


五、 Git基本原理

5.1、哈希

  哈希是一种加密算法,是一个将明文转化成密文的过程,无论是音频、视频都可以使用哈希算法加密。包括MD5也就哈希算法中的一种。
在这里插入图片描述
哈希是一个系列的加密算法,各个不同的哈希算法虽然加密强度不同,但是有以下
几个共同点:
①不管输入数据的数据量有多大,输入同一个哈希算法,得到的加密结果长度固定。
②哈希算法确定,输入数据确定,输出数据能够保证不变
③哈希算法确定,输入数据有变化,输出数据一定有变化,而且通常变化很大
④哈希算法不可逆
Git 底层采用的是SHA-1 算法。
哈希算法可以被用来验证文件。原理如下图所示:
Git & GitHub图文详解(不详细叫人打我)_第83张图片


5.2、Git 保存版本的机制

5.2.1 集中式版本控制工具的文件管理机制

  以文件变更列表的方式存储信息。这类系统将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。
  比如SVN,在svn服务器上保存的就是在原来的版本上修改的东西,当你想要某个版本的时候,SVN服务器就将原版本内容和改本的内容进行合并,从而生成你想要的版本。该方式能够节省保存服务器的空间。


5.2.2 Git 的文件管理机制

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


5.2.3、 Git 文件管理机制细节

一个文件,使用了git add命令之后就会生成一个git对象,此时目录中会生成index,这个index文件就是暂存区,在生成暂存区之前,底层会先生成一个树对象,树对象中包含了所有add的文件,然后执行快照放入object文件夹中,此时才完成git add整个流程。也就是其实执行git add之后,是先执行了快照放入了本地库,然后才存入了暂存区中。

Git 的“提交对象”
在这里插入图片描述
提交对象及其父对象形成的链条:
Git & GitHub图文详解(不详细叫人打我)_第84张图片


5.3、Git 分支管理机制

分支管理机制详细讲解请参考官方文档:Git 分支 - 分支简介


六、Git & GitHub团队协作

  学习完成团队内部的git之后,现在我们来使用git操作远程库(代码托管中心GitHub)来进行学习。
为了方便学习,首先在GitHub上注册三个邮箱账号:

创建细节参考文章:
https://blog.csdn.net/weixin_42693104/article/details/82584849

------公司团队项目经理账号: XlangVlang
------公司团队成员账号:xiaojie874062877
------路人账号:XiaoWang9527

6.1、团队内协作

Git & GitHub图文详解(不详细叫人打我)_第85张图片

项目经理创建远程仓库:

1、登录项目经理账号,新创建个仓库,不对仓库进行初始化。
Git & GitHub图文详解(不详细叫人打我)_第86张图片
创建一个空仓库,不对仓库进行初始化:
Git & GitHub图文详解(不详细叫人打我)_第87张图片

Git & GitHub图文详解(不详细叫人打我)_第88张图片
Git & GitHub图文详解(不详细叫人打我)_第89张图片


项目经理创建本地仓库

1、项目经理在本地创建一个本地仓库,并将代码推送至远程仓库。

新建一个文件夹作为本地仓库:
Git & GitHub图文详解(不详细叫人打我)_第90张图片
初始化本地库:
Git & GitHub图文详解(不详细叫人打我)_第91张图片
设置项目级别签名:
Git & GitHub图文详解(不详细叫人打我)_第92张图片
在工作区里面新建文件,并提交到本地库:
在这里插入图片描述

项目经理为远程仓库配置别名与其对应的URL

为远程仓库配置别名与其对应的URL

命令:git remote -v #显示远程仓库使用的Git别名与其对应的URL ,别名可以随便取
命令:git remmote add [项目别名] [URL] #这个Url地址是远程仓库的url
Git & GitHub图文详解(不详细叫人打我)_第93张图片

演示:
Git & GitHub图文详解(不详细叫人打我)_第94张图片


项目经理推送本地仓库到远程仓库

命令:#查看分支图
git log --graph --decorate --oneline --simplify-by-decoration --all

命令:git push [项目别名] [分支名] #本地仓库代码推送到远程仓库

注意:因为远程仓库地址我们使用的是https协议的,现在我们要将本地库代码推送到远程库,需要告诉远程库是谁来访问的自己,由于我们来项目成员和项目经理对远程库访问的演示,所以在使用不同角色访问远程库的时候记得删除访问凭据信息,否则提交到远程库的信息将不会变:
Git & GitHub图文详解(不详细叫人打我)_第95张图片
Git & GitHub图文详解(不详细叫人打我)_第96张图片

演示:
Git & GitHub图文详解(不详细叫人打我)_第97张图片
推送成功:
Git & GitHub图文详解(不详细叫人打我)_第98张图片

刷新GitHub:
Git & GitHub图文详解(不详细叫人打我)_第99张图片
Git & GitHub图文详解(不详细叫人打我)_第100张图片


成员克隆远程仓库到本地

命令:git clone [远程仓库URL] #成员克隆项目到本地
Git & GitHub图文详解(不详细叫人打我)_第101张图片

项目成员新建一个文件夹,进行初始化,并设置签名,然后直接从远程仓库上克隆项目:
Git & GitHub图文详解(不详细叫人打我)_第102张图片


项目经理邀请成员加入团队

在项目成员完成项目代码的时候,想要将自己的内容提交到远程库,前提条件是该成员已经受到远程库创建者的邀请,加入了一个团队中:
1、远程仓库发出邀请
Git & GitHub图文详解(不详细叫人打我)_第103张图片
Git & GitHub图文详解(不详细叫人打我)_第104张图片
Git & GitHub图文详解(不详细叫人打我)_第105张图片
Git & GitHub图文详解(不详细叫人打我)_第106张图片

2、项目成员接收邀请
发送邀请成功以后,被邀请者的邮箱会收到一封邮件,只要他登录邮箱,接收邀请即可。
Git & GitHub图文详解(不详细叫人打我)_第107张图片
然后项目经理重新登录远程库,发现已经成功邀请了成员:
Git & GitHub图文详解(不详细叫人打我)_第108张图片


成员推送内容到远程库

命令:git push [项目别名] [分支名] #成员推送任务到远程库

演示:
Git & GitHub图文详解(不详细叫人打我)_第109张图片
此时再刷新页面,发现:
Git & GitHub图文详解(不详细叫人打我)_第110张图片


项目经理更新成员提交的内容

命令:git fetch [远程仓库别名] [分支名]
#查看分支图
命令:git log --graph --decorate --oneline --simplify-by-decoration --all
知识:在项目的clone与push的过程中,本来只存在两个分支,一个是本地的master分支,一个是远程仓库的master分支,然后现在由于成员push了内容,所以会在本地master和远程master分支中间生成一个远程跟踪分支(中介分支),所以在更新远程仓库数据的时候,会先将数据更新到中介分支上,我们需要使用主分支将中介分支上的内容进行合并。

演示:
Git & GitHub图文详解(不详细叫人打我)_第111张图片
Git & GitHub图文详解(不详细叫人打我)_第112张图片
Git & GitHub图文详解(不详细叫人打我)_第113张图片


6.2 深入远程跟踪分支

远程跟踪分支

知识
1、远程跟踪分支是在执行git push之后默认生成了别名为origin远程跟踪分支的。
2、只有在clone的时候,本地分支(master)和远程跟踪分支(taobao/master)是有数据同步的。无论是执行git push(推送)或是git fetch(拿取)的时候,都是本地分支和远程分支做通讯,

1、一般公司成员在克隆完远程仓库项目的时候,不直接对主分支做修改,而是新建一个分支,然后在分支上修改代码。:

Git & GitHub图文详解(不详细叫人打我)_第114张图片
刷新远程仓库GitHub:
Git & GitHub图文详解(不详细叫人打我)_第115张图片
Git & GitHub图文详解(不详细叫人打我)_第116张图片
在push之后,确实生成了一个远程跟踪分支:
在这里插入图片描述

2、项目经理去feath项目跟新的文件,因为远程仓库上有两个分支,如果想要都拿到两个分支的文件,项目经理需要也创建一个对应的子分支来获取更新文件:
Git & GitHub图文详解(不详细叫人打我)_第117张图片
Git & GitHub图文详解(不详细叫人打我)_第118张图片
整个拿取子分支文件的过程比较复杂繁琐。

问题:每次push都需要指定分支名称才能提交,而且fetch之后,需要合并才能拿到数据,其中最主要的原因还是因为中间有个跟踪远程分支。那么我们可以在push的时候直接不写项目名和分支名进行推送吗?

实践结果:
  经过实践后发现,成员主分支(master),在做了文件修改之后可以通过直接使用git push推送到远程库,因为只有执行了clone命令才和远程库同步,但是子分支(xiaojie_A)则不行,会报语法错。
  事实上,无论我们执行push还是执行fetch都是远程跟踪分支和远程分支在做交互,那么我们如何从能直接从本地分支推送到远程分支,或者直接从远程分支拿取到本地分支呢?
Git & GitHub图文详解(不详细叫人打我)_第119张图片
此时,此时如果项目经理想要拿数据,可以使用更高级的命令git pull,前提也是要对成员子分支进行跟踪才可以,因为成员master执行了clone命令的分支,所以成员分支可以直接git pull
Git & GitHub图文详解(不详细叫人打我)_第120张图片
成员可以直接pull:
在这里插入图片描述

总结
1、当clone克隆一个分支的时候,其实是自动创建了一个跟踪origin/master的master的分支,所以可以直接pull和push。

2、git fetch命令或拿取所有远程库上更新的文件,但是不会去和远程跟踪分支建立跟踪关系,需要自己进行手动合并,执行merage

3、如果想要去让别人共享一个,那么可以使用以上的方式共享到远程库。如果不想让别人共享,那么可以不进行追踪。同事也可以在创建一个分支的时候就执行让其去跟踪远程跟踪分支:命令: git branch -b xiaojie_A origin/xiaojie_A
使用命令:git branch -vv可以查看所有跟踪分支
例如:
在这里插入图片描述

正常的数据推送和拉取步骤:
1、确保本地分支已经跟踪了远程跟踪分支:git branch -u [想要追踪的远程跟踪命令]
2、拉取数据:git pull
3、上传数据:git push


git pull和git fetch的区别:

相同点
首先在作用上他们的功能是大致相同的,都是起到了更新代码的作用。
#fetch
.fetch:相当于是从远程获取最新版本到本地,不会自动merge

git fetch orgin master //将远程仓库的master分支下载到本地当前branch中
git log -p master ..origin/master //比较本地的master分支和origin/master分支的差别
git merge origin/master //进行合并

这个命令会访问远程仓库,从中拉取所有你还没有的数据。 执行完成后,你将会拥有那个远程仓库中所有分支的引用,可以随时合并或查看。

  如果你使用git clone 命令克隆了一个仓库,命令会自动将其添加为远程仓库(git remote -v)并默认以 “origin” 为简写。 所以,git fetch origin 会抓取克隆(或上一次抓取)后新推送的所有工作。 必须注意 git fetch 命令会将数据拉取到你的本地仓库 - 它并不会自动合并或修改你当前的工作。 当准备好时你必须手动将其合并入你的工作。

  如果你有一个分支设置为跟踪一个远程分支,可以使用 git pull命令来自动的抓取然后合并远程分支到当前分支。 这对你来说可能是一个更简单或更舒服的工作流程;默认情况下,git clone 命令会自动设置本地 master 分支跟踪克隆的远程仓库的 master 分支(或不管是什么名字的默认分支)。 运行 git pull 通常会从最初克隆的服务器上抓取数据并自动尝试合并到当前所在的分支。

#pull
git pull:相当于是从远程获取最新版本并merge到本地

git pull origin master //相当于git fetch 和 git merge

:用git pull更新代码的话就比较简单暴力了但是根据commit ID来看的话,他们实际的实现原理是不一样的,所以不要用git pull,用git fetch和git merge更加安全。


删除远程分支

三个命令一般配套使用

命令:git push origin --delete [远程分支名] #删除远程分支
命令:git remote prune origin --dry-run #列出仍在远程跟踪但是远程已经删除的无用分支
命令:git remote prune origin #清除上面命令列出来的远程跟踪


6.3、远程协作冲突

远程操作的时候,无论是执行push还是pull的时候都会有冲突的发生。
从头做一遍演示,并显示解决冲突问题:

1、登录GitHub新建一个仓库Git & GitHub图文详解(不详细叫人打我)_第121张图片

2、创建一个本地仓库,放入项目代码,并将文件push到远程仓库:
在这里插入图片描述
Git & GitHub图文详解(不详细叫人打我)_第122张图片
推送代码到远程仓库:
Git & GitHub图文详解(不详细叫人打我)_第123张图片

3、B团队成员从远程仓库上克隆代码,修改项目内容后提交:
在这里插入图片描述
Git & GitHub图文详解(不详细叫人打我)_第124张图片
小王邀请小张加入开发团队,一起做XXDong项目:
Git & GitHub图文详解(不详细叫人打我)_第125张图片

然后小张就可以顺利提交代码到远程仓库了:
Git & GitHub图文详解(不详细叫人打我)_第126张图片
Git & GitHub图文详解(不详细叫人打我)_第127张图片

4、小王从远程仓库从拿取项目文件:
Git & GitHub图文详解(不详细叫人打我)_第128张图片
Git & GitHub图文详解(不详细叫人打我)_第129张图片

5、小王现在又接到某个任务,需要写某个功能的代码,为了项目的安全性,小王决定新建一个分支,并在分支上完成功能后再进行合并:
Git & GitHub图文详解(不详细叫人打我)_第130张图片
6、小李此时想要更新小王的提交到远程库上的最新文件,然后自己也在分支上新增一个文件:
Git & GitHub图文详解(不详细叫人打我)_第131张图片
Git & GitHub图文详解(不详细叫人打我)_第132张图片
7、小王再创建有一个追踪分支,然后从上获取文件:
Git & GitHub图文详解(不详细叫人打我)_第133张图片

8、制造一个冲突:
此时小王和小李同时对一个文件进行修改,且小李先修改好文件进行了推送:
小李推送任务:
Git & GitHub图文详解(不详细叫人打我)_第134张图片
小王修改好文件正要推送:
Git & GitHub图文详解(不详细叫人打我)_第135张图片
9、冲突解决:
小王先get pull代码,然后再进行修改:
Git & GitHub图文详解(不详细叫人打我)_第136张图片
这个时候就解决问题了。
同样,如果小李修改了文件,并被push到远程仓库,此时小王也对同样的文件进行修改,修改了以后文件执行pull,这时候也会报冲突问题。小王可以将文件放到本地库中,然后先pull代码,再修改冲突,修改完成以后再执行push即可。


6.4、团队外协作

  如果你想要参与某个项目,但是并没有push推送权限,这时可以对这个项目进行“派生(Fork)”。派生是指GitHub将在你们空间中创建一个完全属于你的项目副本,且你对副本具有完全的操作权限。通过这种方式,项目的管理者不需要忙着把用户添加到贡献者列表并给予他们推送权。非对内成员可以派生这个项目,将修改推送到派生的项目副本中,并通过创建合并请求(Pull Request)来让非队内成员的改动进入源版本库中。
Git & GitHub图文详解(不详细叫人打我)_第137张图片
:所有的开源下项目都有一个fork功能。
Git & GitHub图文详解(不详细叫人打我)_第138张图片
Git & GitHub图文详解(不详细叫人打我)_第139张图片

流程演示:
1、模拟去远程仓库上fork一个项目源码:
Git & GitHub图文详解(不详细叫人打我)_第140张图片

然后fork一个该项目到自己的GitHub远程仓库:
Git & GitHub图文详解(不详细叫人打我)_第141张图片

fork完成以后就可以在自己的仓库里面找到该项目Git & GitHub图文详解(不详细叫人打我)_第142张图片

2、新建一个文件夹作为本地仓库,然后去自己的远程仓库clone到本地:
在这里插入图片描述
Git & GitHub图文详解(不详细叫人打我)_第143张图片

2、由于现在是项目的A1_branch分支代码出问题了,所以进入该分支修改并提交:
Git & GitHub图文详解(不详细叫人打我)_第144张图片

3、确定修改已经提交成功以后,发送pull请求,等待公司团队审核。
Git & GitHub图文详解(不详细叫人打我)_第145张图片
Git & GitHub图文详解(不详细叫人打我)_第146张图片
Git & GitHub图文详解(不详细叫人打我)_第147张图片

4、此时公司团队项目经理重新登录GitHub,然后对pull请求进行审核:
Git & GitHub图文详解(不详细叫人打我)_第148张图片
Git & GitHub图文详解(不详细叫人打我)_第149张图片
查看bug详情,并回复小张,拒绝审核通过:
Git & GitHub图文详解(不详细叫人打我)_第150张图片

5、小张再次登录GitHub,查看pull请求:
Git & GitHub图文详解(不详细叫人打我)_第151张图片
Git & GitHub图文详解(不详细叫人打我)_第152张图片

6、看到回复后小张继续修改代码,然后进行再次提交。
Git & GitHub图文详解(不详细叫人打我)_第153张图片
点击“close and comment”以后:
Git & GitHub图文详解(不详细叫人打我)_第154张图片
此时就算是项目经理登录,也看不到他的回复了。如果想要让项目经理知道,只能是修改完成Bug以后重新发起Pull 请求:
方法一(本方法)
Git & GitHub图文详解(不详细叫人打我)_第155张图片
Git & GitHub图文详解(不详细叫人打我)_第156张图片

方法二
项目经理登录:
Git & GitHub图文详解(不详细叫人打我)_第157张图片
Git & GitHub图文详解(不详细叫人打我)_第158张图片
显示:
Git & GitHub图文详解(不详细叫人打我)_第159张图片
此时点击按钮进行合并即可:
Git & GitHub图文详解(不详细叫人打我)_第160张图片
Git & GitHub图文详解(不详细叫人打我)_第161张图片

7、项目经理再次审核,然后进行合并操作(合并操作如上图所示)。

8、查看是否合并成功:
Git & GitHub图文详解(不详细叫人打我)_第162张图片

9、如果此时又出现了问题,项目经理需要再向小张求助:
Git & GitHub图文详解(不详细叫人打我)_第163张图片
然后拉到最下面,提交文件:
Git & GitHub图文详解(不详细叫人打我)_第164张图片

10、由于小张是fork的之前的版本,但是最新提交的版本又没有,该怎么做呢?
登录小张github,发现版本没变:
Git & GitHub图文详解(不详细叫人打我)_第165张图片
此时需要重新换一个项目别名或者重新建立项目别名与访问URL的关系,去重新pull项目:
Git & GitHub图文详解(不详细叫人打我)_第166张图片


七、Git中.gitignore的配置语法

  在日常的开发中,当我们需要将一个项目提交到Git时,并不是所有的文件都需要提交,比如一些自动生成的文件,这时候就可以使用.gitignore来忽略一些不需要提交的文件,本文着重介绍一下.gitignore的配置语法。

创建
  当使用Eclipse时,我们需要在提交Git之前,需要自己创建一个.gitignore文件,由于Windows下创建文件必须键入文件名,而要创建的.gitignore是没有文件名的,所以我们可以使用move命令来实现,打开Git Bash ,使用mv gitignore .gitignore,然后可以编辑器编辑这个文件。
在这里插入图片描述

Git & GitHub图文详解(不详细叫人打我)_第167张图片

常用的规则

/mtk/ 过滤整个文件夹
*.zip过滤所有.zip文件
/mtk/do.c过滤某个具体文件

以上规则意思是:被过滤掉的文件就不会出现在你的GitHub库中了,当然本地库中还有,只是push的时候不会上传。
除了以上规则,它还可以指定要将哪些文件添加到版本管理中。

!src/不过滤该文件夹
!*.zip 不过滤所有.zip文件
!/mtk/do.c不过滤该文件

1、配置语法:
以斜杠/开头表示目录;
以星号*通配多个字符;
以问号?通配单个字符
以方括号[]包含单个字符的匹配列表;
以叹号!表示不忽略(跟踪)匹配到的文件或目录;

此外,git 对于 .ignore 配置文件是按行从上到下进行规则匹配的,意味着如果前面的规则匹配的范围更大,则后面的规则将不会生效;

2、示例说明
a、规则:fd1/*
说明:忽略目录 fd1 下的全部内容;注意,不管是根目录下的 /fd1/ 目录,还是某个子目录 /child/fd1/ 目录,都会被忽略;

b、规则:/fd1/*
说明:忽略根目录下的 /fd1/ 目录的全部内容;

c、规则:/*
!.gitignore
!/fw/bin/
!/fw/sf/
说明:忽略全部内容,但是不忽略 .gitignore 文件、根目录下的 /fw/bin/ 和 /fw/sf/ 目录;

Github给出的Android开发中使用的.gitignore模板:

# Built application files
*.apk
*.ap_
# Files for the Dalvik VM
*.dex
# Java class files
*.class
# Generated files
bin/
gen/
out/
# Gradle files
.gradle/
build/
# Local configuration file (sdk path, etc)
local.properties
# Proguard folder generated by Eclipse
proguard/
# Log Files
*.log
# Android Studio Navigation editor temp files
.navigation/
# Android Studio captures folder
captures/
# Intellij
*.iml
# Keystore files
*.jks

忽略文件的具体使用可参考:
Git中使用.gitignore忽略文件的推送


八、idea中使用Git

8.1、修改IntelliJ IDEA的maven插件默认仓库地址

(该步骤一般用于使用idea频繁创建工程使用,当然不修改也是可以的。)
Git & GitHub图文详解(不详细叫人打我)_第168张图片
1、指定自己的mavne仓库
Git & GitHub图文详解(不详细叫人打我)_第169张图片

2、添加阿里云仓库:
Git & GitHub图文详解(不详细叫人打我)_第170张图片
3、指定maven编译环境:
Git & GitHub图文详解(不详细叫人打我)_第171张图片
配置结果:
Git & GitHub图文详解(不详细叫人打我)_第172张图片
Git & GitHub图文详解(不详细叫人打我)_第173张图片


8.2、安装Git核心程序

默认情况下,IDEA是不自带git运行程序的,所以需要通过
菜单->settings->Version Control->Git->Path to Git executable: 设置为安装git中所安装的git.exe
Git & GitHub图文详解(不详细叫人打我)_第174张图片

8.3、设置github账号

接下来为github设置账号密码:
  菜单->settings->Version Control->GitHub->Add account
设置好了之后,IDEA的git准备工作就做好了
Git & GitHub图文详解(不详细叫人打我)_第175张图片

Git & GitHub图文详解(不详细叫人打我)_第176张图片


8.4、初始化本地仓库

在IDEA中创建一个项目,并将该项目初始化为一个本地仓库:
Git & GitHub图文详解(不详细叫人打我)_第177张图片
Git & GitHub图文详解(不详细叫人打我)_第178张图片
效果1: 文件颜色变成红色,表示当前文件与暂存区文件存在差异:
Git & GitHub图文详解(不详细叫人打我)_第179张图片
Git & GitHub图文详解(不详细叫人打我)_第180张图片

效果2:显示Git工具管理项目的路径:
Git & GitHub图文详解(不详细叫人打我)_第181张图片

效果3:
Git & GitHub图文详解(不详细叫人打我)_第182张图片


8.5、添加Git忽略文件

方法一:使用新增的方式添加Git忽略文件。(当然也可以手动在工作区目录下添加)
Git & GitHub图文详解(不详细叫人打我)_第183张图片
Git & GitHub图文详解(不详细叫人打我)_第184张图片

方法二:在本地仓库的exclude文件中写忽略文件(这种方式方便一点)
Git & GitHub图文详解(不详细叫人打我)_第185张图片

Git & GitHub图文详解(不详细叫人打我)_第186张图片


8.6、添加文件到暂存区

选中项目,右键,Git,Add:
Git & GitHub图文详解(不详细叫人打我)_第187张图片
添加到暂存区的文件颜色变成了绿色:
Git & GitHub图文详解(不详细叫人打我)_第188张图片


8.7、取消暂存区文件的添加或者修

方法一:
Git & GitHub图文详解(不详细叫人打我)_第189张图片
方法二:
Git & GitHub图文详解(不详细叫人打我)_第190张图片

8.8、添加文件到本地库并提交的远程库

先在GitHub上创建一个远程仓库,用于提交本地库代码:
Git & GitHub图文详解(不详细叫人打我)_第191张图片

方法一:
Git & GitHub图文详解(不详细叫人打我)_第192张图片

方法二:
Git & GitHub图文详解(不详细叫人打我)_第193张图片
Git & GitHub图文详解(不详细叫人打我)_第194张图片
提交完成以后,项目文件颜色就变成了正常颜色。

这里会询问你要提交的哪里去,点击Define remote,并输入在" 创建成功,得到git地址 "步骤中的:
Git & GitHub图文详解(不详细叫人打我)_第195张图片
提交到远程仓库:
Git & GitHub图文详解(不详细叫人打我)_第196张图片

或者也可以自己手动提交本地库代码到远程库:
Git & GitHub图文详解(不详细叫人打我)_第197张图片


8.9、切换Git历史提交版本

1、编辑文件,并进行多次提交
Git & GitHub图文详解(不详细叫人打我)_第198张图片
Git & GitHub图文详解(不详细叫人打我)_第199张图片
2、提交多个版本以后,可以进行查看历史提交版本:
Git & GitHub图文详解(不详细叫人打我)_第200张图片
当然在这也可以:
Git & GitHub图文详解(不详细叫人打我)_第201张图片
Git & GitHub图文详解(不详细叫人打我)_第202张图片

如果想要回到哪个版本可以这样使用:
1、右键,复制历史版本号
Git & GitHub图文详解(不详细叫人打我)_第203张图片
2、找到Reset HEAD:
Git & GitHub图文详解(不详细叫人打我)_第204张图片
3、选择Hard,并且张贴上刚刚赋值的版本号即可:
Git & GitHub图文详解(不详细叫人打我)_第205张图片
:使用Idea工具只能像SVN一样,回到版本1之后,如果在想回到版本2,在idea中是不支持的。如果想要回到版本2,只能通过Git的命令函操作来实现了。


8.10、创建分支以及合并分支

创建分支
1、找到创建分支的选项卡:
Git & GitHub图文详解(不详细叫人打我)_第206张图片
Git & GitHub图文详解(不详细叫人打我)_第207张图片
Git & GitHub图文详解(不详细叫人打我)_第208张图片
Git & GitHub图文详解(不详细叫人打我)_第209张图片

此时我们在所在当前分支在A_branch,在该分支上进行代码修改,并进行提交:
Git & GitHub图文详解(不详细叫人打我)_第210张图片
查看历史:
Git & GitHub图文详解(不详细叫人打我)_第211张图片

合并分支到主线
1、先切换到主分支(master分支)
Git & GitHub图文详解(不详细叫人打我)_第212张图片
Git & GitHub图文详解(不详细叫人打我)_第213张图片
并查看master分支提交历史:
Git & GitHub图文详解(不详细叫人打我)_第214张图片

2、合并分支:
Git & GitHub图文详解(不详细叫人打我)_第215张图片
勾选想要合并的分支,填写备注,并提交:
Git & GitHub图文详解(不详细叫人打我)_第216张图片
此时再查看历史,发现代码内容已经和分支进行了合并:
Git & GitHub图文详解(不详细叫人打我)_第217张图片


8.11、Git解决冲突

1、主干先提交一个版本:
Git & GitHub图文详解(不详细叫人打我)_第218张图片
查看历史:
Git & GitHub图文详解(不详细叫人打我)_第219张图片

2、切换到A分支,A分支同样也在同一个代码文件中做做修改:
Git & GitHub图文详解(不详细叫人打我)_第220张图片
添加内容并且提交:
Git & GitHub图文详解(不详细叫人打我)_第221张图片
查看历史:
Git & GitHub图文详解(不详细叫人打我)_第222张图片

3、切回主干,合并分支:
Git & GitHub图文详解(不详细叫人打我)_第223张图片
合并分支:
Git & GitHub图文详解(不详细叫人打我)_第224张图片
合并完成以后,发现产生了冲突,这个冲突是由于主分支和A分支提交代码冲突引起的:
Git & GitHub图文详解(不详细叫人打我)_第225张图片

这里推荐使用手动的方法来解决冲突:
显示冲突,并合并冲突:
Git & GitHub图文详解(不详细叫人打我)_第226张图片
解决冲突以后:
Git & GitHub图文详解(不详细叫人打我)_第227张图片
冲突解决完以后查看历史:
Git & GitHub图文详解(不详细叫人打我)_第228张图片

当然,也以上所有的操作可以先在本地工作区内解决了冲突以后,再一次性将完整的代码上传的远程仓库也是可以的,而且更推荐后者,将合并后的代码一次上传到远程库的方式更好。


8.12、Git更新当前最新的本地库

如果是团队协同开发,团队成员如果提交了代码到远程库,那么我们要如何进行跟新呢?

1、在线修改GitHub代码,模拟团队成员提交:
Git & GitHub图文详解(不详细叫人打我)_第229张图片
此时,远程库上的内容是最新的,如果此时你使用idea工具进行push本地库的代码,此时idea会报错Push Rejected(拒绝push)的一个提示框。想要解决此问题,有两种方法:
  一种是点击提示框中的Merge或者Rebase和远程库进行合并。
  另外一种就是直接使用update,然后选择Merge`或者`Rebase
Git & GitHub图文详解(不详细叫人打我)_第230张图片
还有一种方法,这种方式,如果有冲突再来解决冲突:
Git & GitHub图文详解(不详细叫人打我)_第231张图片


8.13、idea克隆项目到本地库

1、到远程库复制一个将要clone的仓库地址:
Git & GitHub图文详解(不详细叫人打我)_第232张图片

2、idea中找到clone命令
Git & GitHub图文详解(不详细叫人打我)_第233张图片
Git & GitHub图文详解(不详细叫人打我)_第234张图片
Git & GitHub图文详解(不详细叫人打我)_第235张图片

你可能感兴趣的