Git 基础用法
type
Post
status
Published
date
Dec 31, 2021
slug
gitBase
summary
来源：原创
tags
Git
category
码农
icon
password
GIt 基础详解
Git 本地仓库存在三个区，分别为工作区、暂存区和版本库。
工作区为我们进行代码工作的区域，任何代码的改动都会体现在该区域；
版本区为我们已经完成的代码工作，以
Commit 节点的形式存在；暂存区则在工作区和版本区之前，暂存一下我们的工作代码。
Commit 节点
上图就是一个
Commit 节点。简单的理解，它是一个以一串 hash 值为 key，文件改动、日期、提交者等内容为 value 的 objects。
每个
Commit 节点存有上一个节点的相关信息，这里可以想象成反向单向列表。所有的节点存在于
.git/objects 目录中。笼统理解，Commit 节点是 git 系列操作的元数据， 后面介绍的
git branch、git reset、git checkout 等都是基于 Commit 节点进行的。git clone
为了项目成员协同开发，就引出了远程仓库，各开发者可以通过
git clone 获取远程仓库。clone 的执行过程就是把一个一个的 Commit 节点从远程下载到本地，站在用户视角，就像是看到其他开发者在一步一步的帮你把项目写出来。
知识提升：Git 作为分布式管理系统，所以本地仓库也是可以互相 clone 的。git clone gitA gitB，即 gitB 仓库 clone 自 gitA。
git pull
之后当有其他开发者将代码推送到远程，我们只需 git pull 即可将他人的成果拉取到本地。
pull 的过程就是将与本地不同步的 Commit 节点一个一个同步到本地。
知识提升：git pull = git fetch + git merge，即拉取远程代码并合并到本地代码
git push
git push 将本地仓库推送到远程仓库，同理也是一个一个的推送到远程。git add
git add 将工作区中的改动添加到暂存区中。git commit
git commit 将暂存区中的改动添加到版本区。Commit 之后就会生成一个节点信息，通过
git log 可以查看串线记录。git branch
前面几个操作都比较简单易懂，从现在开始我们拿出真家伙，开始一波操作。
先说结论，分支是指向某个 Commit 节点的 refs（个人偏向翻译成指针）。
前面说过，Commit 节点只会记录前一个节点，这就导致从一个父节点 A 出来的 B、C 兄弟节点是相互不可见的，即 B 不知道 C 在哪里，C 也不知道 B 在哪里。
这个时候若 master 指针指向 B，dev 指针指向 C，通过 git log 查看串线记录就分别为 BA 和 CA。习惯上，我们把 BA 成为 master 分支，CA 称为 dev 分支。
git tag
- *tag 也是指向某个 Commit 节点的 ref，**不同于 branch 的是，tag 指针不随 Commit 的增加而自动指向到最新的 Commit 节点。
由于 tag 指针不移动的特性，tag 经常作为一个发布版本的记录。
git checkout
git checkout 有两种常用的方式：
git checkout {file}，表示用暂存区的 file 覆盖工作区的 file。
git checkout {branch 或者 commit hash}，表示将 HEAD 指针指向的 branch 或者 Commit 节点。
着重讲一下第二种用法，要讲该用法，必须得先讲
HEAD 指针。一般情况下，HEAD 指针指向某个 branch 指针，并且使工作区变成最终指向的 Commit 节点的内容。
我们可以通过 git checkout dev 切换分支（即 HEAD 指针指向 dev 指针），也可以通过 git checkout a4b1e5 直接将HEAD 指向到 a4b1e5 节点。
git reset
git reset 也有两种常用的方式：
git reset {file}，表示用版本区的 file 覆盖暂存区的 file。
git reset {origin/branch 或者 commit hash}，表示将当前 HEAD 指针和其指向的 branch 指针一起移动到 origin/branch 指向的节点或者 hash 指向的节点。
知识提升：git reset origin/dev —hard默认情况下使用 reset 命令切换 branch 指针指向后，隐藏节点的内容会同步到工作区。若使用 --hard 参数，则这些改动被直接抛弃，不会显示在工作区。
git merge
上面 branch 中，我们创建了 BA 和 CA 两个分支，最终任务完成了，B、C 节点的改动信息我们都需要，但是分支互相不认识，于是我们通过 git merge 将两个分支合并，最终会变成 DBA 和 DCA 两个分支。
D 节点就是 merge 节点，记录 merge 发生的信息。
merge 后当 HEAD 在 D 节点和后续节点，我们都能看到 B、C 节点的代码改动信息。
知识提升：git merge --no-ff若存在父节点 AA，dev 指针指向 AA。此时创建一个分支 feature，并改动代码提交 BB。这个时候使用 git merge feature，git 会发现 dev 分支在分叉后没有任何改动，就会直接把 dev 指针指向到 BB，而不会产生 merge 节点。这样一般情况下是没问题的，但是 review 平台有个坑，这种情况下会提示没有代码修改，无法推送。这个时候使用 git merge --no-ff 强制产生一个 merge 节点后再进行推送即可。