长期开发feature branch时rebase master是否需先同步最新？

完全不需要严格按照「切换本地master、拉取最新提交、切回feature分支」的固定流程操作。这套来回切分支的操作只是新手阶段养成的固有习惯，远不是必须执行的步骤。
你这套操作的核心目标其实非常明确：拿到远程master的最新代码基线，把当前feature分支的独立提交重放到这个最新基线上，整个过程根本不需要依赖“把工作区切到本地master分支”这个动作。

全程不切分支的高效操作 #

保持当前停留在feature分支的状态，只需要两步就能完成rebase同步：

• 拉取远程master的最新跟踪提交：执行git fetch origin master
• 直接基于刚拉取的远程跟踪分支执行rebase：git rebase origin/master
  这套流程不会改动你本地的master分支指针，也不会碰到未暂存改动就触发工作区切换冲突，比来回切分支效率高很多——尤其是大仓库场景下，切分支往往要花数秒到十几秒校验全量工作区文件，完全是无意义的等待。

需要同步更新本地master时的操作 #

如果你后续有在本地master分支开展操作的需求，也不需要专门切分支完成更新：

• 直接在feature分支上执行git fetch origin master:master，这条命令会自动把本地master的指针快进到和远程master完全一致的位置，全程不用切换工作区分支
• 执行完成后再跑git rebase master，和你来回切分支操作的最终效果完全没有区别
  注意：如果你的本地master存在未推送到远程的独立提交，这条命令会直接抛出快进失败的报错，反而能帮你及时发现分支状态异常，比手动切过去pull的容错性更好。

常见误区说明 #

很多人觉得必须切分支才能操作，本质是混淆了「分支指针更新」和「工作区切换」的概念：

• git的分支本质只是个指向特定提交的轻量指针，更新这个指针的指向根本不需要把工作区切到对应分支
• 来回切分支反而会带来额外的工作流风险：如果工作区有未暂存的改动，git的分支切换操作可能会因为文件冲突直接打断你正在进行的开发操作

内容的提问来源于stack exchange，提问作者Jason Y