V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
miketeam
V2EX  ›  程序员

大神,有每有更好的办法和代码啊,大半夜还在合 啊

  •  
  •   miketeam ·
    5nnok · 2018-01-23 21:37:19 +08:00 · 8460 次点击
    这是一个创建于 2256 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我们主线一个分支,开发一个分支,太多人一起上代码,然后开发分支差主分支好多。现在我大晚上的还将开发分支代码合到主分支,一行行对。你们有我这边折腾吗?求解啊

    85 条回复    2018-01-27 22:27:19 +08:00
    likuku
        1
    likuku  
       2018-01-23 21:40:45 +08:00   ❤️ 1
    定时定期,别拖,别积攒。

    再多要点人帮你合并
    missdeer
        2
    missdeer  
       2018-01-23 21:41:01 +08:00
    我们直接 double commit
    StevenTong
        3
    StevenTong  
       2018-01-23 21:45:22 +08:00
    无解吧
    btcking
        4
    btcking  
       2018-01-23 21:49:22 +08:00
    公式机制被破坏了,哈哈哈。。
    miketeam
        5
    miketeam  
    OP
       2018-01-23 21:50:12 +08:00 via iPhone
    8000 多行代码,真是日狗了
    nciyuan
        6
    nciyuan  
       2018-01-23 21:51:21 +08:00 via Android
    一行一行?
    直接看文件,一样的直接略,开发分支优先
    miketeam
        7
    miketeam  
    OP
       2018-01-23 21:54:28 +08:00 via iPhone
    怕覆盖了别人的,5 个人的代码改来改去,受不了了
    XinLake
        8
    XinLake  
       2018-01-23 21:54:56 +08:00
    不重叠,不遗漏,逐个穷尽,完全独立。
    不同的人做不同模块的代码这种情况就少了,你这估计是有多人做同一个事情就变成这样了
    miketeam
        9
    miketeam  
    OP
       2018-01-23 21:55:06 +08:00 via iPhone
    compare 对比,一个个挑,把我自己的先挑出来。
    miketeam
        10
    miketeam  
    OP
       2018-01-23 21:55:57 +08:00 via iPhone
    一部分人开发新模块,然后又有人局部重构
    thundernet8
        11
    thundernet8  
       2018-01-23 21:56:09 +08:00 via Android   ❤️ 2
    以后要让你的队友 开发习惯性 rebase 主分支
    youdiqs
        12
    youdiqs  
       2018-01-23 21:57:33 +08:00 via iPhone   ❤️ 1
    我们是 git 一个主分支 4 个开发分支
    目前没啥大问题,万一有啥问题反正可以回滚。

    要是对 git 合并不太信任,或者无法测试是否合并正确 or 难以判断冲突的代码
    那就要至少按天来 频繁的合并 才不会导致后期大量堆积代码验证合并。

    也可以用 代码比较工具 来进行对代码一行行的对比合并(太难…耗时间)
    chinvo
        13
    chinvo  
       2018-01-23 21:58:07 +08:00   ❤️ 1
    团队协作没做好

    new branch、pull request 之类的方案要高效率用的基础是团队分工

    避免同时针对同一个 feature/bug 作改动

    每做到一个阶段就提交一次
    miketeam
        14
    miketeam  
    OP
       2018-01-23 22:00:42 +08:00 via iPhone
    这样合并完了明天又是自虐般的自测试验证了。真的好绝望
    Hieast
        15
    Hieast  
       2018-01-23 22:06:23 +08:00   ❤️ 3
    git flow,各自处理各自的 feature 合并到 develop 分支
    miketeam
        16
    miketeam  
    OP
       2018-01-23 22:27:41 +08:00 via iPhone
    你是不知道我们这里 controller 有多重…我现在有空就一点一点的搬。头发都熬白了几根。真真的勇士敢于直面惨淡的垃圾场~
    zjsxwc
        17
    zjsxwc  
       2018-01-23 22:28:55 +08:00 via Android
    是你们分支太少的缘故吧,不可能只有两个分支,一个主分支 master,一个开发分支 dev,这样合并当然会有很多冲突了。


    git 正常使用应该是每个 feature 都从 master 开一个小分支,于是我们工作时会有 n 多小分支,这样既保证了每个小分支可以很容易的(冲突少、逻辑清晰、能快速找到当事人)被合并到 master,又能和 redmine 等项目管理配合起来管理项目,然后定期删除老的 feature 分支就好了。
    miketeam
        18
    miketeam  
    OP
       2018-01-23 22:29:26 +08:00 via iPhone
    你们猜到我这里是几手的代码
    miketeam
        19
    miketeam  
    OP
       2018-01-23 22:29:53 +08:00 via iPhone
    还真是 2 个分支呢
    YyYyYyy
        20
    YyYyYyy  
       2018-01-23 22:30:45 +08:00
    @miketeam 为什么局部重构会和新模块开发有冲突需要合并?那说明这局部的重构就不是解耦的。
    再退一步讲,为什么不用适配器模式把重构部分的对外接口包起来?
    建议明天把搞局部重构的那人拉出去枪毙(不要说是我说的 ε===ᕕ(ᐛ)ᕗ
    miketeam
        21
    miketeam  
    OP
       2018-01-23 22:32:50 +08:00 via iPhone
    想法是好的,我现在改那些代码只能借着修改 bug 去改。主动修改那些代码需要和一堆人讲明情况,拉个 ppt 说明这样改的原因…
    nicevar
        22
    nicevar  
       2018-01-23 22:45:43 +08:00   ❤️ 1
    就两个分支....楼主你不累死也是奇迹,人上得多,效率低下
    这不是合代码的问题,是你们任务分配组织能力有点差啊,尽量把任务分细了,一个分支对应一个任务或者 bug,限制时间,比如每个任务必须三天内完成,如果评估完不成就再细分,这样代码冲突会降到最低
    发布版本的时候迭代做好点,可以一周一小版本,一月一大版本之类的
    miketeam
        23
    miketeam  
    OP
       2018-01-23 22:59:52 +08:00 via iPhone
    我现在最怕的是把别人的代码覆盖了…正在对比,不出意外我马上可以下班了。还有人在奋斗。。
    miketeam
        24
    miketeam  
    OP
       2018-01-23 23:01:28 +08:00 via iPhone
    7 点开始的,中间合了几次,正要上又被抢先了……然后又要拉取代码在看!
    yomiko123
        25
    yomiko123  
       2018-01-23 23:04:24 +08:00   ❤️ 1
    祝你好运吧
    ryd994
        26
    ryd994  
       2018-01-23 23:08:17 +08:00 via Android
    所以分 pull 党和 rebase 党
    nl101531
        27
    nl101531  
       2018-01-23 23:12:44 +08:00
    应该不同的人不要做同一块业务...或者分层逻辑下,不同的人写不同的层.中间用接口沟通
    miketeam
        28
    miketeam  
    OP
       2018-01-23 23:17:31 +08:00 via iPhone
    这个不是 rebase 的问题。主分支跑太快了……
    miketeam
        29
    miketeam  
    OP
       2018-01-23 23:25:13 +08:00 via iPhone
    此刻路上已经没有多少人了……内心拔凉拔凉滴
    miketeam
        30
    miketeam  
    OP
       2018-01-23 23:26:04 +08:00 via iPhone
    狠狠滴骂一句:狗屎架构师
    lihongjie0209
        31
    lihongjie0209  
       2018-01-23 23:26:25 +08:00
    每个人做自己的模块不就好了吗?
    miketeam
        32
    miketeam  
    OP
       2018-01-23 23:32:13 +08:00 via iPhone
    抢出版本,dieline 快来了……
    imNull
        33
    imNull  
       2018-01-23 23:33:32 +08:00 via Android
    master 加锁,只有 owner 有 Merge 权限。
    开发时,每个人一个自己的分支,自己定期合 master,最后提 code review,如果冲突打回重改,最后 owner 合并。

    这样子应该没什么问题了,有问题可以再交流
    eccstartup
        34
    eccstartup  
       2018-01-23 23:35:44 +08:00 via iPhone
    deadline

    git pull --rebase
    miketeam
        35
    miketeam  
    OP
       2018-01-23 23:37:09 +08:00 via iPhone
    以为代码不多的。原本计划 8 点下班,喝喝茶,写写 go 在睡觉。现在撒都不想直接睡了,太困了……
    akring
        36
    akring  
       2018-01-23 23:40:35 +08:00
    @miketeam 我看的都要哭了,简直人间悲剧
    66450146
        37
    66450146  
       2018-01-23 23:45:07 +08:00
    CI 自动从开发分支上 merge 主分支,如果出错的话要求分支作者 rebase / merge 就是了

    我们的做法是,没办法 merge without conflict 的改好才做 code review,测试没通过的修好才做 code review,review 不过的重新改
    PureWhite
        38
    PureWhite  
       2018-01-24 00:19:04 +08:00   ❤️ 6
    @miketeam 楼主,给出一个比较好的实践吧:
    1. 禁止直接 push 到 dev 或者 master 分支,必须使用 pull request 才行( github 会保证合并无冲突,有冲突自己 resolve ),而且必须要 review 通过才行,任何人都没有权限直接合。
    2. 所有 pr 要求代码量改动在 100 行之内,方便 review,一般 30 行左右最佳。
    3. 把所有的任务无限拆小,越小越好,不停地分解到一个几十行代码的级别。
    4. 集成 ci 测试,测试不过不 review 不能 merge,github 是可以设置的,和 circleci 集成很好。
    5. **如果不遵守以上的,你干嘛还用 git 啊,大家直接改 ftp 的文件不得了,不按照流程走一切工具和方法论都无用。**
    swulling
        39
    swulling  
       2018-01-24 00:23:24 +08:00 via iPhone   ❤️ 2
    配置 push 只允许 fast forward,如果出现冲突,由提交代码的人自行解决,不解决无法合入

    简单讲,谁的代码先入库,其他人就得解决冲突。
    last
        40
    last  
       2018-01-24 00:27:18 +08:00 via Android
    祝你好运哈哈,我期末作业就四人的代码都弄得头疼
    zhx1991
        41
    zhx1991  
       2018-01-24 00:28:13 +08:00
    定期的把主分支往自己分支上合, 防止差太远.
    iyaozhen
        42
    iyaozhen  
       2018-01-24 00:30:04 +08:00 via Android   ❤️ 1
    我们是分支开发主干上线。

    大家都在自己的主干开发,提测前先把主干的代码合到分支,上线前分支再提合到主干
    alexapollo
        43
    alexapollo  
       2018-01-24 01:18:20 +08:00
    最简单有效的开发准则:
    人数较少,项目不大,且人员精良程度较高,可以只有 master 和 dev 分支,尽量避免分支之间的切换
    msg7086
        44
    msg7086  
       2018-01-24 08:08:19 +08:00
    这大概是把 Git 当成 SVN 在用了。
    miketeam
        45
    miketeam  
    OP
       2018-01-24 09:18:04 +08:00
    @alexapollo 然而事实就是人数多,项目大,人员高中低都用,富有层次感。经常 2 个分支来回切。。。
    miketeam
        46
    miketeam  
    OP
       2018-01-24 09:19:26 +08:00
    @msg7086 应该是我平时太忙了,没有及时拉代码,等开发完了再拉。然后其他人代码也多,然后就悲剧了。
    dong3580
        47
    dong3580  
       2018-01-24 09:31:24 +08:00   ❤️ 2
    @miketeam
    同时多个人改一个文件必然会冲突,需要配合,细化模块然后分更小的小组开发,这样只要每个人都在改自己的那部分代码,一般不会有问题。
    lights
        48
    lights  
       2018-01-24 09:36:11 +08:00 via iPhone
    用 git,大家都遵循同一个 git 的 work flow
    SmiteChow
        49
    SmiteChow  
       2018-01-24 10:26:45 +08:00
    需求拆分问题
    miketeam
        50
    miketeam  
    OP
       2018-01-24 12:00:05 +08:00 via iPhone
    和需求拆分粒度好像没关系。主要是先前写的太挫了。不敢改,因为每 50 行代码要自己设计 3 个测试用例。完全就是一项体力活。改完了还要一个个汇报。心力憔悴啊
    BBCCBB
        51
    BBCCBB  
       2018-01-24 12:19:04 +08:00
    gitflow 对合并代码也不友好,

    github flow 是最吼的~

    就是提 pull request 这种方式是最吼的.
    miketeam
        52
    miketeam  
    OP
       2018-01-24 12:39:56 +08:00 via iPhone
    不能永 GitHub 怎么办?
    mars0prince
        53
    mars0prince  
       2018-01-24 12:58:41 +08:00   ❤️ 1
    最简单的就是每天同步 master,其他任何方法都不靠谱,你落后主分支几百个版本,神仙也帮不了你
    iamsk
        54
    iamsk  
       2018-01-24 12:59:55 +08:00   ❤️ 1
    迭代时间短一些,功能小一点。
    yuankui
        55
    yuankui  
       2018-01-24 13:11:35 +08:00
    项目启动的时候从 master 拉一个 feature 分支
    然后你们项目成员基于这个 feature 分支开发, 开发的方式是从这个 feateure 分支拉新的分支,然后后定期把"相对稳定的"代码合到 feature 分支, 保持 feature 分支与你们每个月的分支都是相对实时的.
    这样就不会有最后合代码的问题了.

    话说回来, 合代码是日常的事, 而不是最后 的事.
    zhangyouming
        56
    zhangyouming  
       2018-01-24 13:14:08 +08:00
    推荐一个工具 beyond compare 。用了很久了。
    AsisA
        57
    AsisA  
       2018-01-24 13:22:23 +08:00 via Android
    master 分支+dev 分支,master 分支设置 owner,然后大家每人从 dev 分支上开自己的分支。

    平时大家往 dev 分支合并自己的分支,owner 定期把 dev 分支往 master 分支合并,如果不怕麻烦还可以加上 reviewer

    分工的时候也尽量每人做不同的部分,比如按照功能模块拆分
    wizardoz
        58
    wizardoz  
       2018-01-24 13:29:54 +08:00
    楼主生怕把别人的代码覆盖了,所以熬夜加班比较代码。
    当楼主看完最后一行确定无误运行 push 的时候,git 提示,你的本地代码不是最新,请更新到最新再进行提交!
    楼主心中一万只羊驼奔腾而过。在对比代码的几个小时中别人又上传了新的代码。
    一切从头开始……
    xloger
        59
    xloger  
       2018-01-24 13:30:50 +08:00
    我们是这样的,线上版在 master 分支,开发版在 dev 分支,然后每次一个人或几个人要开发某新功能时就在 dev 上切一个分支出来,开发完毕后 merge。基本没遇到落后几百个分支没法合并的问题。 [但是我隐约记得这样好像会导致这些分支的 commit 信息丢失?
    scofieldpeng
        60
    scofieldpeng  
       2018-01-24 13:35:17 +08:00
    用 git 那么久就没有出现过你的这些问题,很明显是你们 git 工作流,然后你们自己也不按照规则玩导致的,最后套用 v 站经典话术:要么忍,要么滚
    zhangsen1992
        61
    zhangsen1992  
       2018-01-24 13:36:28 +08:00
    每次 变更完立马 commit merge 别人再 pull 否则攒一堆冲突
    contmonad
        62
    contmonad  
       2018-01-24 13:46:32 +08:00 via iPhone
    用一些新出的更好的工具。关键词:patch-based VSC, semantic merge
    lwldcr
        63
    lwldcr  
       2018-01-24 13:48:35 +08:00
    每天先 pull --rebase, 再开始干活

    另外 代码如果拆分的好的话 单个文件只有 2、3 个人需要修改它 这样出现冲突也好解决一些
    ittianyu
        64
    ittianyu  
       2018-01-24 13:48:59 +08:00
    后端:微服务(一人负责几个项目)
    移动端:分模块(一人负责几个模块)
    前端:有请下面的大神来回答
    firefox12
        65
    firefox12  
       2018-01-24 13:53:52 +08:00 via iPhone
    很好办的 gerrit 每个人 gerrit 提交 ci 过了再提交,有冲突了 自己打回去重新做。rebase 了 编不过了 你来负责。总之先进去的一定是有优势的,后进去的 需要解决冲突,这个永远不能避免
    ai277014717
        66
    ai277014717  
       2018-01-24 13:54:39 +08:00
    根据模块分工,然后单元测试。先提交先走人。
    miketeam
        67
    miketeam  
    OP
       2018-01-24 13:56:04 +08:00 via iPhone
    就是用 beyond compare
    tairan2006
        68
    tairan2006  
       2018-01-24 13:56:31 +08:00
    git flow,定期合并
    ai277014717
        69
    ai277014717  
       2018-01-24 13:56:47 +08:00
    每次小版本结束就 merge 到 master 上然后开一个新的 develop-1.1xx 分支,大家在上面开发。
    miketeam
        70
    miketeam  
    OP
       2018-01-24 13:57:05 +08:00 via iPhone
    也正是用 gerrit ……
    scriptB0y
        71
    scriptB0y  
       2018-01-24 14:15:02 +08:00
    能往主分支合并代码的不应该只有 develop 分支和紧急的 hotfix 分支吗?不然区分主分支和 develop 还有什么意义?
    miketeam
        72
    miketeam  
    OP
       2018-01-24 14:21:20 +08:00 via iPhone
    @scriptB0y
    情况是:主管让我们在 develop 分支开发验证好没问题,然后自己去理清代码上传到 master 分支…
    banksiae
        73
    banksiae  
       2018-01-24 15:01:31 +08:00
    应该是分支没开对,各种分支合并的操作流程出问题了
    precisi0nux
        74
    precisi0nux  
       2018-01-24 16:28:10 +08:00
    借助工具吧,比如 jet brains 有些有冲突的代码可以智能合并,完了自己再检查一下就好了,能省不少事。
    pkookp8
        75
    pkookp8  
       2018-01-24 16:44:22 +08:00 via Android
    复杂的代码先合,简单的代码后合
    没事就把别的分支的代码合到自己分之上
    Alex6
        76
    Alex6  
       2018-01-24 16:52:16 +08:00
    楼上说的都挺好的,比如任务拆分,禁止直接推送 develop,master 等。
    建议你们小团队可以搞这样一个习俗,不管什么分支代码,只要在该项目内,比如是拉出的 feature 开发分支,那么保持提交点是一条直线,谁要是玩花了,请客喝水吃零食!
    至于 feature 分支合到 develop 上冲突很多,那显然是模块任务划分不清,或者是需求不明,很多人在同时在改同一个地方。那是组织需求的问题了,这是属于是做不做。而代码的维护和管理是怎么做。
    0Kelvin
        77
    0Kelvin  
       2018-01-24 16:53:15 +08:00
    我只要改完一块东西必然提交,怕自己这工作的破电脑忽然哪天就跪了。
    nekoyaki
        78
    nekoyaki  
       2018-01-24 16:55:39 +08:00
    要么是你们自己工作流程的问题,要么是把 git 当 svn 用了……
    sampeng
        79
    sampeng  
       2018-01-24 17:29:04 +08:00
    1.模块化不够好。改一处要动其他地方
    2.每日提交合并。你需要一根假 master 分支,对,就是测试分支。这个分支和 master 分支是时刻同步的,最少基线是同步。每日提交合并到这根分支上来。如果有测试,测试应该在这根分支上做测试。难道你们在各自的子分支上测试?会累死的。。ok,测试完毕。可以上线了。一个 merge 就完事了。根本不可能有冲突。要冲突也在每日提交的时候解决了。每日提交的时候,开发分支需要 rebase 合并好了的结果。然后接着干。
    sampeng
        80
    sampeng  
       2018-01-24 17:30:38 +08:00   ❤️ 1
    当然,我实际的使用场景来看。。小于 5 个人压根没这么麻烦。。模块化做好后,没人 commit 也不会冲突。一根线就够了。。其他都是自己折腾自己
    romisanic
        81
    romisanic  
       2018-01-24 19:52:36 +08:00
    每天开始开发前,合并一次主干代码,晚上下班前,合并一次主干代码
    miketeam
        82
    miketeam  
    OP
       2018-01-24 20:37:41 +08:00 via iPhone
    已经记下了,一个个试一下,看以后会不会好一点
    ckylolo
        83
    ckylolo  
       2018-01-24 20:45:05 +08:00   ❤️ 1
    吃尽苦头,明白是流程规范问题,尝试一下 git 最佳实践吧,具体参考
    [link]( http://blog.jobbole.com/109466/)

    重点两个:
    ##理解这张图
    ![image]( http://legendtkl.com/img/uploads/2016/git-model.png)

    ##记住合适的提交时机
    lvxg
        84
    lvxg  
       2018-01-27 22:14:14 +08:00
    我们也 2 个分支,有一次和运维合了一宿 都合懵逼了
    miketeam
        85
    miketeam  
    OP
       2018-01-27 22:27:19 +08:00 via iPhone
    我心里有阴影合的…
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   4310 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 05:31 · PVG 13:31 · LAX 22:31 · JFK 01:31
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.