V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
codetnci
V2EX  ›  职场话题

因为 git pull 和同事闹僵了。

  •  
  •   codetnci · 2019-05-18 01:48:08 +08:00 · 15152 次点击
    这是一个创建于 1776 天前的主题,其中的信息可能已经有所发展或是发生改变。

    同事:(idea)你要先点击项目目录,右键-git-commit directory,然后右键-git-pull。理由,避免冲突,避免覆盖代码。

    我: 经常是没有 commit 就 pull,而且不是用(idea)右键项目根目录来 pull,有时是用(idea)vcs 窗口中的命令行(git pull)来 pull,有时用工具栏上的 pull 按钮。理由右键项目使用 git 效率慢

    被他一直说,因为我屡教不改,最后他发脾气了。

    我没有 commit 就 pull 的理由如下。 1 我这边只是改动属于我自己功能的模块,代码基本在自己的 service 类里,base,commom 等方法我基本也不会去动,所以大概率不会和他的代码冲突,或者要 pull 的代码有冲突。 2 有时我代码一点改动都没有,就只剩下一两个文件,一个是我本地的 java test 类,一个是自己新建的 bean 类。我就没有 commit 直接 pull。 3 我觉得没改好的代码不好随便 commit,而且他的操作是 commit directory,(不是什么东西都 commit 上去了?) 4 (我心里想)就算是冲突或者覆盖也只会影响到我,也不会影响其他人啊?即使我的代码被覆盖或者出现冲突了,我可以回退啊(所以我心里潜台词的就是我不 commit 就更新关你毛事啊)

    和同事冲突的原因: 他说他这样做避免代码冲突和覆盖,我一直不照着他说的方法去做(理由在上面),教多几次后他就受不了发脾气了。

    另外: 1 他 commit 很随意,我看到他把 idea 文件夹下面的一个文件也提交了。 2 另外一个同事也很随意,很经常 git add . 然后 git commit -msg "code" 。 3 我看到过不知道是谁把 log 文件也提交上去了,更新冲突,我把我本地的 log 文件删了才 pull 成功,我在想谁那么有才啊? 4 我个人对 git 命令行不太熟,用的最多的就是 git clone。其他都是用 sourcetree 来提交和更新的。有点讨厌命令行,特别是 add 文件的时候。所以也不怎么研究命令行。 5 我在上家公司的基本上是各做各的,所以冲突不多,要合作的时候也是在同一个分支的基础上建立一个子分支,所以冲突不多。 6 我现在的情况是我们所有开发全在一个分支下工作,也没有创建个人的子分支。

    想让各位评论评论,不求对错。只想知道你们的看法,求 git 正确使用方法

    80 条回复    2019-05-20 13:18:39 +08:00
    impl
        1
    impl  
       2019-05-18 04:54:02 +08:00 via Android   ❤️ 4
    换 SVN
    fhsan
        2
    fhsan  
       2019-05-18 06:13:28 +08:00
    我的操作流程 branch pull status diff commit push,我遇到的基本上都是不怎么会用 git 的人。
    iamdqncoder
        3
    iamdqncoder  
       2019-05-18 06:56:58 +08:00 via Android   ❤️ 7
    emm。。折中一下 git stash 然后 pull 然后 git stash pop
    mikicomo
        4
    mikicomo  
       2019-05-18 07:13:32 +08:00 via Android
    我是 commit pull push 的,有时候不想提交就先 stash,有时候真的觉得 commit 比较多难看了,就 rebase 一下,至于 idea 文件夹的问题…可以用 gitignore 解决
    precisi0nux
        5
    precisi0nux  
       2019-05-18 07:21:46 +08:00 via Android   ❤️ 10
    你这已经是好的了,既然用了 jb 系,就用 jb 系的套路来,根本不用 pull,直接 commit 后 push,万一有 conflict 的话会提示你然后你再 resolve 之后他会自动再 push,不要太方便。不要把用 cli 的思想带到 IDE 来。
    WoodenTea
        6
    WoodenTea  
       2019-05-18 07:31:55 +08:00
    git 常用的命令没几个,看一下教程,自己动动手就能理解。
    把不需要添加到仓库的文件添加到.gitignore,可以解决不需要的文件造成的冲突。
    不要有问题就说队友这不对哪不好,方法总比问题多。
    nicevar
        7
    nicevar  
       2019-05-18 07:36:40 +08:00 via Android   ❤️ 39
    说难听点你们这一群人都是瞎搞,技术团队水平堪忧,都在一个分支上操作能不乱吗,可以先锁死 master,按功能或者需求进行分支创建,完成之后先 merge 某个稳定的分支或者 master,这样谁的屁股不干净就自己擦,再由一个主要负责人进行 MR 审核
    wpzero
        8
    wpzero  
       2019-05-18 07:37:38 +08:00 via iPhone   ❤️ 2
    同事的操作肯定不规范了,你们开发都在一个分支? git 的好处就是分支轻量,如果不同分支,我感觉 pull 没关系的
    dangyuluo
        9
    dangyuluo  
       2019-05-18 07:39:56 +08:00
    纯属瞎开发,团队效率 -80%
    liaojl
        10
    liaojl  
       2019-05-18 07:56:27 +08:00 via Android   ❤️ 1
    没 commit 之前如果不 stash 的话 pull 不了的吧,如果 stash 了,pull 完之后 stash pop 有冲突的话,还是要 merge conflict 的。所以先 commit 再 pull,和先 pull 再 commit 按理来说应该是一样的,该有冲突的还是有冲突,唯一的区别可能是 stash pop 的冲突不会产生一个新的 commit。PS.我上一家公司也是团队 10 多个人在同一分支开发,经常有人代码编译都过不了就提交了,其他人一 pull 就 gg 了。
    dengtongcai
        11
    dengtongcai  
       2019-05-18 07:58:58 +08:00 via iPhone
    一人一个分支
    kmahyyg
        12
    kmahyyg  
       2019-05-18 08:00:57 +08:00
    都用 JB 了,还折腾这么多,JB IDE 很友好的,你两的用好 gitignore 就行。
    个人习惯:pull commit push
    swulling
        13
    swulling  
       2019-05-18 08:12:40 +08:00 via iPhone   ❤️ 5
    都是惯的,为了避免瞎 commit

    我们团队直接开启 fast forward Only,disable merge commit,大家都在 develop 分支上开发。

    老老实实 rebase,解决冲突后提交,有冲突就根本提交不了。最后出来的历史就是一个线性历史,项目有没有多大,搞那么复杂干嘛。

    另外再做好 code Review,保证每个 commit 都写的不错就可以了。
    chengluyu
        14
    chengluyu  
       2019-05-18 08:19:54 +08:00   ❤️ 9
    为什么楼上都在说是工具的问题,不同 git 除了 diff 实现可能不同外,其余都是一样的。让楼主换别的工具,一切照旧,该打架还是要打架。

    问题根本难道不是楼主团队根本不会用 git 吗?太多槽点了。

    1. log 文件不写在 gitignore 里?
    2. 每个 fix 和 feature 直接 commit 到 master,这样不出错才怪,不做单元测试和整合测试了?
    3. 没有 commit message guideline ?你们同事写个「 code 」就能当 commit message 了?

    另外关于楼主团队做事的一些槽点:

    1. 不是你想不想学 CLI,你用了你就该学。
    2. 前几次和同事冲突的时候,就该想怎么解决这个问题了,就算个人解决不了,也该 push 老大去解决。
    trait
        15
    trait  
       2019-05-18 08:26:40 +08:00 via iPhone   ❤️ 6
    楼上把我惊呆了,这跟 cli 习惯有个毛的关系,用 jb 就必须按 ide 得来???团队连个开发流程都没有
    Felldeadbird
        16
    Felldeadbird  
       2019-05-18 08:37:56 +08:00 via iPhone
    不是一人一个分支吗?
    3CH0
        17
    3CH0  
       2019-05-18 08:38:19 +08:00
    貌似 JB pull 有冲突的时候 会自动 stash
    wengjin456123
        18
    wengjin456123  
       2019-05-18 08:43:13 +08:00 via Android
    你们不发 pr 么?合并的时候觉得代码影响了直接不给通过就行了啊
    keepeye
        19
    keepeye  
       2019-05-18 08:43:14 +08:00   ❤️ 1
    谁创建的项目 gitignore 都没弄好?连 .idea .vscode 这类目录还有日志要忽略是基本常识吧..

    还有 git pull 覆盖的是自己的代码,跟他们有啥关系,冲突了也是你自己解决啊,你那些同事是把 git 当 svn 用了吗?

    最后,自己尽量在自己的分支里开发,就不用这么扯皮了。
    wengjin456123
        20
    wengjin456123  
       2019-05-18 08:45:38 +08:00 via Android
    每个人 fork 主仓库,在自己 fork 的仓库开发然后提交 pr,邀请负责人和同事 code review,通过就合并主仓库 master 分支
    hhecoder
        21
    hhecoder  
       2019-05-18 08:46:14 +08:00 via Android
    你们每个人的操作都有问题,一点不按 git flow 来,3 个人开发早就该出问题了。
    wengjin456123
        22
    wengjin456123  
       2019-05-18 08:46:33 +08:00 via Android
    你们需要拟定个开发流程,吵架没用
    fuxinya
        23
    fuxinya  
       2019-05-18 08:53:18 +08:00 via Android   ❤️ 1
    我这习惯是 Ctrl T 更新,Ctrl K 提交,自动 stash,有冲突手动解决,坚决不自动 merge
    sansanhehe
        24
    sansanhehe  
       2019-05-18 08:57:01 +08:00 via Android
    都挺不规范
    ccpp132
        25
    ccpp132  
       2019-05-18 08:57:43 +08:00 via Android
    加个 code review 就完事,自己机器上还怎么搞怎么搞
    snappyone
        26
    snappyone  
       2019-05-18 09:02:32 +08:00
    多分支加 pr 跟 code review,我们这多提交一个空白行 pr 都过不了
    ferock
        27
    ferock  
       2019-05-18 09:10:38 +08:00 via iPhone
    一个需求一个分支…不就完了
    deepdark
        28
    deepdark  
       2019-05-18 09:35:32 +08:00 via Android
    实在不行就一人一分支吧,隔几天 merge 一次
    henryhu
        29
    henryhu  
       2019-05-18 10:08:23 +08:00
    分支、rebase 用起来
    learnshare
        30
    learnshare  
       2019-05-18 10:15:33 +08:00
    明明有那么多值得争吵的东西,你们偏偏吵些没用的
    bjjvvv
        31
    bjjvvv  
       2019-05-18 10:32:08 +08:00 via Android
    先 commit 永远是最保险的,反正没提交到远程,随时可以改
    taotaodaddy
        32
    taotaodaddy  
       2019-05-18 10:36:38 +08:00 via Android
    你们的技术负责人在哪里
    watzds
        33
    watzds  
       2019-05-18 11:10:54 +08:00 via Android
    鼓励随时 Commit,当然前提是要有自己的分支
    KuroNekoFan
        34
    KuroNekoFan  
       2019-05-18 11:24:08 +08:00   ❤️ 1
    为什么会覆盖,难道你俩都是那种看到 conflict 然后 push -f 的人吗
    Perry
        35
    Perry  
       2019-05-18 11:30:54 +08:00   ❤️ 1
    这个不仅仅是会不会用 git 或者团队开发流程的问题,感觉同事之间已经很难好好沟通或者达成共识了。
    建议让整个团队网上搜一下各种 git workflow 学习一下,确保所有人都会用之后再决定一个每个人都要遵守的 git workflow,推荐用 husky 来规范操作。
    linchengzzz
        36
    linchengzzz  
       2019-05-18 11:33:41 +08:00
    使用方法

    git stash
    git pull --rebase origin <branch>
    git stash pop

    如果遇到冲突就解决冲突 = =
    pkookp8
        37
    pkookp8  
       2019-05-18 12:00:36 +08:00 via Android
    还是有点理由的,如果 pull 有冲突,不小心误操作把代码删了你得重新写
    commit 之后就有历史记录了,即使删了文件或者有人 push -f 覆盖了你的代码也能回退
    yoshiyuki
        38
    yoshiyuki  
       2019-05-18 12:12:53 +08:00   ❤️ 1
    没有 git flow,没有规范,很显然你们没有 tech leader 或者他是吃干饭的
    kuyuzhiqi
        39
    kuyuzhiqi  
       2019-05-18 12:30:18 +08:00 via iPhone
    默默问一下,这种情况下你们会选择离职还是留?
    newtype0092
        40
    newtype0092  
       2019-05-18 14:06:24 +08:00
    看你们吵了一堆没用的,还是 1L 说的靠谱,git 不会用瞎 JR 操作各种问题太多了。。。
    hanxiV2EX
        41
    hanxiV2EX  
       2019-05-18 14:16:30 +08:00 via Android   ❤️ 1
    都用 git 了,还舍不得建立分支开发?
    GeruzoniAnsasu
        42
    GeruzoniAnsasu  
       2019-05-18 15:27:14 +08:00
    1L + 1

    换 svn
    xuanbg
        43
    xuanbg  
       2019-05-18 15:37:11 +08:00
    不要 rebase,一事一 commit 比较好。一般只有在需要联调才 pull 和 push
    lionseun
        44
    lionseun  
       2019-05-18 15:47:37 +08:00 via Android
    感觉是毫无意义的争论
    bigjack
        45
    bigjack  
       2019-05-18 16:14:57 +08:00
    这种事也值得生气
    winglight2016
        46
    winglight2016  
       2019-05-18 17:00:54 +08:00   ❤️ 1
    吵架都没吵到点子上,你们的团队应该统一去培训学习一下 git 最佳实践吧。具体怎么操作是需要统一一下的,这样不是谁对谁错,而是减少不必要的问题——特别是难以解决的问题。

    lz 提到“大概率”如何如何,你要知道一旦发生小概率事件,那会让你记一辈子,git 虽然很稳定,但不是没有出错的时候,一旦出错,commit 是最基本的操作单位,所以没事儿 commit 一下是很好的习惯——绝对不是做完一个任务才 commit。
    hirasawayui
        47
    hirasawayui  
       2019-05-18 17:20:44 +08:00
    打起来打起来,
    danjk159
        48
    danjk159  
       2019-05-18 17:26:33 +08:00
    还是 svn 吧
    uxstone
        49
    uxstone  
       2019-05-18 18:07:30 +08:00
    以功能模块或修改 bug 为一次 commit, 一般一天下来能有个 5 到 6 个 commit

    1.要 commit 前先 pull
    2.commit 后就 push 远程
    3.push 完, 通知其他人 pull 下代码

    pull 的时候有冲突 能自动 merge 就 merge, 有冲突就 revert

    还有没事别瞎 commit , commit 的信息要写清楚都干了啥
    我就想说都这样做了还能有啥冲突?
    demonzoo
        50
    demonzoo  
       2019-05-18 18:19:07 +08:00
    我也是先 pull 再 commit push,如果有冲突的话直接 JB 里面 resolve 一下啊,很容易。。。
    另外,如果互相做的功能不太相关,可以各自建 feature branch,然后最后往主分支里面 merge 就好。
    sunocean
        51
    sunocean  
       2019-05-18 19:52:33 +08:00
    开个会吧, 规范流程. 这个没必要吵架.
    Linxing
        52
    Linxing  
       2019-05-18 20:15:58 +08:00
    很好奇你们为什么会有这个问题 不是都是自己一个分支吗 最多 pull 下 rebase 不就好了
    Lision
        53
    Lision  
       2019-05-18 20:17:30 +08:00
    git pull --rebase
    tyrealgray
        54
    tyrealgray  
       2019-05-18 20:20:47 +08:00 via Android   ❤️ 1
    你们不用分支的吗?争这么半天 git 的高效用法都没掌握
    weizhxa
        55
    weizhxa  
       2019-05-18 21:19:53 +08:00   ❤️ 1
    自己回下吧:
    1、冲突原因:为什么产生冲突?如果说代码修改模块并不一样的话,那么:
    a、代码的格式化不一致,这个是最容易导致大面积的 pull 下来红的原因,你们不知道有没有设置统一的代码格式化。
    b、对于公共类是最容易碰到冲突的原因,说句难听话,如果你的队友修改了公共类,你又在使用旧的公共类库,那么冲突也是无可避免,他更新了代码,自然要冲突。
    2、冲突解决:
    a、好的习惯。
    I、拉取习惯。拉取之前先看下队友的修改内容,来决定是否要完全下载,下载对于自己有什么问题,怎么解决,是否有必要这个版本下载。
    II、当你修改了公共类时,最好向队友说一下,平时注意关系,多谦虚。公共类最好只扩展而不要修改原来的接口。
    b、提交前的测试,基于提交的最新代码测试通过。如此即使最终的裁判,责任也不在于你。
    3、后话
    1、其实每个人因为性格的不一样,导致同一件事看法会有许多不同,那对于自己来说,尽量和团队成员相处好。当工作时候的冲突无可避免时,最好先私底下商量好,然后走公司路线。建议,即使工作冲突再大,也要保持私下关系良好。
    2、一个 git 是否开分支或者不开分支,如何开分支,如何提交合并,如何保证最终的冲突最少,产品最可靠,亲身经历过,11 个人 5 种想法的人路过。
    cqy2016
        56
    cqy2016  
       2019-05-18 21:28:24 +08:00   ❤️ 1
    这根性格有毛关系,求求你们先学下 git 怎么用吧。。。
    sdushn
        57
    sdushn  
       2019-05-18 21:53:28 +08:00 via Android   ❤️ 1
    @nicevar 😂😂没错啊,我也一脸懵逼,为啥都在一个分支上开发
    anonym233
        58
    anonym233  
       2019-05-18 22:02:50 +08:00   ❤️ 1
    说实话,感觉你们争论的点不对,也没有把 git 的优势发挥出来。楼上说的很对,git 常用的命令就那几个,我的同事不擅长命令行的用的是 github desktop。我们项目是没有经过测试的稳定代码是不能随便推 master 的,代码冲突很正常,可以使用 vscode 进行解决冲突很方便。建议了解一下 git,毕竟 git 很强大,我用熟以后才后悔为什么没早点学 git(第一家公司是 svn).
    whypool
        59
    whypool  
       2019-05-18 22:09:54 +08:00   ❤️ 1
    git reset --hard --hard
    icylogic
        60
    icylogic  
       2019-05-18 22:17:01 +08:00   ❤️ 1
    你本地怎么弄关别人什么事,只要你 push 不带 force 上去的东西保证正常不就好了。

    你自己因为 pull 被覆盖了东西,是你自己的麻烦啊,你自己负责解决。只要你和远程有真正的冲突(这件事应该很少发生,应该通过流程和分支避免,的确每个团队都会有自己的习惯和解决方案,各有优劣,但放着不管所有人都在一个分支上干活是最糟糕的那种),总之你得在 pull 之前某个时间节点解决它,只不过先 commit 是让你 pull 的时候就强制你解决而已。

    而且为啥你同事会知道你每次 pull 的时候发生了什么,他每天盯着你电脑看了?

    我个人习惯是,准备解决冲突前(只要我和远程 diverge 了我就默认会有冲突),先 fetch+status 一下,有个心理预期。
    yhxx
        61
    yhxx  
       2019-05-18 22:21:20 +08:00
    先不说什么团队规范,你怎么 pull 关他什么事。。。为什么他能发现你 pull 的方式不合他心意?
    又不是 push
    Cbdy
        62
    Cbdy  
       2019-05-18 22:39:26 +08:00 via Android
    提交代码发 pr 多简单
    yidinghe
        63
    yidinghe  
       2019-05-18 23:11:05 +08:00 via Android
    先 pull 再 commit 这是有礼貌的表现,就是不管什么锅我先背了,冲突我来处理。
    liukanshan
        64
    liukanshan  
       2019-05-19 00:07:09 +08:00
    这种情况还和别人理论什么 你去争你就是傻逼 他说的一切都对 也麻烦不要去纠正。
    exonuclease
        65
    exonuclease  
       2019-05-19 00:31:14 +08:00 via iPhone
    先 git stash 再 git pull
    oneisall8955
        66
    oneisall8955  
       2019-05-19 01:35:13 +08:00 via Android
    git 不太会用,用 idea 只是简单的 Ctrl K 选 push,自动 merge,有冲突手动合并,最后自动 stash 提交到主分支。。。
    passerbytiny
        67
    passerbytiny  
       2019-05-19 08:25:32 +08:00
    恕我愚钝,不知道为什么先 commit 会避免冲突,要不楼主把同事叫过来问一下。
    @bjjvvv #28
    @watzds #30
    @pkookp8 #33
    你们 commit 的信息怎么写?还是你们觉得修改历史后再 push -force 更不容易出问题。
    kran
        68
    kran  
       2019-05-19 09:27:11 +08:00 via Android
    @passerbytiny 并不能避免冲突,昨天看这个帖子我想的是,他同事说的可能不是主贴上的问题
    zqx
        69
    zqx  
       2019-05-19 09:55:05 +08:00 via Android
    如果用 git 不用 git 最佳实践,不如不用 git,换 svn
    bjjvvv
        70
    bjjvvv  
       2019-05-19 11:04:12 +08:00
    @passerbytiny #67 提交了 commit 你的代码才算进了 git 的仓库。你合并代码也好,其他什么切分支也好,反正遇到到了什么问题,你想回滚的时候,发现自己代码根本就没被 git 记录就蛋疼了。
    siteshen
        71
    siteshen  
       2019-05-19 11:58:13 +08:00
    只要你不搞坏别人的东西,怎么操作都没问题。如果用自己的流程,搞出问题(或者要麻烦别人),就别怪别人发飙。
    pkookp8
        72
    pkookp8  
       2019-05-19 12:33:53 +08:00 via Android   ❤️ 1
    @passerbytiny 我没说 commit 可以避免冲突,我是说我的意思是 commit 之后代码就被 git 管理了,即使有什么操作导致你的代码丢失,只要不是整个仓库被删,都能恢复。冲突也可以在 commit+pull 之后解决
    反之如果先 pull,解决冲突过程出了点意外,代码可能就没了。所以对方的想法并不是没有道理的
    楼上很多人说可以用 git 的分支开发,我想说 svn 其实也支持分支开发模式,如今 svn 和 git 一样是差异存储。但是很多人认为 svn 一份分支就是一份存储,可能是以前的模式误导了吧。
    commit 信息怎么写: 你改什么写什么。一两句话简单描述一下就行了。反正我是不会用 code 或者 update 之类的一个单词的描述
    hellomsg
        73
    hellomsg  
       2019-05-19 13:44:44 +08:00
    发帖子的时间可以去练一练 git 怎么用
    du5t6reak
        74
    du5t6reak  
       2019-05-19 15:10:58 +08:00 via iPhone   ❤️ 1
    git add . 我也是醉了,在我们 team 这么玩儿要被骂死的,个人配置文件也 push 有病吧
    luozic
        75
    luozic  
       2019-05-19 15:59:49 +08:00 via iPhone   ❤️ 1
    找个 github flew 练习一下不就行了,三个都在哪胡搞,都还有理了。
    dNib9U2o8x
        76
    dNib9U2o8x  
       2019-05-19 16:25:42 +08:00
    建议你们使用更加强制化的流程, upstream/master 分支禁止 push,只允许从 pull request merge,这样你们本地愿意怎么玩就怎么玩
    moxiaonai
        77
    moxiaonai  
       2019-05-19 18:39:16 +08:00 via Android
    流程有问题,不是操作的问题
    corningsun
        78
    corningsun  
       2019-05-20 09:05:23 +08:00 via iPhone
    楼主是否 pull 后把别人的提交覆盖了?

    上你们 git 提交历史图吧,看结果才能让大家评理。
    bdnet
        79
    bdnet  
       2019-05-20 11:10:38 +08:00
    Gitflow、GitHub flow、Gitlab flow

    更重要的是约定一个开发流程吧,至于操作方式,不需要定这么死。有人喜欢点鼠标,有人喜欢命令行,还有人直接快捷方式搞定。
    l00t
        80
    l00t  
       2019-05-20 13:18:39 +08:00   ❤️ 1
    菜鸡互啄
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3310 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 63ms · UTC 13:32 · PVG 21:32 · LAX 06:32 · JFK 09:32
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.