git - 多个 JIRA 任务，多个分支，同一个文件
git - multiple JIRA tasks, multiple branches, same file
我有三个 jira 任务，实际上是一个分为三个的任务（用于创建用户配置文件的步骤 1、2、3）（不是子任务）。所以我被指示为每个 jira 任务创建分支。我的问题是第二个分支需要第一个分支的代码，第三个分支需要第一个和第二个分支的代码。
示例：
分支 1 - 已创建 controller.php
分支 2 - 修改 controller.php
分支 3 - 已修改 controller.php
（请注意，我不仅在分支 2 和分支 3 中添加了新行，而且还更改了一些现有行）
为了让它工作，我所做的是我总是从前一个分支出来，这样我就可以得到我的改变。所以分支 2 从分支 1 分支出来，分支 3 从分支 2 分支出来。
我应该只创建一个分支吗？或者我使用 git 执行此操作的最佳方式是什么？
优缺点：
- 为每组更改设置一个分支的好处是您可以将更改彼此分开。
- 每组更改都有一个分支的缺点是您必须将它们彼此分开。
让我解释一下 - 如果您需要将这些更改分开并模块化，以便您可以仅将每个 JIRA 任务所需的更改应用到将来的其他任务中，或者可能只需要删除与某个 JIRA 任务相关的更改给定 JIRA 任务，然后对每个分支进行分支非常好，因为您将拥有一组可视化分组的提交，并且使用可视化 git 工具可以很容易地看到发生了什么。您还可以更轻松地对一系列这些更改进行变基，而不是从单个分支中挑选随机提交来准确获得您需要的更改。
分离每个分支的缺点是您最终必须将 3 个分支合并在一起，并且根据您对相同代码行的更改程度以及相互依赖性，很可能你们都会发生冲突它们之间的问题必须在合并时解决（而不是在开发更改时解决），而且您最终很可能不得不对 3 个分支中的每一个进行一些相同的更改，而不仅仅是重用随着您完成 3 个任务的最新变化。
Git 使分支变得容易
但是，让我们清楚的是，Git 使得分支变得超级容易，而且这样做的开销非常小，而且大多数合并都非常轻松（即使存在冲突......）。拥有 3 个独立的分支还意味着您可以根据需要在所有 3 个分支上并行 运行 测试和 CI/CD，如果其他人只参与其中的一两个分支，团队将非常清楚3 个变更集在何处以及如何添加到您的工作中（比如由其他团队成员修复的缺陷等）。
推荐
综上所述，根据所提供的信息，我认为我们无法就哪种方法最适合您的特定情况给出答案。您必须根据上述以及您团队的产品和工作流程特有的类似因素自行做出决定。
我可以给出一个建议 - 对此保持敏捷。按照你的团队所说的去做，然后找一个不需要很多时间重新实现更改的小案例，然后尝试将 2 或 3 个任务放在一起，穿插到一个分支中。与我在没有涉及所有当地因素的情况下试图为您做出决定相比，这种经历会更好地向您展示利弊。额外的奖励——如果结果更好，你将有一个实际工作产品的演示，你可以向你的团队展示作为证明——或者一个演示，你可以展示并询问他们是否在下一次尝试它的意见feature/sprint/etc。或对该替代方法进行更大的演示等。
这是我的建议。我们想让事情变得更简单，但我们会尽力满足您的老板想让您做的事情。据我所知，he/she 只需要不同的分支来处理不同的任务，以便 he/she 可以跟踪您的工作。虽然可能，但我认为创建三个不同的分支不是最好的方法。您可以做的只是为您的任务创建子任务。您在主任务上创建 1 个分支 。然后在 git 上，确保你的 提交消息提到子任务 。在您的情况下，您将进行三个提交。假设在 Jira 中创建了 3 个子任务，您有子任务 001、子任务 002、子任务 003。所以在你的分支中你必须提交：
"subtask-001 created controller.php" - this is one commit
"subtask-002 modified controller.php to blah blah" - and another commit
"subtask-003 modified controller.php agan.." - another one
这些都将在您创建的一个分支中，然后您可以为它提出拉取请求。在 jira 中，这三个提交将出现在 EACH 个子任务中，只要子任务 ID 与您在提交消息中提到的相匹配。它要简单得多，但您仍然可以在 Jira 中跟踪修订。
我有三个 jira 任务，实际上是一个分为三个的任务（用于创建用户配置文件的步骤 1、2、3）（不是子任务）。所以我被指示为每个 jira 任务创建分支。我的问题是第二个分支需要第一个分支的代码，第三个分支需要第一个和第二个分支的代码。
示例：
分支 1 - 已创建 controller.php
分支 2 - 修改 controller.php
分支 3 - 已修改 controller.php
（请注意，我不仅在分支 2 和分支 3 中添加了新行，而且还更改了一些现有行）
为了让它工作，我所做的是我总是从前一个分支出来，这样我就可以得到我的改变。所以分支 2 从分支 1 分支出来，分支 3 从分支 2 分支出来。
我应该只创建一个分支吗？或者我使用 git 执行此操作的最佳方式是什么？
优缺点：
- 为每组更改设置一个分支的好处是您可以将更改彼此分开。
- 每组更改都有一个分支的缺点是您必须将它们彼此分开。
让我解释一下 - 如果您需要将这些更改分开并模块化，以便您可以仅将每个 JIRA 任务所需的更改应用到将来的其他任务中，或者可能只需要删除与某个 JIRA 任务相关的更改给定 JIRA 任务，然后对每个分支进行分支非常好，因为您将拥有一组可视化分组的提交，并且使用可视化 git 工具可以很容易地看到发生了什么。您还可以更轻松地对一系列这些更改进行变基，而不是从单个分支中挑选随机提交来准确获得您需要的更改。
分离每个分支的缺点是您最终必须将 3 个分支合并在一起，并且根据您对相同代码行的更改程度以及相互依赖性，很可能你们都会发生冲突它们之间的问题必须在合并时解决（而不是在开发更改时解决），而且您最终很可能不得不对 3 个分支中的每一个进行一些相同的更改，而不仅仅是重用随着您完成 3 个任务的最新变化。
Git 使分支变得容易
但是，让我们清楚的是，Git 使得分支变得超级容易，而且这样做的开销非常小，而且大多数合并都非常轻松（即使存在冲突......）。拥有 3 个独立的分支还意味着您可以根据需要在所有 3 个分支上并行 运行 测试和 CI/CD，如果其他人只参与其中的一两个分支，团队将非常清楚3 个变更集在何处以及如何添加到您的工作中（比如由其他团队成员修复的缺陷等）。
推荐
综上所述，根据所提供的信息，我认为我们无法就哪种方法最适合您的特定情况给出答案。您必须根据上述以及您团队的产品和工作流程特有的类似因素自行做出决定。
我可以给出一个建议 - 对此保持敏捷。按照你的团队所说的去做，然后找一个不需要很多时间重新实现更改的小案例，然后尝试将 2 或 3 个任务放在一起，穿插到一个分支中。与我在没有涉及所有当地因素的情况下试图为您做出决定相比，这种经历会更好地向您展示利弊。额外的奖励——如果结果更好，你将有一个实际工作产品的演示，你可以向你的团队展示作为证明——或者一个演示，你可以展示并询问他们是否在下一次尝试它的意见feature/sprint/etc。或对该替代方法进行更大的演示等。
这是我的建议。我们想让事情变得更简单，但我们会尽力满足您的老板想让您做的事情。据我所知，he/she 只需要不同的分支来处理不同的任务，以便 he/she 可以跟踪您的工作。虽然可能，但我认为创建三个不同的分支不是最好的方法。您可以做的只是为您的任务创建子任务。您在主任务上创建 1 个分支 。然后在 git 上，确保你的 提交消息提到子任务 。在您的情况下，您将进行三个提交。假设在 Jira 中创建了 3 个子任务，您有子任务 001、子任务 002、子任务 003。所以在你的分支中你必须提交：
"subtask-001 created controller.php" - this is one commit
"subtask-002 modified controller.php to blah blah" - and another commit
"subtask-003 modified controller.php agan.." - another one
这些都将在您创建的一个分支中，然后您可以为它提出拉取请求。在 jira 中，这三个提交将出现在 EACH 个子任务中，只要子任务 ID 与您在提交消息中提到的相匹配。它要简单得多，但您仍然可以在 Jira 中跟踪修订。