git学习【完结】

git_1">git 学习【完结】

文章目录

git 学习【完结】
- 一、Git基本操作
- - 1.创建本地仓库
  - 2.配置本地仓库
  - - 1.局部配置
    - 2.全局配置
  - 3.认识工作区、暂存区、版本库
  - 4.添加文件
  - 5.修改文件
  - 6.版本回退
  - 7.撤销修改
  - 8.删除文件
- 二、Git分支管理
- - 1.理解分支
  - 2.创建、切换、合并分支
  - 3.删除分支
  - 4.合并冲突
  - 5.合并模式
  - 6.分支策略
  - 7.bug分支
  - 8.强制删除分支
- 三、Git远程操作
- - 1.理解分布式版本控制系统
  - 2.创建远程仓库
  - 3.克隆远程仓库_HTTPS
  - 4.克隆远程仓库_SSH
  - 5.将本地提交到远程
  - 6.拉取远程操作
  - 7.忽略特殊文件
  - 8.配置命令别名
  - 9.标签管理
  - 10.删除标签
- 四、Git实战场景
- - 1.多人协作场景一
  - 2.多人协作场景二
  - 3.解决远程分支删除本地仍可见的问题
- 五、企业级开发模型
- - 1.什么是企业级开发

一、Git基本操作

1.创建本地仓库

mkdir gitcode
cd gitcode
git init  #初始化

2.配置本地仓库

git 配置项 name,email
git config user.name "ljh"
git config user.email "123123@qq.com"
git config -l # 查看配置项
git config --unset user.name # 删除配置项
git config --global user.name "ljh"
# 生效于所有的git仓库 因为往往我们的服务器上有很多git仓库# 注意不能直接重置
git config --global --unset user.name

1.局部配置

2.全局配置

3.认识工作区、暂存区、版本库

我们在gitcode目录下，创建一个文件，命名为ReadMe

目前情况下，Git能否管理ReadMe文件呢？是不行的！！这里这个.git 称为版本库（仓库）,ReadMe称为工作区，图示如下：

stage叫做暂存区/索引，也可以称为index

对工作区的修改包括：新增、修改、删除

在我们的版本库中存在一个objects区域：我们修改的工作区的内容会写入对象库的git对象中。

stage和master中存的都是索引，objects中存的才是对象。

注意：.git目录是不支持在该目录下进行手动修改的！！！

4.添加文件

git add ReadMe
git add . # 将当前目录下所有文件添加到暂存区

git commit -m "add first file" # 本次提交的细节信息

git log # 查看提交日志
# commit: 哈希计算的数字，十六进制
# Author:ljh <....qq.com>
# Date: 
# add first file
git log --pretty=oneline # 仅打印一行log

cat .git/HEAD # ref:refs/heads/master
cat ./git/refs/head/master # 最新一次提交的commit号

我们的commit号：前两位：文件号后面：文件标识

git cat-file -p commit号
# tree: 所有的commit
# parent: 上一次提交的commit号
# author
# committer: add 3 file commit的内容/更改的内容

要记住！git追踪管理的其实是修改，而不是文件！

git status # 查看当前仓库的状态 哪些文件在工作区被修改了

5.修改文件

如果要查看进行了哪些修改【查看暂存区和工作区文件的差异】

git diff ReadMe

a/ ：表示修改前 b/：表示修改后根据上图可以发现改动前后文件名没有变化

@@ -1 表示改动前一行 +1,2 表示改动后，连续两行

也可以 git diff HEAD - - [file] 查看版本库和工作区文件的区别

总结：git status + git diff 的组合可以用来查看哪些内容发生了修改+修改了哪些内容

6.版本回退

假如我们现在有两个版本的ReadMe，v1版本内容为git，v2版本内容为git world

git reset [ --soft | --mixed | --hard ] [HEAD]
# 本质是回退的版本库的内容，还可以回退到当前版本

工作区	暂存区	版本库
git world	git world	git world
git world	git world	git 【- -soft】
git world	git	git 【- -mixed 默认】
git	git	git 【- -hard 慎用】

具体使用方法：

