Git(一) ：git使用常用命令

傷城~ 2023-07-18 14:19 31阅读 0赞

### 基础命令 ###

*  `git clone git@github.com:nohosts/nohost.git` 克隆远程仓库的内容到本地
 *  `git pull origin master` 获取远程分支master并merge到当前分支
 *  `git branch -a` 查看 全部分支（远程+本地）
 *  `git checkout -b bugFix`新建名称为bugFix的分支，并切换到到此分支。（如果分支已存在则去掉-b即可）
 *  `git status` 查看当前~~~~版本状态（是否修改）
 *  `git add .` 增加当前子目录~~~~下所有文件更改至暂存区
 *  `git commit -m 'xxx'` 提交暂存区的修改至本地的版本库, 修改备注为xxx
 *  `git push` 将本地版本推送到远程分支
 *  `git merge testBranch` 合并testBranch分支至当前分支
 *  `git tag v1.0 dfb02e6e4f2f7b573337763e5c0013802e392818` 增加v1.0的tag到某个提交上
 *  `git stash` 暂存本地的当前修改，将本地代码重置为HEAD状态。（如果需要取出修改，命令后加一个pop即可）
 *  `git log` 显示提交日志（如果想每个提交信息显示在一行，可以加上--pretty=oneline）
 *  `git show dfb02e6e4f2f7b573337763e5c0013802e392818`显示某个提交的详细内容
 *  `git reset --hard HEAD` 将当前版本重置为HEAD

注意这两个命令的区别：

git pull = fetch + merge
    
    git pull --rebase = fetch + rebase

### “不常用”命令 ###

**一、HEAD^n 和 HEAD~n 相对引用**

`HEAD` 是一个对当前检出记录的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。`HEAD` 总是指向当前分支上最近一次提交记录 (如果想看 HEAD 指向，可以通过 `cat .git/HEAD` 查看， 如果 HEAD 指向的是一个引用，还可以用 `git symbolic-ref HEAD` 查看它的指向。)

**  1、基础使用**

*  使用 `^` 表示向上移动 1 个提交记录。n表示第n个父提交，不填默认是1(正上方)
 *  使用 `~<num>` 向上移动多个提交记录 如 ~3

**注意：操作符还支持链式操，如HEAD^2~3^**

** 2、延伸用法**：

**移动分支**可以直接使用 -f 选项让分支指向另一个提交。例如下面的命令会将 master 分支强制指向 HEAD 的第 3 级父提交。

git branch -f master HEAD~3

**二、git reset VS revert 回滚**

`git revert HEAD`是用一次新的commit来回滚之前的commit，`git reset` 是直接向上移动分支，删除一些commit看上去像从未提交一样。这两者看似达到的效果是一样的，其实完全不同

git reset HEAD~1
    git revert HEAD

如下所见，图1是初始状态（需要撤回 `C2` 提交）,图2和3 是从图1分别执行 `reset` 和 `revert` 后的结果

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0NjA3ODM3_size_16_color_FFFFFF_t_70][]

1.  **`reset`**执行后，master 分支移回到了 `C1`；现在我们的本地代码库根本就不知道有 `C2` 这个提交了。
2.  **`revert`**执行后，在我们要撤销的提交记录 `C2` 后面多了一个新提交`C2'`，而`C2'`引入了**更改**—— 这些更改是用来撤销`C2`这个提交的。也就是说`C2'`的状态与`C1`是相同的。

**总结一下：（此处解释若有问题，请下方评论区留言）**

*  reset执行之后，没有了c2的提交记录，但是如果你是在c1的基础上做的修改，然后再提交，那么就没有问题。
 *  revert执行之后，还存在c2的提交记录，同时也增加了一个c2'的修改记录，表示你有个回退版本的操作，这样可以保留原来的c2操作，便于以后查看所有的修改记录，包括回退操作。

# 事例
    reset后的123 merge了12345 还是12345
    revert后的12345(-3) merge了12345 是12345(-3)

**三、git cherry-pick 选择**

`cherry-pick` 可以将提交树上任何地方的提交记录取过来追加到 `HEAD` 上（只要不是 HEAD 上游的提交就没问题）

