个人比较奇葩的解决冲突的方式

stash pop还得解决冲突，直接merge rebase 解决冲突不是一个样子吗

我都是打开文件，一行行读冲突内容然后修改保存重新Commit :) 笨办法

rebase和你的stash法应该是类似的。只是rebase可以用在多次提交上。

我以为你和别人起冲突了...

@Xrong +1。看到标题时还莫名想起了分歧终端机。

前面都理解，最后的push force 什么鬼

git rebase origin/master
有冲突上 beyond compare 3路比较,我觉得这是最好的一种方式了,不过其他的我也不会了

弄这么多就是 `git pull -r`

@ngn999 哈哈，以前人家也是这样跟我说的 https://github.com/AngryLawyer/rust-sdl2/pull/301#issuecomment-72076800

不过我不熟悉 Git 的工作流程，不一步步来我会慌的 :-）

在我正文描述的步骤中间我经常还要检查几次 git-status 和 git-diff 确保我没有搞错 :-P

冲突的话，git merge或者rebase不好？解决冲突。
你的做法的话，在这一步`git stash pop`也会冲突吧？

ps 主干的话，需要`git push --force`这样去force吗？如果你force的话，是否代表，别人也会冲突？

@mahone3297 嗯，主要是保证在上游过编译的前提下我新的提交也是过编译的。
逻辑上还是合并冲突，只不过步骤上分开来了。

合并冲突是在 `git stash pop` 这一步做的没错，这里会出现一些 `<<<<<<<<<<<` 和 `>>>>>>>>>>`，在合并的时候把这些冲突部分处理掉，对正常语言写的代码来说一般就没事。

`git push --force` 我这里的意思是我的 HEAD 这个提交其实已经 push 过了，只不过没有合并到上游的主干，我需要强制性把之前 push 过去的 HEAD 从上游中抹掉。没错如果其他人在依赖我这个 HEAD，那就必须解决新的冲突。所以最好的情况就是代码的模块化比较好，可以保证在没有直接的文件上的冲突的情况下强制性合并。

@bombless
》`git push --force` 我这里的意思是我的 HEAD 这个提交其实已经 push 过了，只不过没有合并到上游的主干，我需要强制性把之前 push 过去的 HEAD 从上游中抹掉。没错如果其他人在依赖我这个 HEAD，那就必须解决新的冲突。所以最好的情况就是代码的模块化比较好，可以保证在没有直接的文件上的冲突的情况下强制性合并。

所以，你的做法应该是merge or rebase，这时候，虽然也会有冲突，然后，你resolve conflicts后，push就可以了，不需要 --force，这样，其他人也不会有任何问题。

@mahone3297 哈哈，多谢提点，我终于明白我这么做的差别在哪了。
之前一直没想通。

不过我在想，如果要 amend 到 HEAD 那就必然有冲突，是这样吗？

@bombless
假如你的commit是这样
..................->a->b->c
..................->a->b->c`
--amend 的话，代表你丢弃之前的c这个commit，新生成一个c`的commit。这时候，别人如果之前拿了你的c commit，这时候，别人fetch代码，git会提示，branch有问题，开叉了。然后，到底会不会出问题，我好想也不清楚了，要试下。

反正，多人提交的branch（比如master），不要force update，amend，除非万不得已。或者知道别人还都没获取你的commit。你自己开的分支，随便force update。我是这么干的。。。
在master上，我即使提交错了，我也会revert上次错的commit。虽然log看起来有点难看，但是不会有问题。（说明下，我的这个做法可能并不一定好，可能有更好的方法）

@bombless
》不过我在想，如果要 amend 到 HEAD 那就必然有冲突，是这样吗？
好像不一定会有冲突。冲突的意义是说，同一行代码，都被修改了。
上面说的，c和c`，假如这2个commit，没有修改到同一行代码，应该是不会有冲突的。

试了下 `git pull -r` 真的很爽……
做完之后 git-add 然后再 `git rebase --continue` 一切就搞定了……
看来没有以前想象的那么难嘛