返回信息流关于github在合并到master，解决冲突的问题：
公司的代码在GitHub上，我在组里人同意了pull request了后，我准备将我的这个branch合并到master里。但是这时我的branch的代码和master的代码已经有些地方是冲突的了，因为master的代码已经跟我最开始的版本有些不一样了。我看组里的大哥是这么帮我操作的，在我的命令行里，输入了这些：
git checkout master
git pull
git rebase master my_branch_name
想请问下大家，我第二步不太明白，pull的时候不就用master的代码把我本地我的branch的代码覆盖掉了吗？为什么看起来并没有，只是把不一样的地方覆盖了下来？
这是一条镜像帖。来源：北邮人论坛 / soft-design / #48423同步于 2019/3/25
该镜像源已超过 30 天没有更新，可能在源站已被删除。
SoftDesign机器人发帖
关于github在合并到master，解决冲突的问题：
PMS
2019/3/25镜像同步30 回复
订阅后，新回复会通过你的通知中心匿名送达。
9 条回复
pull的是master分支，你的分支还是没变。然后rebase的时候把你的分支合进去，自动把你的分支有冲突的地方用master分支的内容覆盖了，你看下master分支的历史，应该可以看到你的commit记录在前面
push -f 一把梭，如果有错误提示，把分支protected关掉就好了
其实楼上说的对，冲突的本质是某个文件在你的分支和master分支都有改动，git不知道该保留哪个。这三个命令的作用是让你的分支上的代码领先于最新的master，如果有冲突在你的本地解好，这样merge的时候git就知道保留你的代码了
push -f 一把梭，哈哈哈，解决一切冲突
【 在 dss886 的大作中提到: 】
: push -f 一把梭，如果有错误提示，把分支protected关掉就好了
: 其实楼上说的对，冲突的本质是某个文件在你的分支和master分支都有改动，git不知道该保留哪个。这三个命令的作用是让你的分支上的代码领先于最新的master，如果有冲突在你的本地解好，这样merge的时候git就知道保留你的代码了
个人觉得该情况下比较正规的做法是先checkout到master，pull最近的代码，然后再checkout到自己分支，合并master代码并解决冲突，然后push自己分支并请求合并到master上
git pull --rebase
如果有冲突手动合并冲突然后git add ，git rebase --continue 完事。
没有冲突直接你的是最新的
举个例子可能比较好理解
冲突场景：当你将自己的开发feature分支合到远程的dev分支时，由于在此之前别人可能已经合到dev分支过，你的feature分支不是基于当前最新的dev拉出的，合并可能出现冲突。
解决办法：
1. merge解决法：在合并之前先将远程dev分支的最新内容拉取过来，在本地合并到你的feature分支，有冲突解决冲突，然后再push到远程进行合并
具体的：
* 在本地切换到dev分支：git checkout dev
* 拉取最新内容：git pull (因为别人提交的时候如果遇到冲突肯定有解决过，所以这里应该不会有冲突)
* 在本地切换到feature分支：git checkout feature
* 合并到本地分支：git merge dev (遇到冲突就解决)
* push到远程分支的feature分支，提Merge Request
分支形式：
2. rebase解决法：在合并之前先将远程dev分支的最新内容拉取过来，在本地对你的feature分支执行变基操作，有冲突解决冲突，然后再push到远程进行合并
* 在本地切换到dev分支：git checkout dev
* 拉取最新内容：git pull (因为别人提交的时候如果遇到冲突肯定有解决过，所以这里应该不会有冲突)
* 在本地切换到feature分支：git checkout feature
* 变基，使你的feature基于最新的dev：git rebase dev (遇到冲突就解决)
* push到远程分支的feature分支，提Merge Request
分支形式：