我在master 中开发了一个未完成的功能，因此我无法部署到生产环境。
所以我所做的就是从该master 分支创建一个develop 分支，然后在master 上恢复上次提交。
现在我的问题是，当我在 develop 分支上完成新功能时，我应该如何进行合并？
我问这个是因为在我的情况下，我将继续直接在 master 上开发新的小功能，在将 develop 合并到 master 之前，我必须合并到 develop。
但是如果我将master 合并到develop 中，我不会也合并revert..？
【问题讨论】：
我建议阅读本指南https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
听起来你会从理解和坚持特定的 git 流程中受益更多，而不是我解释如何解决你遇到的这个问题。
我还建议在这里阅读有关变基的信息：https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase
变基是一种技术，可让您在将提交推送到上游分支之前移动提交。它可以帮助分配在您描述的那种情况下，您开始在分支 A 中处理某个功能，但希望在分支 B 上使用它，那里还有其他与第一个分支不匹配的更改。
【讨论】：
嗯，对所提出的问题有一个技术性的答案，并且有关于如何做你想做的事情的实用建议。
技术上的答案是，您遇到了这样的情况：
A -- B -- ~B -- C -- D <--(master)
\
E -- F -- G <--(develop)
其中~B 是由revert 的B 创建的。
如您所述，如果您将master 合并到develop，那么~B 将被带入develop，从而撤消对B 的更改。此外，如果将develop 合并到master，B 中的更改仍然不会出现在master 中，因为B 已经可以从master 访问。 （事实上，在这个例子中它是合并基础。）
情况与还原合并时发生的情况非常相似，并且恢复选项相同：
选项 1：您可以“还原还原”——我会在将 develop 合并到 master 之前通过 reverting ~B 在 master 上执行此操作，或者在合并后在 develop 上执行此操作master 转换为 develop，以先到者为准。 （还有其他变体，但这是我通常推荐的变体。）
选项 2：您可以执行“强制变基”来创建一个新提交，以“重做”B 所做的事情，但 master 的历史记录中还没有。
git rebase -f <A> develop
（您将<A> 替换为您还原的提交之前的提交的ID 或解析为的某个表达式；例如
git rebase -f develop~4 develop
在给定的示例中。如果它不是一个容易计算的提交数量，您可能可以使用git merge-base master develop 来帮助定位提交；但请记住，在此示例中，您需要合并基础的父级，而不是合并基础本身。）
无论如何，这会产生
A -- B -- ~B -- C -- D <--(master)
\
B' -- E' -- F' -- G' <--(develop)
这将允许master 和develop 以预期的方式合并。但是，请注意这会重写 develop 的历史记录，因此如果您已将 develiop 推送到其他开发人员可能正在共享它的远程位置，那么这可能是不可取的（并且至少需要协调；请参阅git rebase 文档）。
这就是你现在可能应该做的事情，因为你已经做了你已经做过的事情。但更实用的建议是：您的需求显然需要更复杂的工作流程。在master 上开发小功能可能“感觉”更简单，但它并没有为您节省任何技术上的重大损失，而且还会导致您遇到类似的问题。
有许多工作流程，有些更简单，有些更复杂。找到最简单地满足您的需求是您需要解决的问题。 GitFlow 非常好，但可能超出您的实际需要。仅使用独立的功能分支是介于两者之间的另一种选择。
【讨论】：