git 如何不显示 merge branch xx into xx 的记录

用 rebase ，gitlab 之类的都有选项可以调

rebase

gitlab 的选项

Merge method
Determine what happens to the commit history when you merge a merge request. How do they differ?

Merge commit
Every merge creates a merge commit.

Merge commit with semi-linear history
Every merge creates a merge commit.
Merging is only allowed when the source branch is up-to-date with its target.
When semi-linear merge is not possible, the user is given the option to rebase.

Fast-forward merge
No merge commits are created.
Fast-forward merges only.
When there is a merge conflict, the user is given the option to rebase.

git merge xxx --no-ff

@MENGKE 不好意思看错问题了

rebase + 1

rebase

对于 git 的操作应该是 merge 而不是 rebase ，对于任何的操作应该都需要记录，如果你使用 rebase ，实际上你操作了，提交的 commit 不一定是你要提交的，想退回会比较困难，如果你不想要看见这样的记录，可以自定义 commit 信息，但是一定要有这个 commit

git log --no-merges

虽然平常都是 rebase ，然而我更喜欢 merge 的做法。

git merge --ff-only <branch>

多人协作的时候，这条 merge 记录是有意义的，它代表由谁审核过了这个 merge ，并允许合并的
例如，开发这个项目的有 2 个 maintainer A ，B ，功能由 developer C 开发
那合并记录就能看出来，功能的 commit 是 C 做的，如果 merge commit 是 A ，说明是 A review 之后合进来的

--ff-only

fast forward

在本地使用 rebase
在远端（网页上 merge 的时候）使用 fastforward

@0x2CA 这个还是看不同的开发模式，主干开发不一定需要这样

gitlab Fast-forward merge
文档:https://docs.gitlab.com/ee/user/project/merge_requests/methods/#fast-forward-merge

rebase/cherry-pick

merge branch xx into xx 是一条正式 Git 提交，你要是去了，你会被打死，谨记。

如果你不想让出现 merge branch feature_x into deveop 的提交，那么你需要调整的是修改 merege request 的执行合并的方式，让起实质上只能是压缩提交，或者快速合并。但之前已经做过的，是不能改的。

压缩提交方式，会将待合并分支的所有提交先压缩成一个提交，一般不建议这么做，严重丢失历史。

快速合并有前提的，两个分支开叉的地方，必须是主分支的 Head ，即实际上主分支原地没动，只有待合并分支生成了新内容。要么你需要外部限定一次只能有一个开发分支（这就不存在分布式开发了，实际上连 SVN 都不算，直接回到了 VSS 时代的先锁定后修改方式）。要么得借助于然 rebase ，待合并分支先变基，然后再往主分支合并（这就类似于 SVN 方式了）。并且，你还得配置 merege request 的执行方式是 --ff-only 。

git pull -r

merge branch xx into xx 正好跟外部文档上的 merge request 一一对应，是一条非常有用的提交。安心留着吧。

我很好奇，为啥楼为啥要去掉这个呢？

@ilovey482i #23 看着难受

grep -v 'merge branch'

@ilovey482i 管理的不好容易出现 merge hell 。。比如同时有 2-3 个活跃的分支在往主线合并，交叉的连线很容易变成蜘蛛网。 比如这种提交历史基本就没法看了

根据我的实际经验，不要有这种洁癖，难看总比出问题要好