整理了一下最近开发的分支操作。

假设一个情景：现在项目的最新的版本是在 origin/release/20260815 分支上；现在你跟你的同事需要进行下一个版本的迭代。你们需要新开发需求/修复bug然后保存到新的分支 origin/release/20260821 上。

现在假设你本地是刚拉的项目，只有 master 分支；现在要准备开发。

首先创建本地的最新分支跟踪远程仓库的最新分支；然后在当前最新分支上切出你的开发分支：

git switch -c release/20260815 --track origin/release/20260815

git switch -c feature/20260816-xujunliang

这样你本地的 release/20260815 分支就会跟踪远程分支 origin/release/20260815，本地分支 feature/20260816-xujunliang 就是你的开发分支。

现在远程仓库还没有你的这个开发分支，后续你开发后需要推送到仓库的你的开发分支，所以创建远程仓库的开发分支，并把你的开发分支推送绑定到远程仓库的分支。

git push -u origin feature/20260816-xujunliang

可以去代码仓库检查一下，是不是远程开发分支已经成功创建了。

这个分支是只有我一个人开发，开发完成后就可以直接执行 git push。

git push

如果这个分支是多人协作的(当然如果多人协作，分支名字就不能这么取)，那提交和推送之前就需要检查你本地是否跟远端是同步的。

git pull origin feature/20260816-xujunliang

git push

如果有冲突就解决冲突，解决后执行 git push。

现在假设已经全部开发好了。现在要推送到下个版本的分支 release/20260821 上，如果这个新版本分支还不存在，那你就创建一下然后提交过去。基于你现在最新的开发分支。

git switch -c release/20260821 # 创建本地release分支

git push -u origin release/20260821 # 推送绑定，创建远程release新分支

可以检查下是不是远程仓库已经创建了新的 release 分支并且代码已经跟你本地的开发分支一致。

如果在你打算提交的时候，最新的这个 release 分支已经存在，并且其他开发同事已经提交过了。那你本地就要拉取这个分支，并且把这个分支合并到你自己的开发分支里。

git fetch origin # 让你本地更新最新的仓库分支情况

git switch feature/20260816-xujunliang # 切换到你的最新的开发分支

git rebase origin/release/20260821 # 把最新的release作为你开发分支的基

# 当然merge也行，但是如果分支你一人开发，rebase条理比较清晰

这里 rebase 的作用是，比如 R 是上个版本分支 release-20260815，F1 是你的开发分支，F2 是别人的开发分支，R2 是别人根据他的开发分支创建的最新版本分支 release-20260821。

R---F1  feature/20260816-xujunliang
 \
  F2---R2  release/20260821

rebase 之后你的开发分支的状态就会变成

R---F2---R2---F1'

如果有冲突就处理冲突，然后在推送到开发分支。rebase 会修改提交的编号，所以一般需要 --force-with-lease；它主要是关注远程仓库是否还是上次你看到的状态。以上面的例子举例，远程仓库原本的你的开发分支是 R---F1，rebase 之后变成了 R---F2---R2---F1'，所以就要使用这个参数。

git push --force-with-lease origin feature/20260816-xujunliang

最后把你的最新分支合并到 release/20260821 中。

git fetch origin 

git switch -c release/20260821 --track origin/release/20260821

git merge --ff-only origin/feature/20260816-xujunliang

git push

其中 --ff-only 表示只允许线性向前，如果有冲突或者有其他新提交，会失败。

后续如果测试环境出现了bug，你需要修复并且最后合并到release，流程也跟上述一致。