Git-实战详解

Posted 2022-12-13 写Bug的渣渣高

很多时候，学习 Git 可能往往是为了保存自己的代码开发进度，管理团队的代码。所以很多时候，一般的学生或者是普通的程序员，也只需要了解该如何用ta。重要的不是你会多少条指令，而是你知道在何种情况下，该用哪一条指令，只有真正自己能用到的指令，才算自己真正学会了
文章的脊髓在使用篇

看文助手

• 本文不适合纯小白，如果不了解 git 是什么，不了解 add ,coommit，不推荐阅读本文
• 如果你懂得 add commit ，那么跳转到使用篇
• 如果是遇到了使用篇的那些情况，可以直接跳转
• 如果你想了解一些命令使用流程，可以跳转总结
  

  文章目录

  • • • 看文助手
    • 配置篇 -- 初次见面
    • • 初次见面
      • 踏入正轨-- 创建仓库
      • 初次尝试 -- 管理你的仓库文件
      • 正式登场 -- 项目管理
    • 使用篇---最佳实践
    • • 分离头指针的注意情况
      • 比较两个文件的差异
      • 修改commit 的 message
      • 合并多个 commit
      • 使用 rebase 遇到错误怎么办
      • 比较暂存区和HEAD所含文件的差异
      • 比较暂存区和工作区
      • 将暂存区恢复成HEAD一样
      • 如何让工作区的文件恢复成咱暂存区一样
      • 消除最近的几次提交
      • 看不同提交的差异
      • 正确删除文件的方法
      • 开发时遇到紧急需求
      • 指定不需要Git管理的文件
    • 全篇总结--精彩回顾

配置篇 – 初次见面

初次见面

当我们创建项目和 Git 初次见面时，它不知道我们叫什么,第一步就是，告诉它我们的名字和邮箱，先让他知道我是谁

 git config -- global user.name '你的名字'
 git config -- global user.email '你的邮箱'
	含义：在全局范围下设置自己的名字和邮箱
创建完之后,使用如下命令进行查看设置是否正确
 git config --list 

小拓展1：
邮箱不要设置为假的邮箱，名字可以为假名字
为什么要它要知道我的名字和邮箱？
>>>> git 作为分布式版本控制，它需要知道本次 commit 由谁提交，才能方便的进行控制
小拓展2
如果你的电脑可能由几个人使用，电脑中也包含几个人的项目，如何保证我的项目使用的名字和邮箱不错误？
下面是设置本仓库的用户信息
>>>> git config --local user.name ‘你的名字’
>>>> git config --local user.email ‘你的邮箱’
在本地的仓库中，local优先级大于global,即在你的仓库中查看用户信息，那么显示的就是这个仓库用户信息，即local

---

---

踏入正轨-- 创建仓库

如果要问，如何写出一个完美的项目，第一步该怎么做，那一定是先创建一个仓库
给已经存在的代码文件放入仓库

在安装好git之后，打开项目文件夹
git init

用命令新建一个项目

git init 项目名称

下载项目

git clone 网址

下载项目实操
找到一个你想要下载的项目

复制之后，使用命令即可

初次尝试 – 管理你的仓库文件

现在你创建好你的仓库了，你要做一个合格的管理者，对文件管理就像是管理一个团队

招兵买马 – 创建新文件

创建文件夹
mkdir 文件夹名.后缀名
新建一个文件，但是不进入
touch 文件名.后缀名
创建并进入编辑
vim 文件名.后缀名

编辑文件内容

这里主要是简单讲一下如何使用git里面的编辑器来编辑内容

新建一个文件并进入编辑

按 英文字母 i 进入编辑内容状态
输入完成后

• esc 退出编辑状态
• 输入:wq 退出编辑框

重命名文件

git mv 原文件 新文件  
注意要带后缀

查看文件列表

ls -al

正式登场 – 项目管理

下面的内容才是 git 最引以为傲的功能,git 中有工作区，暂存区，版本库

