Git非官方使用总结

原文地址：https://blog.dpf114.top/posts/git-often-used/

1.什么版本控制系统

单独的讲版本控制我们或许不知道它是什么，但是举个我们生活中的小例子，我们很容易明白它是什么。

例如我们毕业修改无数遍的论文：

毕业论文最终版
毕业论文最最终版
毕业论文最最最终版
毕业论文最最最最终版
毕业论文最终不改版
毕业论文最终真不改版
毕业论文最终真真不改版
毕业论文最终打死不改版
毕业论文最终打死不改版 2

...

这里有很多版本，而版本控制系统就是对我们写的内容不同版本进行控制的系统。

常用的版本控制系统有SVN和Git。我们在实际开发中Git使用的比较多。

2.安装和配置

2.1.安装

Windows

对于windows只要下载安装包直接安装即可。

Linux

使用apt-get工具下载安装

apt-get update
sudo apt-get install git

Mac

使用brew工具下载安装

brew install git

2.2.安装后配置

不管是 Windows 安装还是 Linux 安装，安装好之后，我们都先通过如下两行命令做一个基本配置,目的是为了区分不同开发人员的身份，即每次提交都是由谁提交的。配置方式如下：

git config --global user.name 'username'
git config --global  user.email '[email protected]'

配置完成后配置信息存储在~/.gitconfig文件中

3.基本使用

在基本操作之前我们要了解一下Git使用的分区

• 工作区：工作区也就是我们平常写代码的地方
• 暂存区：通过git add提交后临时存放代码的地方
• 本地库：通过git commit提交后存放代码的地方，本地库保存着历史版本相关信息。
• 远程库：远程库也就是远程代码仓库，例如Gitee、GitHub、gitlab。

3.1.初始化仓库

初始化仓库有两种方式，一种是通过从远程仓库克隆，另外一种是直接从当前目录初始化，命令如下：

git init

执行完成后当前目录下会多出一个 .git 的隐藏文件夹，所有 git 需要的数据和资源都存放在该目录中。

3.2.查看仓库状态

通过git status命令可以查看仓库的状态。刚初始化的仓库查看状态如下：

修改工作区后查看状态如下图：

提交暂存区后查看状态如下图：

提交到本地仓库后查看状态如下图：

3.3.提交到暂存区

通过git add可以将工作区的内容提交到暂存区，有以下几种使用情况：

git add 具体文件
git add .
git add *

.和*都代表提交工作区的所有文件。

3.4.提交到本地库

通过git commit将暂存区内容提交到本地仓库，具体使用如下：

git commit -m '提交描述内容'

注意：描述内容不能为空。建议每次提交写清楚提交内容，可用于版本回退。

3.5.提交到远程仓库

如果是通过克隆的方式初始化仓库，提交到本地库后，可以直接通过git push直接提交到远程仓库，如果是通过git init初始化，需要远程远程创建好对应仓库后，让本地仓库跟远程仓库关联，让后再用 git push提交。

关联远程仓库

用git remote命令关联远程仓库，格式git remote add 别名 远程仓库url,举例如下

git remote add origin https://github.com/xiaoxiaoshou/testgit.git

这里的url你可能两种类型，分别为https://github.com/username/reponame.git和[email protected]:username/reponame.github.io.git,代表着git两种不同的连接方式。

其他关联远程仓库相关命令：

# 查看关联了哪些远程分支
git remote -v
# 删除关联分支
git remote remove 别名

提交到远程仓库

提交命令格式git push 别名 分支名，举例如下:

git push origin master

3.6.从远程拉取代码

常用有以下两种方式：

1.使用git clone

默认从远程master分支拉取：

git clone 远程url地址

指定分支拉取：

git clone -b 分支名称 远程url地址

使用git pull

使用格式git pull <远程主机名> <远程分支名>:<本地分支名>。

例如我们要将远程 origin 的 master 分支拉取过来，与本地的 master 分支合并

git pull origin master:master

我们也可以简化为

git pull origin master
git pull origin 
git pull 

git pull = git fetch+git merge,fetch的作用是从远程拉取代码，merge的作用是合并代码(后面分支管理有详细解析)

4.代码撤销与版本回退

4.1.查看提交记录

使用git log可以查看提交过的信息，每次提交（git commit）到本地仓库的详细信息，每条提交信息大致如下：

commit cdc2ac8c3b6d9f8bde05140aca484aa4482f8895
Author: xiaoxiaoshou <[email protected]>
Date:   Tue Dec 1 15:41:13 2020 +0800

    提交描述内容

commit后面的编号是每次提交的一个索引（我们可以叫它版本号），用于版本前进或后退

使用git log显示的内容过多，我们一般使用下面两个比较简洁的查看方式：

# 推荐使用
git reflog

git log --online

4.2.工作区代码撤销

可能有一天你正在写代码，写了很久发现写错了，想恢复到一开始的状态，一个笨办法就是把刚刚写的代码一行一行的删除，不过这种方式成本太高，可以通过 git checkout -- <file> 命令来撤销工作区的代码修改。如下图：

4.3. 添加到暂存区代码撤销

想要撤销提交到暂存区的代码分以下两步：

• 1.将暂存区代码撤销到工作区git reset HEAD

• 2.将工作区代码撤销（和工作区代码撤销一样）git checkout -- file

4.4.提交到本地仓库代码版本回退

