如何按提交创建时间同步Git分支内容？解决cherry-pick后合并问题

我有两个分支：master和staging。提交C最初在staging上创建，因紧急需求被cherry-pick到master分支，此时分支结构如下：

-x-x-x-A-B-C-D (staging)
      /     
-x-x-x-C (master)     

之后，另一个feature分支被直接合并到master，新增了提交E和合并提交F，分支结构变为：

-x-x-x-A-B-C-D (staging)
      /     
-x-x-x-C-E-F (master)

我需要将master的内容同步到staging，以便后续能将staging干净地合并回master。若直接合并，会因之前的cherry-pick产生重复提交；若使用rebase执行git checkout staging && git rebase origin/master，会将A、B、D置于master内容之上（除非使用--rebase-merges，否则合并提交F不会被同步，这点我不确定），得到的分支结构为：

-x-x-x-C-E-F-A-B-D (staging)

但我希望能按照提交的实际创建时间进行合并，最终得到如下分支结构：

-x-x-x-A-B-C-D-E-F (staging)

请问这种操作是否可行？是否有实际意义？还是将A、B、D置于master内容之上的方案更好？

附git log --graph master的结果（已标注对应提交字母）：

*   commit c0ead31e3f7a7f6e077b2bbb947775dcd2dc3453 (**F**) (HEAD -> master, origin/master, origin/HEAD)
|\  Merge: b943c0fd 07a7dd24
| | Author: Author
| | Date:   Tue Nov 22 03:23:09 2022 +0000
| |
| |     Merge branch 'feature' into 'master'
| |
| |     <commit message for feature>
| |
| |     See merge request company/project!24
| |
| * commit 07a7dd245bec741e1c077d055558b3930c570a3f (**E**)
|/  Author: Author
|   Date:   Tue Nov 22 03:20:57 2022 +0000
|
|       <commit message for feature>
|
* commit b943c0fd70e5ba64b70b03721ab2962facaecbc3 (**C**)
| Author: Author
| Date:   Wed Oct 19 18:49:58 2022 +0000
|
|     <commit message>
|
|
|     (cherry picked from commit e1598f670d0e78e76ee0e54a4a4668e7186adbab)
|

1. 目标结构是否可行？ #

可行，但需要处理cherry-pick带来的提交重复问题，具体操作有两种思路：

• 合并+忽略重复提交：切换到staging分支后执行git merge master -s ours，这个策略会让staging保留自身的A-B-C-D代码状态，同时将master的E-F合并进来，最终生成一个合并提交，历史会呈现为-x-x-x-A-B-C-D-[合并提交]-E-F的结构。
• cherry-pick线性化：如果要完全实现无合并节点的线性结构，可以将master上的E和F单独cherry-pick到staging：

  git checkout staging
  git cherry-pick 07a7dd24  # 提交E的哈希
  git cherry-pick -m 1 c0ead31e  # 合并提交F需要加-m 1指定母本
  

  这种方式会生成新的提交哈希，最终得到A-B-C-D-E'-F'的线性历史。

2. 该操作是否有实际意义？ #

从提交历史的可读性来看，按创建时间排列的线性历史确实更直观，能清晰反映功能开发的时间线。但Git的核心价值在于代码状态的追踪，而非严格的时间顺序——通过git log --date=original就能查看所有提交的真实创建时间，无需强行调整历史结构。如果团队非常看重历史的“叙事性”，这种结构有一定意义；否则，强行调整的投入产出比不高。

3. 哪种方案更优？ #

将A-B-D置于master内容之上的rebase方案（执行git checkout staging && git rebase --rebase-merges origin/master）通常更优，原因如下：

• 后续合并更干净：当staging基于最新master完成rebase后，后续合并回master时Git会直接快速合并，不会出现冲突或重复提交问题。
• 历史更可控：--rebase-merges参数可以保留master上的合并提交F，生成线性且清晰的历史结构，避免额外的合并节点。
• 风险更低：强行调整时间顺序的操作（如多次cherry-pick）可能意外修改代码状态，而rebase逻辑更可控，只要确保在本地分支执行，push时用--force-with-lease就能安全更新远程分支。

注意：如果staging是多人协作的公共分支，不建议使用rebase（会改写历史），此时应选择合并方案，接受合并节点，通过git merge -s ours解决重复提交问题。

内容的提问来源于stack exchange，提问作者Timothy Fisher