git checkout master; git cherry-pick C2

下图中左、右两张图分别是执行代码前后的样子：

![format_png][]

**四、git rebase 变基**

在 Git 中整合来自不同分支的修改主要有两种方法：`merge` 以及 `rebase。`

说明：**举例每个 `分支` 都有不同的颜色，`*前缀` 表示现在所处的分支，而 `commitid` 都由C0、C1、C2代替每一个提交的哈希值，`箭头` 表示分支的继承。**

**1.merage**

**`merge` 合并两个分支时会产生一个特殊的提交记录，它有两个父节点。简单说就是：“我要把这两个父节点本身及它们所有的祖先都包含进来。”**

git checkout master; git merge bugFix

下图中左、右两张图分别是执行如下代码前后的样子:

![format_png 1][]

可以看出来，红色圈圈是最主要的改变—— `merge` 合并分支后，会在master分支上 `新增一个C4提交` ，而C4提交里面有master和bugFix代码库所有的修改。

此时的bugFix代码还没和master `同步`（颜色不同），也就是master上有bugFix代码，bugFix上没有master代码，我们还需要执行如下代码：

git checkout bugFix; git merge master

![format_png 2][]

**2. rebase**

**`rebase` 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下去。它的优势就是可以创造更线性的提交历史。**

git checkout bugFix; git rebase master

下图中左、右两张图分别是执行代码前后的样子：

![format_png 3][]

bugFix 分支里的内容通过 `rebase` 直接 `复制` 到 master 分支上。现在 bugFix 分支上的工作在 master 的最顶端，同时我们也得到了一个更 `线性`的提交序列。

**注意：提交记录 C3 依然存在（树上那个半透明的节点），而 C3' 是我们 `rebase` 到 master 分支上的 C3 的 `副本`（内容是一样的，只是commitid更新了）**

但是，此时master还没有和bugFix `同步`（颜色不同），我们还需要执行如下代码

git checkout master; git rebase bugFix

![format_png 4][]

由于bugFix继承自master，所以 Git 只是简单的把master分支的引用向前移动了一下而已。

**3. rebase的延伸用法**

3.1 省去切换分支即可rebase

git rebase targetBranch originBranch

表示切换到originBranch，然后执行git rebase targetBranch

3.2. rebase需要谨慎使用

当你要改写的commit history**还没有被提交到远仓库的时候，也就是说，还没有与他人共享之前**，commit history是你私人所有的，那么想怎么改写都可以。

而一旦被提交到远程后，这时如果再改写history，那么势必和他人的history长的就不一样了。`git push` 的时候，git会比较commit history，如果不一致，commit动作会被拒绝，唯一的办法就是带上 `-f` 参数，强制要求commit，这时git会以committer的history覆写远程分支，从而完成代码的提交。虽然代码提交上去了，但是这样**可能会造成别人工作成果的丢失**，所以使用 `-f` 参数要慎重。

所以，在不用 `-f` 的前提下，想维持树的整洁，方法就是：在 `git push`之前，先 `git fetch`，再 `git rebase`。

3.3.总结

无论是通过变基，还是通过三方合并，整合的最终结果所指向的快照始终是一样的，只不过**提交历史不同**罢了。**变基是将一系列提交按照原有次序依次应用到另一分支上，而合并是把最终结果合在一起**。

**在你自己的分支（非他人共享）的分支进行rebase是可以的，但是如果在公共分支rebase修改提交需要谨慎——最好是先 `fetch`、再 `rebase`、最后 `push`。**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0NjA3ODM3_size_16_color_FFFFFF_t_70]: /images/20230528/5af7169ca3f54c62a16e9b6a36a321b9.png
[format_png]: /images/20230528/9b75313c55b6497eb35e435cfa75cc50.png
[format_png 1]: /images/20230528/188597bd9a904c32936a8e6fc5677f7d.png
[format_png 2]: /images/20230528/8342d418b4e948b1893698b225d92297.png
[format_png 3]: /images/20230528/477c3c06e16c4e7c84df4e6016926f52.png
[format_png 4]: /images/20230528/0bb179b48cb543d7951b175d2a0e8936.png