• 工作区：你当前正在打代码的区域，这里的代码没有被管理
• 暂存区：暂时存放你提交的代码记录，相当于时工作区和版本库之间的缓存区
• 版本库：当你完成了一个小功能，可以提交到版本库中，这里会保存你的很多提交的记录，可以切换提交记录，并查看以往提交记录中的文件，并且能够修改，在以往的基础上构建代码

查看状态

命令用于显示工作目录和暂存区的状态。
git status

提交代码至暂存区

基本操作
git add 文件1 文件2
git add * 将仓库中所有未加入仓库的文件加入暂存区

进阶操作
将目录及其子目录加入到暂存区
git add 目录  

提交代码至本地仓库

git commit  --m  备注

查看提交记录

查看当前分支提交记录
git log 
查看最近n条提交记录
git log -n
查看所有分支提交记录
git log --all
查看图形化的所有分支提交记录
git log --all  --graph 
查看最近n条图形化的所有分支提交记录
git log --all --graph --n4
简洁的方式查看分支提交记录
git log --oneline 

查看分支

git branch 查看本地仓库
git branch -r 查看远程仓库

创建新的分支
需要依附于一个 commit 然后创建一个新的分支

git checkout -b 分支名

切换分支

git checkout master 切换到master分支

总结:
新建仓库—>>管理文件—>>>编辑文件，提交至暂存区------>>>确定暂存区的代码可靠性------>>>提交至本地仓库
切换分支—>> 先保存本地未缓存的代码----->>>切换

checkout实战操作
使用这个命令,切换到以前提交的 commit 中，可以查看以往 commit 的文件内容,也可以在那个 commit 的文件基础上面新建分支。比如说我需要在上一次提交的基础上，新增一个功能，但是功能比较难实现，我们可以切换到上一次提交，然后在上一次提交的基础上面开发，如果开发成功，那么新建一个分支保存记录，有需要的时候就合并新建分支到主分支上面。如果开发失败，并且不需要保留代码，强制切换回主线程。
注意，这个命令需要搞明白在使用，使用的时候要注意 git 的提醒。


查看提交的 commit 记录



复制 commit 后面的版本号,输入

git checkout 版本号

当进入这里以后,他会告诉你,你现在处于头指针分离的状态,你可以在这个分支的基础上开发,在这个分支上的代码可以被你抛弃,也可以被你保留(在这个 commit 的基础上面创建一个新的分支即可)
当你修改了一个文件内容,然后提交后,可以发现,当前状态是头指针分离.

假如你的新功能开发失败,代码确定不想要了,下面直接

git chekcout master

就能跳转至主分支,git 还会告诉你,如果在切换之前,你都没有给那个 commit 创建分支,即使你切换之后,他也会提醒你,是否要保留代码,如果保留,现在还来得急在 那个 commit 的基础上创建一个新分支,在那个 commit 基础上的其他 commit ,也都会保留到新创建的分支中.
总的来说,其实 checkout 命令并没有那么可怕,只要你在使用命令的时候,认真看看 git 的提示,那么基本上不会出错.

使用篇—最佳实践

下面会介绍一些在使用 Git 使用中可能遇到的情况，以及，我到底该怎么办，相比于上面的内容，这里的内容，可能才是真正需要的

分离头指针的注意情况

上面说了chekcout 的具体使用,下面来解释一下这个命令
下面开始实践

解释
当你想查看以往 commit 中具体的代码内容的时候，就得使用 checkout 了.不过，如果用不好这个，你就很可能丢失你的本地代码

在查看的时候，一般我们可以看见下面那个图所示，HEAD指向一个分支，这代表HEAD指向一个具体分支，其本质就是指向这个分支上最新的 commit 。如果用 checkout 到以往提交的一个具体的 commit 这个时候实际上是没有与任何的分支挂钩的，如果我们想尝试在这个 commmit 的基础上编写一个不知道是否可行的功能,可以使用这个命令,然后可以在这个没有挂钩分支的commit中继续编写功能,当你发现了这个不可行,可以直接放弃,如果想保存的话,就在这个 commit 的基础上面新建一个分支即可,让 这个 commit 有归属的分支

