我这里有一个git存储库，有几个人正在处理它。
我已经设置了branch.master.rebase = true和branch.master.mergeoptions = --no-ff，但我遇到了一个问题：
有人试图将功能分支合并为主分支。合并成功，git表示该分支机构在origin / master之前提交了30个提交。当他试图推动变化时，git拒绝推送因为那里的遥控器发生了变化，所以他不得不拉扯。当他做了拉动时，git为那些合并为master的提交做了一个rebase，现在只有29次提交才能成为master。
我认为合并提交已丢失，因为在rebase之后，提交的地方重新应用为新提交，而不是来自功能分支的提交。
推后，树就像那样：
* c3'(head, master, origin/master)
* c2'
* c1'
| * c3 (feature_branch, origin/feature_branch)
| * c2
| * c1
| /
*
这就是我想要实现的目标：
* c4 (head, master, feature_branch, origin/master)
| \
| * c3 (origin/feature_branch)
| * c2
| * c1
| /
*
合并看起来像是一个快速合并，我正在努力避免，以保持分支历史。
有关我可以采取哪些措施来避免这种情况的提示？
谢谢，
编辑： 这篇文章描述了我的问题： http://notes.envato.com/developers/rebasing-merge-commits-in-git/
现在我知道git rebase的--preserve-merges选项，但有没有办法让这个选项成为默认选项？
否则，开发人员必须git fetch和git rebase origin/master而不是git pull。
答案 0 :(得分：3)
如果要保存所有分支历史记录，为什么要使用branch.master.rebase = true？
答案 1 :(得分：3)
保持历史清洁很多次都被过分强调。 DAG（有向非循环图）的性质允许对特定提交（sha1，标签，分支，树等）的引用进行简单的集合操作，以查看已经合并的提交或者仍然需要合并的提交。不进行重新定位可以更准确地保存历史记录，从而显示并行开发的内容以及合并后的内容。
要添加，如果你可以使你的功能变小，你可以通过使用每个功能分支来进行相当有条理的组织。这是我们使用的工作流程：
https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
最初我喜欢保持我的历史不错，整洁和线性。随着我越来越多地使用Git，很明显这是使用像SVN这样的非DVCS工具的延续。