V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
helee9199
V2EX  ›  程序员

公司项目终于从 svn 迁移到 git 了,目前碰到一些问题想请教下。

  •  
  •   helee9199 · 2023-12-07 14:06:48 +08:00 · 4082 次点击
    这是一个创建于 380 天前的主题,其中的信息可能已经有所发展或是发生改变。

    起因还是之前系统问题,因为服务器 SVN 版本过老, 遂建议迁移 git ,讨论了一下决定可以。
    于是我就帮忙架了 gitea
    使用都还好 ,目前碰到一个问题是,多人同时改一个项目时频繁出现
    Merge remote-tracking branch 'origin/main'

    说一下我们的情况, 小公司 小团队,10 开发人员。 项目也比较老,没有模块化,所以不是那种每人负责自己的模块那种。 我一个人的提交线就是一条直线, 但是当有别人提交的时候 很容易就出现 Merge remote-tracking branch 'origin/main' 虽然好像也没啥影响。
    因为就这么点人,使用方面就是 线上版本用分支 onlie 和 main 分支做开发版 ,
    有什么都往 main 里提。线上有问题就切 onlie 改线上的,等没啥情况了再合到 main 。 但是目前几乎只要提交记录里出现别人 就会出现这个提示。 提交前更新在第一次出现这个问题的时候,也交代了大家,也做了,但是还是出现了。 查了下 好像没什么影响。但是就是看着有点烦。

    所以想问下。git 的正确姿势是什么。我们的使用方法有哪些需要改正的?

    35 条回复    2023-12-08 16:51:05 +08:00
    renfei
        1
    renfei  
       2023-12-07 14:12:18 +08:00
    建议看下 GitFlow 工作流
    每人一个分支,然后往基准分支中 merge 合并
    基准分支往个人分支中的话,使用变基 rebase
    kaf
        2
    kaf  
       2023-12-07 14:13:30 +08:00
    建议看下 GitFlow 工作流
    jowan
        3
    jowan  
       2023-12-07 14:14:50 +08:00   ❤️ 12
    人不多直接公用一个 dev 分支 再 merge 到 master
    提交之前拍一下桌子大喊:哥要 PUSH 了!!
    Guaidaodl
        4
    Guaidaodl  
       2023-12-07 14:16:49 +08:00
    你们这个接近主干开发的流程, 就是所有的开发都是在一个分支上开发.

    在这种开发模式下, 开发在 push 之前要先把自己的提交 rebase 到最新的代码上. 具体的命令就是你运行 pull 的时候加上 --rebase 参数
    cheng6563
        5
    cheng6563  
       2023-12-07 14:17:14 +08:00
    正常现象
    Guaidaodl
        6
    Guaidaodl  
       2023-12-07 14:18:09 +08:00
    话说回来, 这种开发模式很考验开发人员素质. 建议考虑切换到 Git Flow 的工作流.
    awalkingman
        7
    awalkingman  
       2023-12-07 14:43:50 +08:00   ❤️ 1
    @jowan 桌子:你礼貌吗
    newaccount
        8
    newaccount  
       2023-12-07 14:51:14 +08:00
    别瞎扯 git-flow ,你这又不是多版本发布,别搞那玩意
    保持单一主线跟你的线上版本一致,就假设是 online
    其他人开的时候从哪里切分支出来都无所谓,准备上线的时候,从 online 切个 testing 出来
    准备上线的功能强制 rebase 到这个 testing ,不能做的就 cherry pick ,保持 tesing 是一条直线,不要有奇奇怪怪的合并出现
    tesing 去测试,没问题了上线,然后 online 去 merge testing ,合并的时候强制 --ff-only

    上面是改了名字的做法,你也可以直接用 master 当做在线分支,重点是做好权限控制,只允许一个人合并到 master
    简单的讲:
    1. 只有一条线,其他分支都可以删
    2. 只有一个人可以合并这条唯一的线,合并时必须 --ff-only
    yangzzzzzz
        9
    yangzzzzzz  
       2023-12-07 14:51:54 +08:00
    主分支合并 其他分支只变基到主分支。
    janus77
        10
    janus77  
       2023-12-07 15:03:16 +08:00
    最省力的做法我遇到过一个,那就是每个人自己开发的时候先切一个本地分支出来,在新的本地分支上面开发,然后提交的时候把这个分支合到本地的主分支,然后主分支 push 上去。
    举例:员工 A 要开发 a 功能,他在他的电脑上建一个本地分支,随便取名,就叫 fucka 吧。写完以后把 fucka 合到本地的 main ,然后 main 推到远程。无冲突。
    好处:
    - 代码冲突较小,本地分支可以写一个功能以后就合,此时改动小,解决冲突也容易。然后合完以后本地分支可以删掉,下次开始写代码的时候再开新的本地分支,保证干净。本地分支可以随便取名,随建随删。每个人都有自己的本地分支,只合自己的那部分改动,冲突也是自己最熟悉、最容易解决。
    - 每次解决冲突都是本地操作,也是改代码的那个人本人亲手操作。他熟悉代码,解决冲突更容易,而且不会影响到远端。
    HaroldFinchNYC
        11
    HaroldFinchNYC  
       2023-12-07 15:03:57 +08:00
    如果代码发生冲突,多半是管理者的问题
    nerkeler
        12
    nerkeler  
       2023-12-07 15:05:20 +08:00 via Android
    我也也是这样,但是我们这纯属拿 git 当 svn 用,多人公用 dev ,测试好了手动在提到 prd
    yidinghe
        13
    yidinghe  
       2023-12-07 17:08:44 +08:00
    没有模块化就先模块化一下
    helee9199
        14
    helee9199  
    OP
       2023-12-07 17:18:53 +08:00
    @yidinghe 模不了,真模不了。屎山了
    helee9199
        15
    helee9199  
    OP
       2023-12-07 17:25:34 +08:00
    @renfei
    @kaf
    @Guaidaodl 小团队来讲 gitflow 这个太复杂了。
    @janus77 简而言之是不是做需求就切分支 做完再合并回去 就不会出这个提示了是吧?
    @nerkeler 是不是 main 一条 不动 然后一条 dev 一条 online ,dev 和 online 各改各的 然后 online 合并回 dev 然后 dev 在合并到 main 总之不到 main 上提交对吧?
    alleluya
        16
    alleluya  
       2023-12-07 17:25:39 +08:00
    @newaccount 根据我的经验 我觉得你说的很有道理
    yc8332
        17
    yc8332  
       2023-12-07 17:31:17 +08:00
    这个就是你们提交的时候没有拉取一下。如果是 commit 再拉取,他就会有一条这种记录。。
    jiangzm
        18
    jiangzm  
       2023-12-07 17:34:29 +08:00   ❤️ 2
    相当于把 git 当 svn 用, 那 svn 提交代码前是不是要拉下远程不然提交不上去。
    同样 git 在提交(push)前也先同步下`git pull --rebase`,这样本地提交到远程都是增量提交。

    其实最好还是开发人员要有自己的开发分支,功能完整再合并到主开发分支。
    dif
        19
    dif  
       2023-12-07 17:36:13 +08:00
    每人一个分支,修改谁的,改完自己合并,如果有 codeview ,就指定开发组长才可以合并。其他人通过 gitea 发起合并申请。最终合并到 dev 分支,测试没问题合并到 master
    xloger
        20
    xloger  
       2023-12-07 17:44:02 +08:00
    首先是要有意识,Git 切换分支是比较轻量的,所以是可以多分支开发。
    一个简单的协作方式是:dev 分支当开发分支,然后每个人自己一个 dev-xxx 分支,某个人每次开发完一部分把代码合并到 dev ,需要的时候也从 dev 拉代码到 dev-xxx 分支。
    这种是比较简单省事不容易出问题学习成本也不高的方式。

    另一种更简单的方式就是其他人说的,push 的时候选 rebase ,在 IDEA 里也是一键的事。
    SilentOrFight
        21
    SilentOrFight  
       2023-12-07 17:47:31 +08:00
    每个人一个分支,把改动的 commit cherry-pick 到主分支合并测试
    zero47
        22
    zero47  
       2023-12-07 17:48:52 +08:00
    共用分支太频繁的锅,commit 的时候没 pull ,别人 push 后 head 就对不上了,一般 gui 的 git 就会帮你生成这个 merge ,个人分支定期合并到公共分支会好点。
    kogorou
        23
    kogorou  
       2023-12-07 22:37:30 +08:00
    每次开发新功能的时候就从主分支切一个新分支分配给开发者,开发人员在这个分支上 commit,push ,完成以后让开发人员提交 pull request ,然后你审核好她的代码没问题,再把这个分支 merge 到主分支上去。关键就是,merge 这个事情让一个人做,不能大家都往上 merge 。
    kogorou
        24
    kogorou  
       2023-12-07 22:38:57 +08:00
    一个人一个分支,一个功能一个分支,切分支又不花钱。
    bthulu
        25
    bthulu  
       2023-12-08 08:40:19 +08:00
    CTRL+T 拉代码的时候, 下面两个选项默认选中的是第一个, 你戳一下选中第二个就没有 Merge remote-tracking branch xxx 了

    Merge incoming changes into the current branch.
    Rebase the current branch on top of incoming changes
    lovelylain
        26
    lovelylain  
       2023-12-08 08:53:27 +08:00 via Android
    强迫症吗?实在是不喜欢有 merge 提交,可以 rebase 再 merge ,例如开发分支 dev 主干分
    支 main ,在发布前:
    git checkout dev
    git fetch
    git rebase origin/main #这一步如果有冲突,处理起来比直接 merge 麻烦
    git checkout main
    git merge dev
    我以前喜欢在发布前这么干,可以使一个特性的提交集中到一起,后来因为冲突解决更麻烦和 dev 分支要 push -f ,改直接 merge 了
    balabalaguguji
        27
    balabalaguguji  
       2023-12-08 09:01:01 +08:00
    要不试下我们的 SVN 代码托管平台: https://svnbucket.com
    a33291
        28
    a33291  
       2023-12-08 09:16:39 +08:00
    我也经常见到这个,原因是 IDE 的自动化机制导致的,至少 vs 会这样.
    我使用独立的 git 管理工具,从不出现这个问题
    tearzx
        29
    tearzx  
       2023-12-08 09:26:48 +08:00
    git pull -r
    horizon
        30
    horizon  
       2023-12-08 09:28:04 +08:00
    gitlab flow
    mengdodo
        31
    mengdodo  
       2023-12-08 10:43:07 +08:00
    不模块化就是找罪受,同一个文件所有人反复改,最后被别人丢弃了都不知道
    helee9199
        32
    helee9199  
    OP
       2023-12-08 10:50:29 +08:00
    @mengdodo 快 20 年的项目改来改去的
    同事习惯也不好。没用的代码不删,注释丢在那 。也不格式化。不会抽取。不停造差不多的轮子。
    甚至 jdbc 的 rs 连线不关被我发现了,狡辩说 rs 不是连线。 提交记录是为了解决宕机问题
    比我早进公司一年( 6 年),就这水平混到现在。
    另外我们是真扁平化。质量没人管。
    10 个人 只有包括我在内的 2 3 个人习惯好一点。
    现在的代码就是屎屎屎屎山。
    鉴于在四线城市。薪资凑合,不加班。前年鉴于此想跳槽来着,但是薪资打 8 折 ,还单双休。
    就只能在这养老了
    7inFen
        33
    7inFen  
       2023-12-08 10:50:42 +08:00
    建议把 online 设为保护分支,只有 leader 可以从 main 合并到 online
    main 分支代码是主分支,再切一个 dev 分支各自开发,开发测试完合并到 main 分支
    nothingistrue
        34
    nothingistrue  
       2023-12-08 14:50:42 +08:00
    在还不熟悉 git 工作流的时候,先强制禁用默认的 merge pull ( fetch + merge ),改为 rebase pull ( fetch + rebase ),这样的话,提交历史的表现会跟 svn update 一样的。
    rnv
        35
    rnv  
       2023-12-08 16:51:05 +08:00
    git pull --rebase 试试
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2858 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 07:11 · PVG 15:11 · LAX 23:11 · JFK 02:11
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.