Git 在处理新JIRA时，是从原始分支机构新分支机构还是未合并分支机构？

我想知道这种做法。假设有一条上游，我从那里分叉

对于我将要处理的每个JIRA票据，我将从我的来源创建一个新的本地分支。当我完成JIRA时，一切都很顺利，我将分支推到我的原点，创建一个到上游的拉请求，在它合并后，我从上游拉，然后从那里开始

我不确定，JIRA分支在被推后是否还没有合并到上游，我已经准备好开发一个新的JIRA。那么，您是否基于以下内容为新JIRA创建新的本地分支

• 以前未合并的JIRA本地分支机构（即未合并的变更）

或

• 前一个未合并JIRA的父级（即没有您在未合并JIRA中所做的更改）

或

• 如果这两个JIRAs中的文件没有依赖关系，那么这并不重要

---

我使用以下方法：

• 始终基于上游分支创建新功能分支（用于JIRA票证），忽略您（和任何其他人）未合并的更改。这样，你总是在一个干净的状态下工作
• 在创建拉取请求之前，请从上游更新本地回购协议，并根据传入的更改重新确定功能分支的基础

根据我的观点/经验，这是最干净的方法，因为无论如何，您都必须根据任何传入的更改重新确定传出更改的基础。它还确保每个拉取请求只包含当前正在处理的票证的更改，而不包含任何其他未合并的票证

如果您在第一张未合并的JIRA票证的基础上开始处理第二张JIRA票证，您将遇到以下问题：

• 您的第二个PR将不仅包含来自第二张票证的修复，还包含来自第一个未合并PR的更改，从长远来看，这可能不会产生影响，但会用不相关的更改污染第二个PR
• 因为你可能不是唯一一个处理代码的人，所以在创建PR之前，你必须先执行

  拉入/重设基础

  步骤，因为在此期间，其他人的更改可能已经合并到上游回购中

您可能想看一看，它提出了一个类似的分支模型，每个特征有一个专用的、独立的特征分支

---

另一个使用拉请求的流行分支模型是模型。

感谢这个干净的想法。你能评论一下从未合并的变更分支出来的效果吗？谢谢，这很好。被选为答案。尽管我还有一个问题：如果我不等待合并，而是简单地为我完成的JIRAs创建合并请求（如您所建议的，所有分支都来自干净状态），当代码审阅者执行所有这些合并时会发生什么？有人将不得不用当前状态更新“过时”的pull请求，例如通过重基。可以是您（这是分支模型中的常见方式），也可以是进行合并的人。