### 彪哥

爱好前端

- 手册

  - 常用Git命令清单
  - Git变基合并
    - 说明
      - 变基要遵守的准则
      - 变基的实质
    - 后悔药
    - 开发期间的rebase操作
      - 背景
      - 操作步骤
    - git cherry-pick
      - 基本应用
      - 转移多个提交
  - Git命令思维导图

- 文档笔记

- 《Git》学习笔记
- 手册

heBody
2020-11-18
目录

# Git变基合并

# # rebase分支合并

## # 说明

以下 `v2` 是某个需求的开发分支， `dev`是总的开发分支，`v2` 是基于`dev`分支签出的。

当完成`v2`的开发后，需要把代码合并到`dev`，我们可以使用`rebase`进行合并：

    # 首先将 v2 push到远程仓库
    git add .
    git commit -m 'xxx'
    git push origin v2

    # 切换到 dev 拉取最新代码
    git checkout dev
    git pull origin dev

    # 切换到 v2
    git checkout v2
    git rebase dev # 将 v2 的所有[commit] 变基到(应用到) dev

    # 切换到 dev
    git checkout dev
    git merge v2  # 将 dev分支 快进合并 （此时 (HEAD -> dev, v2) [commit] 两个分支指向同一个提交）

    # 查看 原v2的[commit]记录 是否在dev分支的最前面（变基成功会把v2的提交记录应用到dev分支的最前面）
    git log

    	# 如果到这一步发现有问题，尝试使用 git --abort中止变基，如果还是有问题的可以在dev分支上使用《后悔药》操作， 再到v2分支上使用《后悔药》操作，即可使两个分支都回退到 rebase变基 之前的状态

    # 试运行项目是否有问题
    yarn start

    git status # 查看状态是否有问题
    git push origin dev # 推送到远程仓库的 dev

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

### # 变基要遵守的准则

几个人同时在一个分支上进行开发和提交时，开发中途请不要私自执行变基，只有在大家都完成工作之后才可以执行变基。

### # 变基的实质

变基操作的实质是丢弃一些现有的提交，然后相应地新建一些内容一样但实际上不同的提交。 因此，变基操作过后的分支将不要再使用。

## # 后悔药

    # 查看HEAD指针变动记录
    git reflog
    # 记录示例(当前分支是v2):
    07c398f (HEAD -> v2, master) HEAD@{0}: checkout: moving from master to v2
    07c398f (HEAD -> v2, master) HEAD@{1}: rebase (finish): returning to refs/heads/master
    07c398f (HEAD -> v2, master) HEAD@{2}: rebase (start): checkout v2
    15a97d8 HEAD@{3}: reset: moving to 15a97d8
    07c398f (HEAD -> v2, master) HEAD@{4}: merge v2: Fast-forward
    15a97d8 HEAD@{5}: checkout: moving from v2 to master
    07c398f (HEAD -> v2, master) HEAD@{6}: rebase (finish): returning to refs/heads/v2
    07c398f (HEAD -> v2, master) HEAD@{7}: rebase (pick): C
    15a97d8 HEAD@{8}: rebase (start): checkout master # 首次rebase
    d278ecd HEAD@{9}: checkout: moving from master to v2 # rebase前的状态
    15a97d8 HEAD@{10}: commit: D

    # 可见，示例中最初的 rebase 操作是 HEAD@{8}，想回退到变基前的状态需让指针指向 HEAD@{9}
    git reset --hard d278ecd  # 重置当前分支的HEAD为指定[commit]，同时重置暂存区和工作区，与指定[commit]一致

    # 此时打印 log 查看是否回到之前的状态
    git log

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

注意：此操作只能回退当前的分支，如其他分支也要回退，需要切换到该分支并执行上面操作。

## # 开发期间的rebase操作

### # 背景

有两个分支：

    dev
    *v2

1
2

`v2` 是基于`dev`切出来的。

提交记录如下：

    		dev
    a - b - c
    		v2

1
2
3

开发期间，两个分支同时有新的commit ：

    				dev
    a - b - c - d - e
    		\ - f - g
    				v2

1
2
3
4

当前你正在`v2`进行开发，`dev`也同时进行开发，并有重大的改变，你需要把`dev`的提交同步到`v2`。

需求： 把`dev`中新的提交同步到`v2`，且不能影响`dev`分支。

### # 操作步骤

1. 基于最新的 `dev` 切一个新的分支 `dev-copy`

   > `dev-copy` 和 `dev` 两者的 commit ID 一致。

2. 在`dev-copy`中执行rebase，将 `dev-copy` 的提交变基到 `v2`

       git rebase v2 # 将 dev-copy 的提交[commit] 变基到(应用到) v2

   1

3. 删除原`v2`分支，将`dev-copy`分支名改为`v2`

       # 当前在 dev-copy 分支
       git branch -d v2 # 删除分支
       git branch -m dev-copy v2 # 重命名

   1
   2
   3

## # git cherry-pick

来源：《git cherry-pick 教程》
(opens new window)

用于将单个或几个`[commit]`复制到另一个分支。

### # 基本应用

    git cherry-pick <commitHash> # 将commitHash应用于当前分支

1

上面命令就会将指定的提交`commitHash`，应用于当前分支。这会在当前分支产生一个新的提交，当然它们的哈希值会不一样。

git cherry-pick命令的参数，不一定是提交的哈希值，分支名也是可以的，表示转移该分支的最新提交。

### # 转移多个提交

Cherry pick 支持一次转移多个提交。

    git cherry-pick <HashA> <HashB> # A和B提交

1

上面的命令将 A 和 B 两个提交应用到当前分支。这会在当前分支生成两个对应的新提交。

如果想要转移一系列的连续提交，可以使用下面的简便语法。

    git cherry-pick A..B # A到B提交，不包含A

1

上面的命令可以转移从 A 到 B 的所有提交。它们必须按照正确的顺序放置：提交 A 必须早于提交 B，否则命令将失败，但不会报错。

注意，使用上面的命令，提交 A 将不会包含在 Cherry pick 中。如果要包含提交 A，可以使用下面的语法。

    git cherry-pick A^..B # A到B提交，包含A

1
编辑
(opens new window)
#Git
上次更新: 2022/12/14, 19:36:42
常用Git命令清单
Git命令思维导图

← 常用Git命令清单 Git命令思维导图→

最近更新

  01
Git修改分支名
08-11

  02
CSS给table的tbody添加滚动条
06-29

  03
我做了一个手写春联小网页，祝大家虎年暴富 原创
01-28

更多文章>

Copyright © 2016-2022 Hesb | MIT License

- 跟随系统
- 浅色模式
- 深色模式
- 阅读模式