相关疑难解决方法(0)

假设我是回购的维护者,并且我想从贡献者那里获取更改,那么有一些可能的工作流程:

1. 我cherry-pick每个都从远程提交(按顺序).在这种情况下,git将提交记录为与远程分支无关.
2. 我merge是分支,拉入所有更改,并添加新的"冲突"提交(如果需要).
3. 我merge各自从远程分支单独提交(再次按顺序),允许为每个提交记录冲突,而不是将所有冲突组合为一个.
4. 为了完整性,你可以做一个rebase(与cherry-pick选项相同？),但我的理解是,这可能会导致贡献者的混淆.也许这消除了选项1.

在情况2和3中,git记录了提交的分支历史记录,与1不同.

使用任何一种方法cherry-pick或merge描述的方法之间有什么优点和缺点？我的理解是方法2是常态,但我觉得用单个"冲突"合并解决大型提交并不是最干净的解决方案.

想象一下，我们使用Gitflow，从中分离出一个发布分支develop，最终将合并到 和main中develop。只有release质量的改进。其中大多数需要部署到集成阶段，因此它们的版本有多个pom.xml（多模块），并且package.json在分支上更新和标记release。

上面develop有针对未来版本的常规（不稳定）功能开发，并且版本已相应设置。有时，来自 的改进release会合并回develop. 我们会遇到合并冲突，在下图中用 X 标记。

main     ----------------------o----
                              /
release        o---o-----o-o-o
              /     \     \   \
develop  ----o---o---x--o--x-o-x----
                           ^
               we are here |

例子：

• 上的release版本号是1.0.0-SNAPSHOT。
• 上的develop版本号是1.1.0-SNAPSHOT分支之后的。
• 新功能进入develop，版本号保持不变。
• 中的版本release偶尔会增加（并标记）为1.0.1、1.0.2等1.0.3。
• 现在，当我想将版本 1.0.x 合并到 1.1.0 而共同祖先是 1.0.0 时， 当然会发生冲突。
  • （我们完全理解那里发生的事情，不需要解释。）

$ git …