如何定期将Git中一个分支的变更转移至另一分支且保留原分支？

我希望在分支A上开展工作，并定期将分支A中的变更同步至分支B，但不想关闭或删除分支A，仍需继续在该分支上工作。需要一种可定期执行、无需额外调整的方案，纠结是使用cherry-pick？带参数的git merge？还是其他方法？同时有两个疑问：这种操作是否属于不良实践？若使用git merge将分支A合并至分支B，合并后继续复用分支A是否属于良好实践？

推荐使用带--no-ff参数的git merge，这是最适合定期全量同步分支变更且无需额外调整的方案，具体操作步骤固定可重复：

1. 切换到目标分支B：

   git checkout B
   

2. 拉取远程分支B的最新代码（多人协作场景下执行）：

   git pull origin B
   

3. 合并分支A的所有变更到B，--no-ff参数会强制创建新的合并提交，清晰记录每次同步的节点：

   git merge --no-ff A
   

4. 推送合并后的分支B到远程：

   git push origin B
   

方案对比 #

• cherry-pick：仅适合同步分支A中的部分特定提交，若定期同步所有变更，需要逐个指定提交哈希，操作繁琐易遗漏，还会生成重复提交记录，后续全量合并时可能引发冲突或历史混乱，不符合你的需求。
• 普通git merge（无--no-ff）：默认执行快进合并，直接将分支B的指针移动到分支A的最新提交，虽操作简单，但会丢失分支A的开发历史节点，后续难以追溯每次同步的时间和内容，不利于维护。
• git rebase：会改写分支B的历史记录，若分支B是多人协作的公共分支，会导致其他协作者的本地分支与远程分支不一致，引发同步问题，绝对不推荐。

1. 定期同步分支A到分支B是否属于不良实践？
   这取决于你的分支策略：如果分支A是长期迭代的开发分支（比如持续开发新功能的feature分支），分支B是预发布或稳定交付分支，定期同步是合理的——它能让B及时获取A的最新进展，提前发现集成冲突和问题，降低最终全量合并的风险。只要保持分支职责清晰（A专注新功能开发，B专注稳定交付），就不属于不良实践。

2. 合并后继续复用分支A是否属于良好实践？
   完全是良好实践。Git的分支设计本身就支持长期分支的持续迭代，合并操作只是将A的变更整合到B，不会对A的后续开发造成任何影响。只要你在A上保持代码质量（比如定期做代码审查、单元测试），继续在A上开发新功能完全符合Git的使用规范。

内容的提问来源于stack exchange，提问作者Nikolai Chichulin