在codeaurora Kernel中，我看到了很多合并提交：
8beeb1e Merge "qseecom: check buffer size when loading firmware images"
10f00f5 Merge "msm: mdss: Clear compat structures before copying to user"
7e9e0b6 msm: cpp: Fix for buffer overflow in cpp.
ef19b0a Merge "net: rmnet_data: Disable generic receive offload by default"
fb864c7 Merge "Input: synaptics: check input, prevent sysfs races"
9232334 Merge "msm: camera: sensor: Validate eeprom_name string length"
3c6a873 Merge "qcrypto: protect potential integer overflow."
04c3de7 Merge "msm: camera: fix bound check of offset to avoid overread overwrite"
7752a0f Merge "msm: camera: eeprom: Validate the power setting size"
682a189 net: rmnet_data: Disable generic receive offload by default
9825755 qcrypto: protect potential integer overflow.
3fc578c msm: camera: fix bound check of offset to avoid overread overwrite
e9e48ad msm: camera: sensor: Validate eeprom_name string length
789bab0 msm: camera: eeprom: Validate the power setting size
f57ac38 qseecom: check buffer size when loading firmware images
我不知道为什么"git log"中有这么多合并提交？
似乎codeaurora正在使用"git merge"到cherry-pick一次提交？ codeaurora用于将一个提交合并到生产分支的命令和参数是什么？
答案 0 :(得分：2)
据我所知，您看到的这些合并是实际的合并提交。如果您选择提交，那么它将在当前HEAD添加整个提交，包括其消息。
阅读这个日志，在我看来，这些小功能/错误修正已经在不同的分支中创建，然后被合并/重新定位到生产分支上，创建了日志条目。
答案 1 :(得分：1)
Cherry-picking和merging是两种不同用途的Git操作。
通常的工作流程和项目是为新功能和错误修复创建单独的分支。开发人员在这些分支上工作，当功能完成（在功能分支上）或修复错误（在错误修复分支上）时，分支将合并到主分支中。
Cherry-picking是一种技术，用于在无法进行合并或rebase时将提交从分支复制到另一个分支。例如，当功能分支上的提交修复错误或实现在另一个功能分支上需要/有用的功能时，可以使用它。
答案 2 :(得分：0)
AOSP存储库由Gerrit管理。这是基本的工作流程。
git clone或repo sync。refs/for/<target_branch>。refs/changes/xx/yyyxx/1格式。想象一下，为Gerrit上的每次提交创建一个新的分支（ref）。 yyyxxx是每次更改的唯一ID。 1是补丁集的序列号。如果创建了新的补丁集，它可以是大于1的任何数字。refs/changes/xx/yyyxx/<last>被提交或合并到目标分支中。如果不是，则提交者需要修改提交并再次推送（或在Gerrit上编辑），以便创建新的补丁集（有时是新的更改）以进行审核。许多用户可能正在进行相同的基本提交，然后推送他们自己的提交。在不同用户的本地存储库中创建许多本地分支。这些本地分支（或更具体地说，这些本地分支的新提交）在被推送到Gerrit后变为refs/changes/xx/yyyxx/1。当合并引用refs/changes/xx/yyyxx/1时，这些提交将应用于目标分支。这些参考分歧，并且targt分支的尖端不断移动。因此，创建了许多合并提交。 Gerrit支持rebase和cherry-pick，但merge是使用最广泛的。