@jokechen 迁移远程仓库应该在本地仓库添加 remote ，把代码和提交记录 push 到新的远程仓库。

如果现状是丢失提交记录的话，那应该基于 231102 创建新的分支，把需要合并的代码从 230915 分支找出来拷贝到新的分支里面，然后把新的分支合并到 231102 发版。新的分支同时也建议合并到 230915 ，虽然不会引起代码变化，但是可以提前解决以后 230915 合并到 231102 时可能出现的潜在问题。

总的来说，不能把 230915 直接合并到 231102 。

同意 @Avn #6 的说法，这种情况应该 cherry-pick 。

但是你们这个分支管理也太混乱了，正常情况下(需求之间独立)都应该基于 master 创建新的 feat 分支，本地 checkout feat 分支来开发的。如果多个需求之间相互依赖，就应该要确定 release version 是不是一致。
假设有 A 、B 两个 feat
case 1: A 先发布的情况下， 创建 A 、B 两个分支。提测的时候 A 先合入测试环境 ，B 在本地开发过程中继续 rebase feat A 代码。如果有多个测试环境，A 、B 分开测试更好；
case 2: A 、B 一起发布，创建一个分支即可。跟团队确认并同步两个需求不可独立发布，按期同时发布 or 同时延期

摸鱼时间的回复，可能描述的还不太精准，仅供参考。要管理好分支，本质上还是要将各个开发环境独立开来

我个人是非常反对用 merge 。只用 rebase 和 cherty-pick 。因为有些 commit 可能是不想要的。所以 merge 不可取。release 分支上 cherry-pick 相应的 commit 。

merge 派和 rebase 派，选了一边就不能换。

@byte10 你看一下 git log 的可视化就知道了。merge 的优点是可以保存 feature branch 上的支线 commit 。

merge 产生的是一个“merge commit”，有多个父节点。这样的 commit 在 rebase 的时候非常蛋疼。也就是说，如果一个 branch 有过 merge ，那就基本告别 rebase 了。

rebase-and-squash 对人多的项目比较合适。因为开发人员水平不一，很多人的 feature branch 的历史都乱七八糟。squash 以后主分支上，一个 PR 对应一个 commit ，就非常干净。之后某个 release branch 需要 backport 的话也很方便，直接 cherry-pick 特定 commit 就行。

如果是 merge ，那就要保留对应的 feature branch 。backport 的时候直接从 feature branch 上 merge 。

通过 rebase 解决冲突，最终产物是树狀的历史。通过 merge 解决冲突，最终产物是网状的历史。