危险在什么地方:

当你在这个 commit 下进行了很多修改,在尝试编写一个功能,但是一天你突然被告知master分支上面,有一个 bug 需要修复,你切换的时候,HEAD指向的这个 commit 多出了一些新的 commit ,但是这些 commit 属于没有归属分支的提交,如果你强制转换,那么 git 可能会清空你的这些代码

怎么解决这个分支:

在这个 commit 的基础上创建一个分支
git branch 新分支名字 分支的 版本号

大家看看这个HEAD指针指向那个分支
-这个分支其实只指向了testNewBranch，后面的代表，两个分支处在同一个版本上

比较两个文件的差异

git diff 记录1 记录2
git diff HEAD HEAD^1 把HEAD和HEAD的父亲比对

修改commit 的 message

git commit --amend 修改最新的 commit 的 message
git rebase -i <修改commit的父commit> 修改老版本的 commit 的 message

仍然是输入 i 进行编辑,修改上面的文字即可,修改好 esc + :wq 退出

修改老版本 commit 的 message
输入

git rebase -i <修改commit的父commit

然后修改pick --> r

注意注意：不能随意对团队仓库分支上面随便更改

合并多个 commit

当你发现你的几个 commit 完成的都是同一个功能下的子功能,你可以把它们合并成一个 commmt

git rebase -i <合并commit的父commit>

现在有三个分支，我们想吧增加新文件和修改新文件，合并成一个

如果我们想合并修改文件和增加新文件 输入:

git rebase --i 365bafe65ec3d9df
–i 后面是想合并的 commit 的父 commit

进入编辑，下面的是各种命令，我们如果想把两个合并在一起，其实就是把第一个合并到第二个上面
输入 i 进入编辑模式,我们把第二行的 pick 改成 s ,然后esc + :wq 退出
在This is combination of 2 commits 下一行输入 合并后的 message 然后退出就行（也可以不输入合并后的 message git 可以自动合并两次提交的 message ）

使用 rebase 遇到错误怎么办

在上面编辑分支的时候，很容易删除了一行pick 版本号,或者说，你删除了 rebase 编辑中的某些字符，会导致分支“消失”
当你 rebase 的时候，编辑错了文本，无法完成rebase，那么退出之后，你会发现，分支没了。
那么该怎么办

我再次执行刚才合并两个分支的界面进行演示
刚才我重写进入编辑了，然后删除了一些内容，导致 rebase 合并失败（中断）

然后，分支就没了，但是你仔细看

现在处于的状态是master|rebase,说明你 rebase 未完成,或者 rebase 有错误,无法成功执行

我们可以使用如下命令,如果是不小心退出了，那么就继续编辑，如果是编辑错了。就放弃刚才编辑的内容，然后你的分支就回来了

git rebase --continue 继续执行
git  rebase --edit-todo 来继续执行
git rebase --abort 放弃刚才编辑的 rebase 文本

可以看到，状态改变了，然后分支也能找到了

比较暂存区和HEAD所含文件的差异

背景：当你提交了一个 commit 然后想看看，我当前的HEAD指向的 commit 和暂存区的有什么区别。
此命令可能会在你切换分支，切换 commit 的时候使用
git diff --cached

比较暂存区和工作区

背景：看看缓存区的和工作区代码的区别有多少,或者比较具体某个文件的区别

git diff 默认情况下就是比较暂存区和工作区

git diff – 文件名

将暂存区恢复成HEAD一样

背景：当你提交了几个 commit 之后，发现新功能研发失败，有几个 commit 可以废弃了，当你完全确定废弃的时候，可以使用这个来直接强制回到你觉得有用的分支上

git reset HEAD

git reset HEAD 取消暂存区的所有(执行完后，可以使用git diff --cached查看)

如何让工作区的文件恢复成咱暂存区一样

