git push时出现non-fast-forward updates were rejected的问题的解决

详情见git push --help中的NOTE ABOUT FAST-FORWARDS部分

什么是FAST-FORWARDS
假设远端分支的最新提交为A，本地分支的最新递交为B，只有本地分支上有A且B是在A的基础上修改得到的，此时push上去是一个“fast-forward update from A to B”

non-fast-forward场景及解决
1. 场景1，多人开发，都从X开始改代码，一个人改完后push改动A，此时另一个人提交改动B就是non-fast-forward，这个提交会导致A的丢失。



从X新建一个分支tmp（如果本地master分支只进行pull操作的话，那么此时master的最新提交时X，master分支也可以），git pull，这时tmp的最新提交是A。在B所在的分支上执行git rebase tmp，解决冲突。此时B就可以变成A的子节点，此时git push就是FAST-FORWARDS，可以正常push。
2. 场景2，单人开发（这个要确保是单人，比如使用github时我们fork的分支就一般是单人开发。不然就有可能变成场景1，强制提交会引起代码丢失），git push之后，远端最新提交为A，此时要么执行git --amend变到B，要么将A回退了修改或变到B

这时push上去不会引起未预期的代码丢失，可以使用git push --force来强制提交。
（注：在git --amend的场景，如果将远端提交close掉，在重新push，会导致远端的代码审核者需要重新看一遍所有的代码。这种场景下的--amend，仅仅在--amend时只改commit提示时才建议使用。否则还是新开一个commit，否则依然会导致远端代码审核者需要重复审核代码。新的commit时，远端审核这只需要看这次新的commit的修改内容就可以了）