|  |      1virusdefender      2023-10-23 09:46:26 +08:00 用 rebase ,gitlab 之类的都有选项可以调 | 
|  |      2vincent20      2023-10-23 09:47:03 +08:00 rebase | 
|  |      3virusdefender      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. | 
|  |      4MENGKE      2023-10-23 09:49:07 +08:00 git merge xxx --no-ff | 
|      6Plutooo      2023-10-23 09:50:02 +08:00 rebase  + 1 | 
|  |      7DOOMS      2023-10-23 09:59:13 +08:00 rebase | 
|  |      80x2CA      2023-10-23 10:01:44 +08:00 对于 git 的操作应该是 merge 而不是 rebase ,对于任何的操作应该都需要记录,如果你使用 rebase ,实际上你操作了,提交的 commit 不一定是你要提交的,想退回会比较困难,如果你不想要看见这样的记录,可以自定义 commit 信息,但是一定要有这个 commit | 
|  |      9wu67      2023-10-23 10:15:41 +08:00 git log --no-merges | 
|      10victimsss      2023-10-23 10:37:24 +08:00 虽然平常都是 rebase ,然而我更喜欢 merge 的做法。 | 
|  |      11zxf4399      2023-10-23 10:48:47 +08:00 git merge --ff-only <branch> | 
|  |      12pkoukk      2023-10-23 10:49:13 +08:00 多人协作的时候,这条 merge 记录是有意义的,它代表由谁审核过了这个 merge ,并允许合并的 例如,开发这个项目的有 2 个 maintainer A ,B ,功能由 developer C 开发 那合并记录就能看出来,功能的 commit 是 C 做的,如果 merge commit 是 A ,说明是 A review 之后合进来的 | 
|  |      13shawndev      2023-10-23 10:52:30 +08:00 --ff-only | 
|  |      14superchijinpeng      2023-10-23 10:54:00 +08:00 via iPhone fast forward | 
|      15adoni      2023-10-23 10:55:00 +08:00 在本地使用 rebase 在远端(网页上 merge 的时候)使用 fastforward | 
|  |      17unco020511      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 | 
|  |      18sycwiki      2023-10-23 14:26:54 +08:00 rebase/cherry-pick | 
|      19nothingistrue      2023-10-23 14:27:30 +08:00 merge branch xx into xx 是一条正式 Git 提交,你要是去了,你会被打死,谨记。 | 
|      20nothingistrue      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 。 | 
|      21tusj      2023-10-23 14:52:37 +08:00 git pull -r | 
|      22nothingistrue      2023-10-23 14:52:44 +08:00 merge branch xx into xx 正好跟外部文档上的  merge request 一一对应,是一条非常有用的提交。安心留着吧。 | 
|  |      23ilovey482i      2023-10-23 15:01:39 +08:00 我很好奇,为啥楼为啥要去掉这个呢? | 
|  |      24lete      2023-10-23 17:21:22 +08:00 @ilovey482i #23 看着难受 | 
|      25kirory      2023-10-23 19:41:39 +08:00 grep -v 'merge branch' | 
|      26nightwitch      2023-10-23 20:21:46 +08:00 | 
|  |      27duanxianze      2023-10-23 20:23:40 +08:00 根据我的实际经验,不要有这种洁癖,难看总比出问题要好 |