赞
踩
rebase为当master有了新的提交,而自己的分支拉取的master相比最新提交有了落后的情况,需要及时通过变基转换为新的底座,这个master就是底座,我们需要进行rebase
笔者在开发中,需要依赖下游分支,而下游分支也是正在开发联调以及测试中的,因此不时就应该对下游分支进行merge拉取,而这种merge会增加新的一条无效提交记录,让自己的改动和下游分支的改动混合在一起,难以做Code Review的分辨,因此最好使用rebase进行冲突的解决
如果当前开发分支是feature/A,feature/A是从远程feature/B分支上拉取过来的,远程feature/B也在同步进行开发,如果想要拉取feature/B最新的分支,有两种方法:
假设你有两个分支,一个是 master 分支,一个是 feature 分支,你在 feature 分支上开发了新功能,现在你想把这个新功能合并到 master 分支上,你可以按照以下步骤操作:
首先,你需要切换到 master 分支:
git checkout master
然后,你可以使用 git merge 命令将 feature 分支合并到 master 分支:
git merge feature
如果在合并过程中出现冲突,Git 会提示你。此时,你需要手动打开冲突文件,找到以下类似的标记:
<<<<<<< HEAD
代码片段 A
代码片段 B
你需要决定保留代码片段 A 还是代码片段 B,或者可能是两者的某种组合。解决冲突后,删除 <<<<<<< HEAD,=======,>>>>>>> feature 这些标记。
解决完所有冲突后,使用 git add 命令将解决冲突后的文件标记为已解决状态:
git add <解决冲突后的文件>
最后,提交这次合并以及冲突解决:
git commit -m “Merge feature branch and resolve conflicts”
这样,feature 分支的新功能就被合并到了 master 分支上。
俗称变基,如果远程feature/B自拉取之后有 1——2——3——4,4次提交,我本地的feature/A有1‘——2’——3‘ 这3次提交,rebase会生成下面的这种情况
1——2——3——4——1‘——2’——3‘,尽管在开发的过程中,可能1‘、2’、3‘先于feature/B的4提交,执行rebase依次会将1’、2‘、3’放在4的后面,这也是rebase的弊端,无法区分当前开发分支(feature/A)是从什么时候在feature/B中拉取出来的,因此在有一些公司中不推荐使用
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。