这是一个创建于 383 天前的主题，其中的信息可能已经有所发展或是发生改变。
remote 的 develop 分支，经过 merege request 之后，commit: xx 历史记录里面会有两条，一条是本身的 commit 记录，还有一条是 merge branch feature_x into deveop 的记录。
如何去掉 merge branch feature_x into deveop 这个 commit 记录？
 |
1
virusdefender 2023-10-23 09:46:26 +08:00
用 rebase ，gitlab 之类的都有选项可以调
|
 |
2
vincent20 2023-10-23 09:47:03 +08:00
rebase
|
|
3
virusdefender 2023-10-23 09:47:08 +08:00
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. |
 |
4
MENGKE 2023-10-23 09:49:07 +08:00
git merge xxx --no-ff
|
 |
6
Plutooo 2023-10-23 09:50:02 +08:00
rebase + 1
|
 |
7
hokori 2023-10-23 09:59:13 +08:00
rebase
|
 |
8
0x2CA 2023-10-23 10:01:44 +08:00
对于 git 的操作应该是 merge 而不是 rebase ，对于任何的操作应该都需要记录，如果你使用 rebase ，实际上你操作了，提交的 commit 不一定是你要提交的，想退回会比较困难，如果你不想要看见这样的记录，可以自定义 commit 信息，但是一定要有这个 commit
|
 |
9
wu67 2023-10-23 10:15:41 +08:00
git log --no-merges
|
 |
10
victimsss 2023-10-23 10:37:24 +08:00
虽然平常都是 rebase ，然而我更喜欢 merge 的做法。
|
 |
11
zxf4399 2023-10-23 10:48:47 +08:00
git merge --ff-only <branch>
|
 |
12
pkoukk 2023-10-23 10:49:13 +08:00
多人协作的时候，这条 merge 记录是有意义的，它代表由谁审核过了这个 merge ，并允许合并的
例如，开发这个项目的有 2 个 maintainer A ，B ，功能由 developer C 开发 那合并记录就能看出来，功能的 commit 是 C 做的，如果 merge commit 是 A ，说明是 A review 之后合进来的 |
 |
13
shawndev 2023-10-23 10:52:30 +08:00
--ff-only
|
 |
14
superchijinpeng 2023-10-23 10:54:00 +08:00 via iPhone
fast forward
|
 |
15
adoni 2023-10-23 10:55:00 +08:00
在本地使用 rebase
在远端（网页上 merge 的时候）使用 fastforward |
 |
17
unco020511 2023-10-23 14:19:07 +08:00
gitlab Fast-forward merge
文档:https://docs.gitlab.com/ee/user/project/merge_requests/methods/#fast-forward-merge |
 |
18
sycwiki 2023-10-23 14:26:54 +08:00
rebase/cherry-pick
|
 |
19
nothingistrue 2023-10-23 14:27:30 +08:00
merge branch xx into xx 是一条正式 Git 提交，你要是去了，你会被打死，谨记。
|
|
20
nothingistrue 2023-10-23 14:50:20 +08:00
如果你不想让出现 merge branch feature_x into deveop 的提交，那么你需要调整的是修改 merege request 的执行合并的方式，让起实质上只能是压缩提交，或者快速合并。但之前已经做过的，是不能改的。
压缩提交方式，会将待合并分支的所有提交先压缩成一个提交，一般不建议这么做，严重丢失历史。 快速合并有前提的，两个分支开叉的地方，必须是主分支的 Head ，即实际上主分支原地没动，只有待合并分支生成了新内容。要么你需要外部限定一次只能有一个开发分支（这就不存在分布式开发了，实际上连 SVN 都不算，直接回到了 VSS 时代的先锁定后修改方式）。要么得借助于然 rebase ，待合并分支先变基，然后再往主分支合并（这就类似于 SVN 方式了）。并且，你还得配置 merege request 的执行方式是 --ff-only 。 |
 |
21
tusj 2023-10-23 14:52:37 +08:00
git pull -r
|
|
22
nothingistrue 2023-10-23 14:52:44 +08:00
merge branch xx into xx 正好跟外部文档上的 merge request 一一对应，是一条非常有用的提交。安心留着吧。
|
 |
23
ilovey482i 2023-10-23 15:01:39 +08:00
我很好奇，为啥楼为啥要去掉这个呢？
|
 |
24
lete 2023-10-23 17:21:22 +08:00
@ilovey482i #23 看着难受
|
 |
25
kirory 2023-10-23 19:41:39 +08:00
grep -v 'merge branch'
|
 |
26
nightwitch 2023-10-23 20:21:46 +08:00
|
 |
27
duanxianze 2023-10-23 20:23:40 +08:00
根据我的实际经验，不要有这种洁癖，难看总比出问题要好
|
Select Language