git log - -pretty=online 得到的结果如下：
commit号1 (HEAD->master) modify ReadMe
commit号2 add file5
commit号3 add 3 file
commit号4 add first file 我想要回退到这个版本
使用 git reset - -hard commit号4 （注意工作区也回退！！！）
运行结果：HEAD is now at 58doaa3【commit号前几位】 add first file【commit 内容】
此时我们 la => .git ReadMe cat ReadMe => hello git
我们输入 git log - -pretty=oneline => commit号4 ( HEAD-> master) add first file
如果反悔了，怎么办？我们刚刚打印出了最近一次修改的commit号1，此时我们使用 git reset - -hard commit号1，我们发现，所有的内容都回来了！log也回来了。为什么有反悔药可以吃呢？因为当前的终端还保留了之前的commit号，如果清掉屏幕/服务器关掉，再次使用git log 就拿不到之前的commit号了，那现在怎么办呢？
可以使用git reflog 这个指令记录每一次的提交命令，可以得到每次commit对应的短的commit号，使用这个短的commit号也可以进行恢复

为什么每次回退的速度都很快呢？原因如下图：

我们实际上回退的时候仅仅修改了master中的commit ID，所以速度很快

7.撤销修改

如果我们在我们的工作区写了很长时间代码，越写越写不下去，觉得自己写的实在是垃圾，想恢复到上一个版本

会出现下面几种情况

工作区	暂存区	版本库	解决方式
1.xxx code			1.手动撤销——不推荐，易出错 2.git checkout - - [filename] ——推荐
2.xxx code	xxx code		git reset
3.xxx code	xxx code	xxx code	前提条件：commit之后没有push，使用git reset - -hard HEAD^

情况2的解决方案一：git reset HEAD ReadMe 【默认是 - -mixed 的】，HEAD表示回退到当前版本，HEAD^ 表示回退到上一版本，我们情况2的当前版本库为空。- -mixed 是暂存区和版本库回退，所以暂存区的 xxx code就清掉了，此时仅工作区有内容，就回到了情况1。之后我们再使用情况1的解决方案，git checkout - -Reade 即可

情况3：版本库存在最新版本的代码 xxx code，但是上一版不包含 xxx code，我们通常使用git进行版本控制的流程如下：工作区->(git add)->暂存区->(git commit)->版本库->(git push)->远程仓库，我们情况3撤销的前提是在commit之后没有进行push，撤销的目的就是不要影响远程仓库的代码。此时我们直接使用指令 git reset - -hard HEAD^ 即可。

8.删除文件

我们删除一个文件通常有两种方式：

首先 rm file5 删除工作区的内容，然后 git add file5 将删除提交同步至暂存区，最后再 git commit -m “delete file5” 将删除同步到版本库
首先使用git rm file5 将工作区，和暂存区的内容都删掉，最后使用git commit -m “delete xxx” 将删除提交到版本库即可。

二、Git分支管理

1.理解分支

我们首先来看一个例子以便于我们更好的理解git分支功能：

HEAD可以指向其他分支，被指向的分支就是当前正在工作的分支。

2.创建、切换、合并分支

git branch # 查看当前本地有哪些分支

git branch dev # 创建一个名为dev的分支
cat .git/refs/heads

并且可以发现他们俩指向的提交的commit号是相同的，此时的状态为：

我们如何切换分支呢：

git checkout dev

此时状态变成了：

注：在dev分支上修改代码，不会影响master分支【工作区、暂存区、版本库都是】

我们在dev上提交代码，此时状态变为了：

那我们如果让master和dev合并，master也保持最新状态呢？分为以下两步：

git checkout master
git merge dev

我们此时再

cat .git/refs/heads/master

发现此时的master主分支的commit id和dev分支之前的commit id 是相同的

3.删除分支

删除本地分支，为了节约资源，指令为：

git branch -d dev

因为创建，合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

4.合并冲突

git合并冲突是怎么造成的呢？

假如我们原来：master分支和dev分支上的内容都是 aaa on dev branch

这时候我们将dev分支上的内容修改为 bbb on dev branch，并且将master分支上的内容修改为 ccc on dev branch，我们再使用git merge指令来合并，就会发生冲突！！！如何解决呢？

