我应该如何分出两个工作项目，一个是增强大师，另一个是增强第一个？

Question

澄清一下：

大师已经包含了一些东西
工作项目 #1（从现在开始：“#1”）增强大师（修复一些东西，添加方法...）
工作项目#2（...“#2”）使用了#1 介绍的一些方法并添加了更多东西

我一夜之间完成了这两件事:D

我想知道如何以审阅者可以增量合并的方式进行分支？我不想在一个 pull-request 中同时加入这两个工作项目，那将是一个巨大的审查！

从我“本地工作”的角度来看，为#1 从 Master 分支一次然后从#1 分支出来为#2 添加内容是有意义的......但是，审阅者将有以相反的顺序折叠它，对吗？他们必须将#2 合并到#1，然后将#1 合并到 Master...但是从伦理的角度来看，他们不能将#2 合并到#1，因为他们还不知道#1 做了什么!

我真的不知道 git 在实际场景中是如何工作的。我理解命令但人们如何使用它们（更具体地说，他们希望我如何使用它们）- 这对我来说是棘手的一点！

我有一个想法：我仍然这样做，然后他们只需要按时间顺序阅读并批准两者，首先...然后按“折叠”顺序合并（#2->#1 ->大师)?

或者：他们可以将 #1 合并到 master 中，并且由于 #2 是“相对于”#1 的，它将“跟随”#1，一旦合并 #1，#2 将立即可合并成为大师？

在这一点上我可能会补充说审稿人比我git知道的还要少......我没有人可以问，真的......

Answer 1

Git会做正确的事。

a-b-c-d-e-f-g-h-i
 \        ^     ^
  m       |     |
  ^       |     |
  master  #1    #2

如果您将 #1 合并到 master 中（或创建一个 pull-request/merge-request 供您的审阅者审阅），则只有来自提交 b、c、[=14= 的更改]、e 和 f 将需要审核。一旦#1合并到master，#2到master的pull-request/merge-request将只包含g、h的变化, i 进行审核。

不存在更改的“双重合并”问题，因为 Git 已经知道 b 到 f 已经合并到 master 分支中，只有 g 到 i 是新的。

在视觉上，先执行 #1 到 master 的合并，然后执行 #2 到 master 的合并，将导致：

a-b-c-d-e-f-g-h-i
 \        ^\    ^\
  m---------n-----o
  ^       |     | ^
          #1    #2|
                  master

n是合并#1到master的合并结果（git checkout master && git merge '#1'），o是合并[=19=的合并结果] 到更新的 master 已经包含 #1 (git checkout master && git merge '#2')

我应该如何分出两个工作项目，一个是增强大师，另一个是增强第一个？

How should I branch out two work items, one is enhancing master, the other is enhancing the first one?

git

branch

branching-and-merging

pull-request