问题描述

多个dev分支在同步开发，同时发起代码评审，但合入master的时候存在先后顺序，那么后面同文件的操作则会提示“合并有文件冲突”，导致代码无法入库，只能重新提交。

在个人分支中如何解决与master分支差异，从何顺利提交评审合入代码？

参考方案

1、按照下面的流程还是没办法在本地已经提交代码的时候正常合并到最新分支代码

# 切换到master分支 
git checkout Android_V_master# 更新master分支代码
git pull Android_V_master# 切回dev分支
git checkout Android_V_dev# 合并master的代码
git merge Android_V_master

2、不知道为什么提交到同一个dev分支的时候，提示找不到这个分支，所以push报错了。

Note：删除分支

# 删除Test_V_dev分支
git push origin --delete Test_V_dev# 如下删除只是本地操作
git branch -D Test_V_dev

处于要删除的分支时，是无法删除的。

Git相关知识

在本地多次merge手动解决冲突的时候，报错 [rejected] (stale info)

分支 [rejected] 报错通常发生在尝试推送一个分支到远程仓库时，远程分支的信息已经发生了变化，从而导致推送操作失败。这种情况通常是因为多个开发者同时对同一个分支进行了更改，或者远程分支已经被更新但本地仓库并未同步的情况下出现。

要解决这个问题，可以先使用 git pull 命令拉取远程仓库的更新到本地，解决可能出现的冲突，然后再尝试推送本地的更改。如果还是存在问题，可以尝试强制推送（git push -f），但需要注意这样可能会覆盖他人的更改，所以要慎重使用。

 

fetch和rebase哪个先执行才正确保证代码不冲突？

在进行代码更新时，一般来说，先执行fetch，再执行rebase可以更好地保证代码不冲突。

fetch命令用于从远程仓库获取最新的提交记录，但不会将远程分支合并到本地分支。这意味着你可以在本地查看远程仓库的更新情况，然后决定是否要进行合并。

rebase命令用于将本地的未推送的提交变基到最新的远程提交之上。这样可以保持项目历史记录的整洁，并避免产生不必要的合并提交。执行rebase之前，首先要确保你的本地分支是基于最新的远程分支的，这就是为什么需要先执行fetch。

因此，先执行fetch可以帮助你了解远程仓库的最新状态，然后再执行rebase可以确保你的本地提交与远程提交保持同步，同时尽量避免冲突产生。