基于索引版本回退（推荐使用）

1.查看提交历史

2.使用git reset --hard [局部索引值]回退（可前进和后退）

使用^符号

git reset --hard^

一个^回退一步

使用~符号

git reset --hard~n	

n代表后退步数

git reset 中三个参数比较

git reset --soft
git reset --mixed
git reset --hard

• –soft
  • 仅仅在本地库移动 HEAD 指针
• –mixed
  • 在本地仓库移动HEAD指针
  • 重置暂存区
• –hard
  • 在本地库移动 HEAD 指针
  • 重置暂存区
  • 重置工作区

4.5.提交到远程仓库版本回退

由于远程仓库与本地仓库内容一致，所以需要远程仓库版本回退只需要本地版本回退再提交到远程仓库即可。

5.分支管理

5.1. 什么是分支

我们在完成一个项目时，不可能是“单线程”开发的，很多时候任务是并行的。举个栗子：项目 2.0 版本上线了，现在要着手开发 3.0 版本，同时 2.0 版本可能还有一些 bug 需要修复，这些 bug 修复之后我们可能还会发 2.1，2.2，2.3 这些版本，我们不可能等所有 bug 都修复完了再去开发 3.0 版本，修复 2.0 的 bug 和开发 3.0 的新功能是两个并行的任务，这个时候我们 3.0 的功能开发直接在 master 分支上进行肯定不合适，我们要保证有一个稳定，可以随时发版本的分支存在（一般情况下这个角色由 master 分支来扮演），此时我们就可以灵活的使用 Git 中的分支管理功能：

1. 创建一个长期分支用来开发 3.0 功能，假设这个分支的名字就叫 v3，我们在 v3 上添加新功能，并不断测试，当 v3 稳定后，将 v3 合并到 master 分支上。
2. 创建一个特性分支用来修复 2.0 的 bug ，一旦 bug 修复成功，就将该分支合并到 master 上，一旦发现新 bug ，就立马再创建分支进行修复，修复成功之后再合并。

5.2.查看分支

我们可以使用命令git branch来查看当前仓库有哪些分支和我们当前所处的分支

前面带*的分支为我们当前所处分支。

5.3.创建并切换分支

第一种方法

• 先用git branch 分支名创建分支
• 然后再用git checkout 分支名切换分支

第二种方法

使用git checkout -b 分支名创建和切换分支一步到位。

5.4.整合分支

分支的整合有两种形式，一种是merge,另外一种是rebase

merge

使用命令git merge [有新内容的分支名]合并分支。

上图解释：主分支在m1时发现有bug，于是切出一个分支bugFix，经过一段时间，主分支开发到m3，bugFix分支(已提交为m2)bug已经解决，这时候需要将bugFix分支合到主分支即使用命令git merge bugFix。

rebase

rebase 又叫变基，使用命令git rebase [有新内容的分支]可以变基。

上图解析：上图是在主分支使用命令git rebase bugFix进行整合分支，整合过程是将bugFix的提交记录在主分支自底向上再提交一遍。

merge和rebase的区别

• merge是把当前分支和要合并的分支合并在一起，进行一次commit提交

• rebase是把要rebase分支的历史提交在当前分支按顺序重新提交，rebase之后HEAD的位置不变(也就是图中的*)

• rebase过程中可能产生冲突，解决冲突后继续提交

  • 解决冲突
  • 提交到缓冲区git add .
  • 继续完成合并git rebase --continue

  以下是冲突部分内容

  <<<<<<< HEAD
  需要合并分支的内容
  =======
  当前分支内容
  >>>>>>> 
  

6.标签管理

我们可以给某一个提交打上一个标签，以示重要。比较有代表性的打标签用它来发布对应的应用的版本比如v1.0、v2.0。Git支持两种标签：轻量标签（lightweight）与附注标签（annotated）。

我们可以用以下命令查看仓库中所有标签：

git tag

6.1.轻量标签

轻量标签很像一个不会改变的分支——它只是某个特定提交的引用。轻量标签本质上是将提交校验和存储到一个文件中——没有保存任何其他信息。

轻量标签打标签格式git tag 标签名称，举例如下：

git tag v0.0

轻量标签默认是对最新的commit进行。

我们也可以对指定commit进行打标签，格式git tag 标签名称 commi对应索引。举例如下

# 查看commit索引
git reflog
# 打标签
git tag v0.01 bcde256

我们也可以删除掉本地仓库上的标签，格式git tag -d 标签名称，举例：

git tag -d v0.01

6.2.附注标签

附注标签是存储在仓库中一个完整对象，它有自己的校验和信息，其中包含标签者的名字、电子邮件、日期时间，此外还有一个标签信息。可以使用GNU Privacy Guard （GPG) 签名并验证。

打附注标签格式 git tag -a 标签名称 -m '标签信息',举例如下：

git tag -a v1.0 -m 'my version 1.0'

6.3.将标签推送到远程仓库

默认情况下，git push 命令并不会传送标签到远程仓库。需要我们手动将标签推送到远程仓库，推送格式git push 远程分支别名 标签名，举例：

git push origin v1.0

---

参考资料：

https://git-scm.com/book/zh/v2

https://www.runoob.com/git/git-tutorial.html

https://segmentfault.com/a/1190000037465780

边学习边玩会游戏：https://learngitbranching.js.org/?locale=zh_CN