假如我认为工作区的做出的新修改，甚至没有暂存区的好。

git checkout --文件

消除最近的几次提交

比较危险，如果某个commit彻底不想要了，在使用这个

git reset --hard 版本号 强制回到某个commit

看不同提交的差异

比较两个commit的文件的差异

git diff 分支 分支 [-- file]

git diff commit1 commit2 [-- file]

上面，分支其实代表的也是一个commit,分支代表的都是一系列分支中的，最新的 commit

正确删除文件的方法

删除之后，可以使用 ls -al 来查看删除状态

git rm 文件名 这里时从本地仓库中删除文件,删除了之后需要提交

git -rm --cached file 将文件从暂存区里面删除

开发时遇到紧急需求

遇到紧急的BUG，可能比当前正在编写的功能要重要的多，我们需要立刻放下手里的活，然后修复 bug 完成后，在编写自己的活

git stash

执行后，工作区时干净的（当时的会保存，）

解决完紧急BUG

git stash apply

git stash list 查看

实操
我们来看一看当前的状态，然后新建一个新的文件，把这个当作我们正在编写的功能，然后突然，遇到要紧急修复的 bug 了
由于十分紧急，当前正在编写的代码很多还在本地的工作区，我们先添加到缓存区

然后我们打开出现 bug 的文件，然后修复 bug

修复完成，我们来来看看自己之前的代码在哪

指定不需要Git管理的文件

比如说github项目里面有个.gitignore

上图表示*.dSYM文件夹内所有文件不受管控，但是*.dSYM文件受管控

下面是java项目。那些文件时可以通过编译或者生成的

使用下面这个命令

vim .gitingore

进入文件后，可以编写，

如何编写.gitingore文件

/ggzx/ 过滤ggzx整个文件夹
*.zip 过滤所有.zip文件
/ggzx/ggzx.md 过滤其中的该文件

锚点

全篇总结–精彩回顾

创建文件

1. 创建文件：touch 文件名
2. 编辑文件：vim 文件名
3. 加入至缓存区：git add 文件名
4. 加入版本库：git commit --m “新增了xxx文件”
5. #查看提交状态:git status

删除文件

1. 删除文件：git rm 文件名
2. 查看删除状态(你会发现删除文件后，需要提交)：git status
3. git commit --m “删除xxx文件”
4. #查看文件列表确认是否成功删除：ls -al

查看版本历史

1. git log
2. git log -n4 查看最近四条
3. git log --online
4. git log --oneline --graph
5. git log --oneline --graph -n4

分离头指针注意

1. 从一个分支切换至其他分支：git checkout 版本号
2. 开发…
3. 开发…
4. 若开发失败------>>> 保留代码进度------->>>git breanch 分支名 版本号
5. 若开发成功------>>> 必须要保存进度------>>>git breanch 分支名 版本号
6. 若不保留进度------->>> 直接切换即可

修改 commit message

1. 新文件直接使用------>>> git commit --amend ------>>> 进入修改界面，输入 i 修改，修改完成 ------ >>> esc + :wq
2. 老文件 ------>>> >git rebase -i <修改commit的父commit ------>>> 把 pick 修改为 r ------>>> 进入修改界面

** rebase 使用错误，删除了字符 **

1. 如果想放弃之前编辑错的文本 ------>>> git rebase --abort
2. 如果想继续编辑 ------>>> git rebase --continue 继续执行

遇到紧急 bug 需要立刻修复

1. 保存当前进度，但是不提交：git stash
2. 修复bug…
3. 提交修复的bug …
4. 恢复进度 ------>>> git stash apply

合并commit

1. 当你发现你的几个 commit 完成的都是同一个功能下的子功能,你可以把它们合并成一个 commmt
2. git rebase -i <合并commit的父commit>
3. 进入编辑 ------>>> 将想要合并到的分支的 pick 修改为 s
4. 退出，然后查看：git log
5. 第三步失败：重来 ------>>> git rebase --abort