V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
git
Pro Git
Atlassian Git Tutorial
Pro Git 简体中文翻译
GitX
lidjxy
V2EX  ›  git

Git rebase 和 merge 是不是没办法混着用?

  •  
  •   lidjxy · 2020-03-29 14:45:25 +08:00 · 5739 次点击
    这是一个创建于 1460 天前的主题,其中的信息可能已经有所发展或是发生改变。

    团队里其它人用的 merge,我用的 rebase,发现好像 rebase 会带上其它人产生的 merge commit 之前自己合进去的 commit,有什么办法能混着用吗?还是只能一起用 merge

    34 条回复    2020-03-30 14:30:36 +08:00
    tedzhou1221
        1
    tedzhou1221  
       2020-03-29 15:08:37 +08:00 via Android
    我也是一直 rebase,团队有某几个人 commit 前都没有先 pull,所以他们每次都是 merge 。

    所以一直都是混用,暂时没有遇到大的问题.就是那条线比较乱。

    还有就是要求团队每个人按一定规范去提交代码比较困难。目前没有强制。
    Haujilo
        2
    Haujilo  
       2020-03-29 15:14:39 +08:00
    没理解,你们现在不就等于是混着用吗?
    leafre
        3
    leafre  
       2020-03-29 15:21:59 +08:00   ❤️ 4
    变基 vs. 合并
    至此,你已在实战中学习了变基和合并的用法,你一定会想问,到底哪种方式更好。 在回答这个问题之前,让我们退后一步,想讨论一下提交历史到底意味着什么。

    有一种观点认为,仓库的提交历史即是 记录实际发生过什么。 它是针对历史的文档,本身就有价值,不能乱改。 从这个角度看来,改变提交历史是一种亵渎,你使用 谎言 掩盖了实际发生过的事情。 如果由合并产生的提交历史是一团糟怎么办? 既然事实就是如此,那么这些痕迹就应该被保留下来,让后人能够查阅。

    另一种观点则正好相反,他们认为提交历史是 项目过程中发生的事。 没人会出版一本书的第一版草稿,软件维护手册也是需要反复修订才能方便使用。 持这一观点的人会使用 rebase 及 filter-branch 等工具来编写故事,怎么方便后来的读者就怎么写。

    现在,让我们回到之前的问题上来,到底合并还是变基好?希望你能明白,这并没有一个简单的答案。Git 是一个非常强大的工具,它允许你对提交历史做许多事情,但每个团队、每个项目对此的需求并不相同。 既然你已经分别学习了两者的用法,相信你能够根据实际情况作出明智的选择。

    总的原则是,只对尚未推送或分享给别人的本地修改执行变基操作清理历史, 从不对已推送至别处的提交执行变基操作,这样,你才能享受到两种方式带来的便利。
    wellsc
        4
    wellsc  
       2020-03-29 15:22:26 +08:00
    最好只用一种
    Haujilo
        5
    Haujilo  
       2020-03-29 15:27:42 +08:00
    我曾经做过尝试,结论是除非你自己是代码管理员,有权利可以拒绝别人的提交,否则你就只能自己玩 rebase,别人 merge 你自己 rebase 是没关系的。rebase 比 merge 稍微难理解,很多码农不肯去学习,很难强推。如果你通过重写历史的方式把别人的 merge 弄掉,整条分支线会变更,其他人都需要删掉分支重新 pull,就看你们团队人员多不多了。
    murmur
        6
    murmur  
       2020-03-29 15:28:52 +08:00
    看你们的习惯,只要是科学管理都行,rebase 会扔掉一些修改痕迹,但是合出来一条笔直的线贼拉漂亮
    Xbluer
        7
    Xbluer  
       2020-03-29 15:54:49 +08:00
    我猜,如果你们服务器上禁止 push --force, 那么你和你的同事应该没有使用同一个服务器分支。

    版本结点 A rebase 到版本 B 结点上,则会查找 A 、B 的共同祖先版本结点 C,然后将 C...A 所有操作都在版本结点 B 上重新操作一遍,不论 C...A 之间的操作是不是当前用户。

    如果是使用同一个服务器分支开发,并禁止 push --force ,那 rebase 就只会包含你没有 push 到服务器上的 commit 。
    hantsy
        8
    hantsy  
       2020-03-29 15:57:12 +08:00
    rebase 会重整 Commit 记录,项目提交记录看起来比较舒服,有时有一些无效的提交(比如少了什么问题,后来加一个 Commit 添加缺少的文件)可以合并。国外的很多开源项目,基本都是要 Rebase,比如一个 PR,经过多次 Code Review 修改,最终会合并到一个 Commit 上去。
    Merge 能比较能真实的反应提交记录,比较简单,对于习惯不好的团队,整个团队的提交时间长了 Graph 看起来就是一团麻。
    Shawlaw
        9
    Shawlaw  
       2020-03-29 16:28:40 +08:00
    rebase 和 merge 操作在团队协作时并没有冲突关系,仅仅是代码合入稳定的协作分支(例如 master 或者 develop )的那一时刻需要做的一个选择——是要以 non-fast-forward 方式直接 merge (生成一个 merge 提交),还是 rebase 后 non-fast-forward 方式 merge (生成一个 merge 提交),还是 rebase 后 fast-forward 方式 merge (不生成一个 merge 提交,直接保留记录到新分支)。
    至于提到的 rebase 后会带有之前已 merge 的提交的情形,大概率是之前已 merge 的提交里修改的内容在 merge 后又被改动了,这时候需要判定是否真的还会带有这个提交,通常来说,这些提交应该在 rebase 过程中被跳过。
    swulling
        10
    swulling  
       2020-03-29 16:48:45 +08:00 via iPhone
    可以混着用而且没啥问题
    creanme
        11
    creanme  
       2020-03-29 16:55:08 +08:00 via Android
    想请教一下,rebase 可不可能造成不可修复的错误?我之前听一个朋友大致说如果犯蠢,rebase 可能造成不可修复的问题,所以他在小组中禁止用 rebase 。
    1423
        12
    1423  
       2020-03-29 17:38:51 +08:00
    在提交前,先在本地 master 分支 pull 更新代码,然后在特性分支 rebase master,解决冲突
    然后在 master 分支 merge -squash commit 信息会生成特性分支的所有提交记录
    jinliming2
        13
    jinliming2  
       2020-03-29 18:08:12 +08:00 via iPhone
    我个人是不建议随时随地 rebase 的,3 楼解释的比较完整,历史记录是有用的,不是为了好看的。只有当必须 rebase 的时候(比如历史提交了敏感信息,需要退回去删掉),才 rebase 。
    分支是需要被保护的,就限制了 push -f 这个万恶之源。
    leo108
        14
    leo108  
       2020-03-29 18:10:45 +08:00
    @creanme
    1. master/develop/release 等公共分支禁止 force push ;
    2. git reflog 了解一下,除非是未 commit 的代码,或者是年代太久远被 git 自动 gc,不然可以恢复到任意状态。
    creanme
        15
    creanme  
       2020-03-29 18:27:27 +08:00
    @leo108 好的,谢谢.
    wangyzj
        16
    wangyzj  
       2020-03-29 19:56:41 +08:00
    rebase 可能会出错
    merge 不会出错
    rebase 看着好看
    rebase 适合单人多分支复杂任务开发
    weixiangzhe
        17
    weixiangzhe  
       2020-03-29 20:07:23 +08:00
    个人感觉,多个开发的话,走类 gitflow 那套的话,feature 分支可以 rebase,其它分支 rebase 不了
    DelayNoMay
        18
    DelayNoMay  
       2020-03-29 20:08:03 +08:00
    混着用,哪个用不了就用另外一个
    DelayNoMay
        19
    DelayNoMay  
       2020-03-29 20:09:38 +08:00
    @tedzhou1221 不是应该先 commit,然后 pull,再 push 吗
    qbmiller
        20
    qbmiller  
       2020-03-29 20:16:47 +08:00 via iPhone
    接住 gitlab squash 大多保证每个功能一条提交记录。
    合并前,是自己 merge 其他还是 rebase 无所谓
    youxiachai
        21
    youxiachai  
       2020-03-29 20:17:25 +08:00
    自己用 rebase
    多人用 merge 。。主要 merge 记录多。。出问题。。找起来直观。。。
    dbskcnc
        22
    dbskcnc  
       2020-03-29 22:31:15 +08:00
    我是 merge,历史记录是有用的,可以看到曾经的工作细节,了解过程跟知道结果一样重要
    laoheshanjigong
        23
    laoheshanjigong  
       2020-03-29 23:54:02 +08:00
    仓库上设置只可以 fastforward merge 就行了。
    szdubinbin
        24
    szdubinbin  
       2020-03-30 00:17:39 +08:00
    @1423 我司也是这种模式,感觉这样结合着 rebase 和 merge 没啥问题。
    PainAndLove
        25
    PainAndLove  
       2020-03-30 00:36:12 +08:00
    rebase 适合自己同时开发多个分支
    scnace
        26
    scnace  
       2020-03-30 01:33:10 +08:00 via Android
    @1423 yep,这是很常见的 GitHub flow 模式。

    这样在 merge 到 master 的 MR/PR 需要回滚时可以直接 revert 。但是如果使用 rebase 的话要 reset 就比较麻烦了,除非是 squash 成了一个 commit 。我的 rebase 但是经常来整理 commit 就是了,在有时间空余的情况下,尽量让之前匆匆写的 commit message 可读可追溯。
    ericgui
        27
    ericgui  
       2020-03-30 07:12:36 +08:00
    我是反对 rebase 的,
    因为它改变历史
    tedzhou1221
        28
    tedzhou1221  
       2020-03-30 07:41:41 +08:00 via Android
    我看上面很多说多分支的情况下操作 rebase 、merge 。我觉得都无所谓了

    问题是我们团队的人喜欢在同一个分支下操作 merge,反正就是看的很不舒服
    Justin13
        29
    Justin13  
       2020-03-30 08:05:43 +08:00 via Android
    别混用,个人项目无所谓,多人协作的最好选定一种,混用容易丢失记录和修改
    xiaoxinxiaobai
        30
    xiaoxinxiaobai  
       2020-03-30 09:15:40 +08:00 via Android
    难道是为了好看???
    frostming
        31
    frostming  
       2020-03-30 09:43:30 +08:00
    master 以及多人协作的分支,不是最好,不是推荐,是必须禁止 rebase


    自己一个人工作的分支可以用 rebase
    Kerwin1202
        32
    Kerwin1202  
       2020-03-30 11:33:10 +08:00
    我一般喜欢 merge 因为 每次大的改动 merge 可以看到对方或者自己改的什么东西. 不管之前怎么改 反正就关注最后就可以了.
    kuro1
        33
    kuro1  
       2020-03-30 12:00:22 +08:00
    反对 rebase +1
    cco
        34
    cco  
       2020-03-30 14:30:36 +08:00
    常用 merge~ 还好吧,也没那么麻烦
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5119 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 09:44 · PVG 17:44 · LAX 02:44 · JFK 05:44
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.