我们先在我们的服务器上复现出来上面出现的这种情况，这里再介绍一个新的指令：

git checkout -b dev1
# 这条指令等于 git branch dev1 + git checkout dev1

模拟完上面的状态后，此时git中的状态图为：

我们再次切换到master分支上，然后尝试去合并

git merge dev1

如何解决冲突呢？我们先看一下我们master分支下的ReadMe文件

我们的解决方案是：手动 vim ReadMe，然后删除掉不需要的代码即可，再将修改后的文件进行add和commit就ok了。

此时git中的状态就是：

我们再去验证下dev分支下还是不是原来的数据：

此外，git也是提供可视图的：

git log --graph --abbrev-commit

5.合并模式

git merge的模式：fast-forward模式：看不出来最新的提交到底是merge进来的还是正常提交的

介于fast-forward模式看不出来是否是合并而来的，所以合并可采用no-ff模式【很推荐，分别找锅】，即：

git merge --no-ff -m "merge dev2" dev2

此时提交后的状态图信息为：

6.分支策略

有了分支，就可以进行多人协作开发了

7.bug分支

我们先模拟一下这个场景：

这种情况是我们不能忍受的！

我们的解决方案是使用 git stash 指令，要注意的是，git stash只能存储被git管理的文件，使用git stash后，工作区的代码就被存入到stash中了，且此时切回master分支时，未提交的代码不会影响master分支的使用。

后续需要处理stash中存储的工作区的内容时，可以通过：

git stash list # 查看stash中存储了哪些内容
git stash pop  # 将stash中内容恢复到工作区

这个时候就可以转去master分支去修复bug了，dev1分支上工作区的内容不会影响到master分支，我们基于master分支的基础上再创建fix_bug分支，去修复bug，修复完成后合并到主分支。此时的状态图如下：

此时如果让master去合并dev 这个操作是不可取的！因为dev上的bug还未修复，会和master冲突。

正确的做法是：让dev去合并master，合并后就算有问题也可以在本地分支多次修改测试，不会影响master代码，此时的状态：

8.强制删除分支

这个需求的场景如下：

git branch -d # 不行，只能删被merge后的分支
git branch -D # 强制删除

三、Git远程操作

1.理解分布式版本控制系统

之前我们学的都是本地完成的版本控制，接下来我们来尝试下远程操作：

我们的中央服务器通常为：github / gitee，这俩是我们常用的代码托管平台。

2.创建远程仓库

这里操作很简单，省略了。

值得注意的是：当我们的开发者开发完dev分支后，我们如果想要将我们的dev分支merge到主分支上，这个操作是不被允许的！我们正确的操作是，需要先创建PR（Pull Request，合并申请单）给管理员，当管理员审核通过之后才可以继续进行merge操作。

3.克隆远程仓库_HTTPS

git clone https://.......(https协议)
# 代码仓库克隆

值得注意的是：千万不要在本地的git仓库目录下克隆！！因为我们本地的git仓库已经是有.git版本库维护的！

git remote
# 打印远程仓库的默认名字，一般为origin

git remote -v
# 查看当前仓库所拥有的权限 push(本地->远程)，fetch(远程->本地)

4.克隆远程仓库_SSH

当前情况下，我们需要先创建公钥：

我们需要在本地配置SSH公钥，我们如何配置呢？

创建SSH key。在用户主目录下，看看有没有 .ssh 目录，再看看这个目录下有没有id_rsa 和 id_rsa.pub 这两个文件
没有怎么办
1. 回到主家目录
2. ssh-keygen -t rsa -C “邮箱” 注意这个邮箱要跟gitee上配置的邮箱相同
3. cat id_rsa.pub 查看公钥
添加自己的公钥到远端仓库，配置后再git clone

5.将本地提交到远程

我们先使用 git config -l 看本地的配置项（需要和远程仓库保持一致）

git config -l

那如何将修改从本地提交到远程？

git push origin(远程仓库名) master(本地):master(远程)

如果本地分支和远程分支的名字是相同的，那么远程名可以省略。我们如何建立远程和本地的联系的呢？在我们clone的时候！

