我们有几个分支，我想确保我不会做任何愚蠢的事情。
分支1具有：提交A+提交B
分支2有：提交A+提交C(这是从提交A继续的工作(+提交D
分支3是的新分支
分支4(主(
我需要将提交A和提交C的一部分合并到主分支中，因为与提交D相关的工作出现了延迟，所以现在我的客户希望提交C的功能与提交D分开发布。
我曾想过在提交a和提交C时创建一个到分支3的pull请求。然而，我无法做到这一点，因为提交C包括一个remaster、一些合并冲突修复和相关的附加代码。
Questinos:
- 如果我只是复制并粘贴相关代码，并在分支3中进行PR，那么当分支1、分支2和分支3最终都合并到主分支时，我会有问题吗
- 如果我不仔细挑选提交，git是否足够聪明，可以选择复制和粘贴，或者当所有分支最终合并时，主分支上是否会出现代码重复问题
我必须使用分支3来引发合并以释放拉取请求，并且不允许接触分支1。有一个单独的团队在做这件事。
以下是我的建议：
- 在
master上创建一个新分支：feature_commit_c(看起来像是branch 3( - 将commit C(不需要分支，使用散列(合并到
feature_commit_c中，在该分支中进行第一次提交 - 进行与"；仅提交C"的一部分；。测试、准备、进行任何其他更新和新的提交
- 创建从新分支到
master的PR - 根据团队要求完成PR审查
- 合并到
master
这应该是最干净的。我总是从新分支将合并回的位置开始新分支，如果我需要其他分支的现有更改，则从其他分支进行侧合并。这样可以避免一些问题，并更清晰地显示您的意图，但这部分取决于您。
注意您的其他问题
Git只看文本，不知道它是从哪里来的。如果是相同的，那么diff将不会显示任何差异。因此，如何从C中进行部分更改(无论是通过复制/粘贴将它们粘贴到A上，还是从提交C中选择性重置文件(取决于您。
在合并A并完成部分C更改后，A-C-d分支和新分支之间的差异应该只是C的其余部分和d的所有部分。
你总是可以在主人身上发生冲突，这只是交易的一部分。但这种情况应该只发生在两个分支中更改的二进制文件或更改的文件/行组合中，忽略了常见的内容(从基本提交+完全挑选的任何内容(。
我需要合并提交A和提交C 的一部分
Commits是git的基本单位。你不能用"；部分"；提交，包括合并。您需要编辑历史记录，将Commit C分解为更小的部分，这样您就可以选择其他分支中的内容。使用git rebase -i拆分，然后基本上撤消Commit C，并使用所需的较小部分创建新的Commit C1、C2等。
将来，我建议您为每个功能创建一个新的分支。您可以在处理该功能时在此分支上创建较小的提交。我建议在工作时做出小的、有凝聚力的承诺。然后，当该特征完成时，将其合并到master或某个其他"特征"中；主干"；树枝不要只将整个大型功能提交为一次提交。
如果我只是复制并粘贴相关代码，并在分支3中进行PR，那么当分支1、分支2和分支3最终都合并到主分支时，我会有问题吗？
如果将代码复制/粘贴到文件中完全相同的位置，那么将来的合并很可能会发生冲突。只要两个分支上的这些行没有其他更改，这些问题就应该很容易解决。