stash了解一下

A、B在各自的分支上干活，适当的时机merge到某个分支。 否则git怎么知道冲突的地方该用谁的代码。

stash跟这有毛关系？楼主是想自动合并冲突文件，目前是不行的，如果可以，何必要告诉你冲突了？

@jjboomsky 这样推送的release也会冲突。
A和B同时修改一个文件，
1. A修改了B的bug，代码有部分需要覆盖
2. A和B改了不同的功能，2份代码需要同时存在。

至于是哪种情况，肯定需要A和B协商沟通，git自己是没办法解决的。

那很显然是不行的，肯定是需要merge一下的嘛~
题主是不是经常被同事覆盖代码？直接看提交记录开喷啊！

A，B更改的是同一块代码那怎么才叫不修改B的推送也保留A的推送呢？你自己的提问就有问题。
这种情况的正确做法就是A stash自己的修改，然后pull远程B的修改，然后合并解决冲突，然后提交，不存在什么同时保证A和B的修改都在。
谁改了哪里commit都会有记录的，包括A对B修改的修改。

@knightdf 其实这个也是可以实现的，叫做“保留双方的修改”，然而对于这种不能自动merge的代码段，很显然是需要手动merge的。如果要保留双方的修改（限于冲突的代码段），那大概率是要报错的。

git push -f了解一下，不过有被砍的风险

你这是基础问题
首先。解决此问题的办法很多。但是不要强推，或者强合
git 先拉后推，永远是对的

首先，你要理解 git 是如何工作的，不要以 svn 的思维去理解 git 根本原理是不同的。一个是中心化的，一个是去中心化的
通常情况下 git 会自动合并双方的修改，当然这个前提是你们改的是不同的位置
一般，对付这种冲突最简单的办法是 先 stash，然后 stash apply，这样可以解决90%的问题

当 A 和 B 修改相同之处的时候，问题就来了。git 会问你怎么处理
遇到了剩下的问题，必须使用 merge tool 进行合并
建议使用图形化工具+ BeyondCompare 解决冲突 不是你改的部分，叫上上一次提交的人确认，或者你团队的人确认
图形化工具可以使用例如 SourceTree, GitKraken

code review！！！

加上review的流程就行了，不然你就先git pull --rebase合一次，push之前再合一次。