6.拉取远程操作

当我们的远程仓库的内容比本地内容更新的时候，我们需要拉去并合并（使用的是fast-forward模式）

git pull origin master:master
# 如果远程仓库分支与本地仓库的分支一致时，等价于
git pull origin master

7.忽略特殊文件

我们平时的日常开发中，我们有些开发文件是不想上传到远端仓库被别人看见的！我们如果在gitee上面创建仓库的时候没有勾选gitignore文件时：我们可以在我们的本地仓库中 vim .gitignore

# 可以直接写文件名
*.so
*.ini
# 写入后git提交的时候会忽略.so和.ini文件
!b.so # 不排除 b.so

我们使用：

git add -f b.so # 强制增加
git check-ignore -v d.so # 查看d.so 为什么被忽略

8.配置命令别名

我们之前想查看一下当前git的状态，使用的是git status指令，但是这个指令实在是有点长了，我们能不能给他简短一下，简化为git st

git config --global alias.st status
# 给git status 起别名为 git stgit log --pretty=oneline --abbrev-commit
# git config --global alias.lpa 'log --pretty=oneline --abbrev-commit'

9.标签管理

标签tag，可以简单理解是为了给某次commit起一个标识，相当于起一个别名。例如：我们对最后一次commit起一个 v1.0 这样的标签来标识里程碑的意义。之后我们在使用版本回退的时候就可以利用tag来方便记忆，而不是使用难以记住的commit_id。打标签的指令：

git tag v1.0 # 标签名，默认是对最新的commit打标签
git tag # 查看有哪些标签 或者
tree .git # 在refs下的tags可以看到标签v1.0(最新一次的commit_id)

如果我们需要对之前的提交打tag呢？

首先，我们需要使用git log --pretty=oneline --abbrev-commit来定位commit_id
然后，git tag v0.9 4ee30f7 (某一次的commit_id) 或者
git tag -a v0.8 -m “important tag: xxx” 7722302(某个commit_id)
git show v0.8 查看tag的详细信息

10.删除标签

如果我们要删除v0.9这个标签：

git tag -d v0.9

我们如果想要将本地标签推送到远端如何操作呢？

git tag #查看本地有哪些标签
# v1.0git push origin v1.0 #将标签推送到远程

我们如果想要删除远端的标签该如何操作呢？

git tag -d v1.0 # 在本地删v1.0git push origin :v1.0 # 在远程删v1.0

四、Git实战场景

1.多人协作场景一

首先，在远程gitee上创建一个分支，命名为dev分支：

我们之前讲过 git branch 指令，这里我们再做一些扩展：

git branch -a # 查看本地+远程的分支
git branch -r # 查看远程分支
git branch # 查看本地分支

我们可以使用一个git pull 指令，直接将我们刚刚在远程创建的dev分支，拉去到本地上！

这里可能会有人有疑问，为什么需要建立连接，当我们需要使用简写的指令的时候，比如git push,git pull的时候，我们的远程仓库和本地仓库必须提前建立连接，如果我们是使用指定好远程和本地的指令，比如git push origin master ( 指定好了，不用建立连接)，注意，我们在本地使用git clone的时候会自动将远程仓库与本地建立连接。
我们的开发者2是window用户，直接在某个目录下克隆我们的远程仓库即可！

现在目前的状态为：

现在我们开发者1要开始自己的开发了，我们的做法是，开发者1现在本地建立他自己的dev分支，并且将这个本地的dev分支与远程仓库的dev分支进行连接：

我们再介绍一个指令，这条指令可以看我们远程的仓库与本地仓库建立的连接关系

git branch -vv

此时的状态为：

这时候我们切换到开发者2，我们开发者2在创建分支的时候并没有与远程的dev分支相互连接，

那么这个时候肯定是不可以直接使用 git pull 或者 git push 的，需要我们手动的去连接远程与本地的连接。我们手动将本地分支与远程分支建立连接的操作是：

git branch --set-upstream-to=origin/dev dev

