0、说明

本篇笔记仅作为防止遗忘某些指令的速查笔记,并不全面。
若遇难点或盲区,请移步官方文档

  • 文档阅读说明:
    • () -> 代表补充说明
    • (' '==' ') -> 代表单词及解释(作者英语太差,所以需要这个)
    • -> -> 代表解释
    • 标题后的 [] -> 代表作者认为文档不清晰需继续整理的地方或是啰嗦不简洁的地方

一、本地使用git时的常用操作

1、提交

1
* `git commit`              ->      提交

2、创建及切换分支

1
2
3
* `git branch`              ->      创建分支    ('branch' == '分支')
* `git checkout`            ->      切换分支    (加上 `-b` 后,作用: 创建并切换分支) 
* `git checkout -b`         ->      创建并切换分支

3、合并的两种方式[这里需要重新简写版本]

  • merge是三路合并，合并双方有一共有基线，合并时会先跳过基线上已处理过的冲突，然后判断双方相对于基线发生变化的部分。
    • 若判断合并双方对同一部分存在变更，则会先由规则判断变更是否一致，若不一致时才会产生冲突。
    • 若判断只有其中一方对某部分存在变更，则会直接由规则变更是否一致，若不一致时才会产生冲突。
1
2
* `git merge`               ->      合并分支    ('merge' == '合并')         ->  以当前分支为基准,合并[分支名]分支,并产生一个新的提交(有一定概率需要处理冲突)、(若此时在当前分支的其他 父类版号~~或分支名~~ 进行相同操作,则只会移动当前指针到刚才新产生的提交  ->  因为对两分支来说,冲突已经处理过了,不会产生无意义的重复提交)
* `git rebase`              ->      重订基底    ('rebase' == '重订基底')    ->  删除当前分支,并重新以 目标分支名 所指向的提交对象为基底合并分支,并产生一个新的提交(有较大几率处理冲突)、(若此时在切换的目标分支的基底处进行相同操作,则只会移动分支指针到刚才的提交  ->  因为对两分支来说，冲突已经处理过了，不会产生无意义的重复提交）

4、分离HEAD与相对引用

  • HEAD -> 也就是HEAD指针(唯一),代表用户当前所处位置,可以指向地址(某个分支地址 或 某个提交对象地址)
  • 分支 -> 也就是分支指针,可以指向地址(一般指向某个提交对象的地址)
  • 相对引用 -> 即相对HEAD的引用 -> HEAD^/HEAD~1/HEAD~2.../HEAD~n -> ^代表向前一个commit、~数字代表向前n个commit (分支指针+^/~也可以相对引用)
    1
    2
    * `git branch -f [分支名]  [移动位置->可用相对HEAD/唯一哈希码(提交对象的地址)] ` -> 移动分支指针(注意:对于和HEAD指向的分支,无法进行指针的移动,必须先分离HEAD)
    * `git checkout [移动位置->可用相对HEAD/唯一哈希码(提交对象的地址)/分支名] ` -> 分离HEAD,只移动HEAD的位置(也可以指向分支地址,从而结束HEAD分离的状态)

5、撤销变更 [这部分存在不清晰,后续还需重新整理]

1
2
* `git reflog` -> 可以查看被隐藏掉的提交对象的地址
* `git reset --hard [唯一哈希码(提交对象的地址)]` ->  `HEAD指针/HEAD指针'+分支指针`切换回历史隐藏的记录号
1
2
3

* `git reset` ->  本地经常使用,会使原来的提交记录就跟从来没有提交过一样,远程端不推荐使用,会造成无效的共享。(要哪个版本,就reset到哪个版本 -> 后续需要分清其与checkout的区别)(目前看来,reset好像隐藏掉记录对象 -> 不过还不确定)
* `git revert` -> 远程经常使用,会基于历史提交记录执行一遍相反的过程并生成一个新的提交,故保证了远程端某分支提交历史的清晰,并且可以使远程端共享不受影响。(要哪个版本,就revert到那个版本的下一个commit版本)(还不确定正确性)

6、自由修改提交树

  • HEAD -> 也就是HEAD指针(唯一),代表用户当前所处位置,可以指向地址(某个分支地址 或 某个提交对象地址)
1
2
3
4
5
6
7
8
* `git cherry-pick [要合并过来的记录 -> 可为多个 -> 可用相对HEAD/唯一哈希码]` -> 将一些提交复制到当前所在位置(HEAD)下面(HEAD上游的除外)cherry-pick是最直接的方式了(当知道提交记录哈希值时最好)。 -> 操作前(移动HEAD到左值处(不包含) -> 即需要移动至左值的父提交处,然后使用)
* `git rebase -i`  ->  交互式rebase -i
  单链 和 跨链
  (虽然跨链为通用理解,但大可不必像我一样全部掌握,涉及到跨链情况用 cherry-pick更方便)
   * 单链
     `git rebase -i [要合并过来的记录 -> 可用相对HEAD]/[左值(不包含)唯一哈希码]+[右值(包含)唯一哈希码]` -> 交互式rebase -> 如果想从连续的一系列提交记录中找到想要的记录,这无疑是最好的方式。(最好用相对HEAD->可以同时移动HEAD和分支)(若是使用左右值,只会移动HEAD,需手动切换分支指针) -> 操作前(移动HEAD到最右值处,然后使用)
   * 跨链
     `git rebase -i [重定向的父节点(取跨链相对'顶父'树层次作为左值] [指定添加过来的记录点(此记录点作为右值往上(左值层次)遍历)]`  ->   跨链且单链记录点少的情况,由于最多两个参数,使用 交互式rebase -i 必定过于繁琐(不推荐)
  • 总结,使用时,两者皆可实现自由修改提交树到任何形状,只是对于不同场景时是否方便而已。(结合使用,涉及跨链的 分支用cherry-pick,设计单链单分支用交互式rebase -i)

7、标签

1
2
3
4
5
6
7
8
9
10
* `git tag [标签名] [位置->可用相对HEAD/唯一哈希码]`  ->  在指定位置创建标签(如果不加位置参数,默认将标签创建在当前(HEAD)位置)
* `git describe <ref>`
  * 语法是
    <ref>可以是任何能被 Git 识别成提交记录的引用,如果你没有指定的话,Git 会以你目前所检出的位置 (HEAD) 。

    它输出的结果是这样的:
     * <tag>_<numCommits>_g<hash>
       tag表示的是离 ref 最近的标签(上游标签), numCommits 是表示这个 ref 与 tag 相差有多少个提交记录,hash表示的是你所给定的 ref 所表示的提交记录哈希值的前几位。

     * 当 ref 提交记录上有某个标签时, 则只输出标签名称

8、自行决定上行路线移动

  • 其实就是^这个符号后跟数字即可(跟上数字后,上移时会改变其默认的父路线)
  • ^与~可随意嵌套使用 如 ^^2~3^2~~3
  • 合理地使用以上这些技巧, 可以提高操作分支时的效率

9、存档裤相关

  • git stash
  • git stash save
  • git stash list