注意我们的开发者2，在clone远程仓库的时候，没有aaa，但是我用户2再提交的时候，用户1在远程仓库上增加了aaa，所以这里我们需要解决冲突！

解决冲突的办法是：我们先手动的将远程的仓库pull下来，然后手动的打开文件解决冲突！然后再使用 git push 提交即可

我们手动解决掉下图中的冲突，然后再次提交即可

修改成功后，我们使用git commit指令和git push指令即可！完成之后我们现在的状态为，远程仓库的dev仓库上既有aaa又有bbb，但是远程仓库的master分支上啥也没有！我们现在就需要将远程仓库的dev分支与远程仓库上的master分支进行合并

我们有两张方式对远程的仓库进行合并：

直接走远程，使用PR单子
本地：本地有dev和master，我们在本地的master 去merge dev【可能出现冲突，最好是用dev 去merge master(这个master必须是保持最新的，如果不是最新的还需要先使用git pull) 】，然后push master (aaa bbb)

最后我们删除掉远程仓库中的dev分支即可！总结如下，注意在这种模式下，我们需要解决冲突，而解决冲突往往是一件非常恶心的事情！

2.多人协作场景二

我们的场景如下，每个开发者各自私有一个分支。和场景一不同的是，我们这次要在不同分支下协作完成。

远程创建分支（推荐的，我们可以保证远程的master分支一定是最新的分支）
本地创建分支 -> push（我们演示的，但是需要注意的是我们要确保本地的master分支保持最新）

首先，我们开发者1，创建一个feature-1分支，在此分支上创建函数文件，然后上传提交 , 操作如下:

不过我们当前直接向远程push是不可以的 , 因为我们还没有向远程仓库建立连接 :

我们直接在push的时候,指定好远端 , 这样代码在上传到远端的时候,就会在远端也创建feature-1 分支了 !!!

此时我们再去切换到开发者2分支上去,要记得我们一定要先进行pull操作 !!! 因为要保证我们当前开发者的master分支上存放的是最新的代码 !

之和就是跟之前一样,我们开发者2也创建自己的分支,然后开发代码,最后再进行提交。

此时再去查看我们的远程上面就有三个分支了，

此时，我们的状态就变为了：

正常情况下，你俩就可以在自己分支上进行专业的开发了，但天有不测风云，你的小伙伴突然生病了，但需求还没开发完，需要你帮他继续开发，于是他便把feature2 分支名告诉你了。这时你就需要在自己的机器上切换到feature-2 分支帮忙继续开发！

我们回到开发者1，我们二话不说先查看下开发者1当前可用看到哪些分支，然后直接进行git pull 指令，将远程仓库的代码先拉去下来，操作如下：

可以看到，我们是检测到了开发者2所开发的分支了的，并且我们成功的将feature2 分支拉去了下来！！！这就是很神奇的一件事了。

我们没有建立连接，为什么还可以用这个短的git pull指令呢？我们再来解释下git pull 指令：

拉去分支内的内容
拉去仓库的内容

此时我们的远程是有feature2分支，但是本地是没有的，此刻我们需要在开发者1的本地上创建feature2分支，并且与远程的feature2分支建立连接。

此时我们开发者1就可以帮助开发者2进行开发了。等开发者2回来以后，我们的开发者2继续他的开发工作时，需要先建立链接，然后再使用git pull 指令，将远程仓库中开发者1开发的代码拉去到本地中。

到这里我们的开发者1和开发者2就都完成了他们的开发工作并且上传到了远程仓库中，我们接下来将远程仓库上分支上的内容合并进master分支上即可！
我们这次就采用在远程通过pull Request单子的形式来合并吧：

接下来就交给审查人员和测试人员即可！

当我们的feature2分支的合并请求被通过以后，此时的状态为：

我们再将feature1与master分支合并的时候会发生冲突吗？有可能是，所以这里我们应该用fearture1分支去合并master

我们当前已经完成了第一步，fearture2合并进主分支，我们还需要完成第二步：master合并到feature1分支上去解决冲突，还有第三步：解决完冲突后的feature1分支合并进主master分支。接下来进行实操：
首先，我们进入master分支，pull一下当前远程仓库中的最新的master分支的代码：