因为 git pull 和同事闹僵了。

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2050 天前的主题，其中的信息可能已经有所发展或是发生改变。

同事:(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

2019-05-18 04:54:02 +08:00 via Android

换 SVN

fhsan

2019-05-18 06:13:28 +08:00

我的操作流程 branch pull status diff commit push，我遇到的基本上都是不怎么会用 git 的人。

iamdqncoder

2019-05-18 06:56:58 +08:00 via Android

emm。。折中一下 git stash 然后 pull 然后 git stash pop

mikicomo

2019-05-18 07:13:32 +08:00 via Android

我是 commit pull push 的，有时候不想提交就先 stash，有时候真的觉得 commit 比较多难看了，就 rebase 一下，至于 idea 文件夹的问题…可以用 gitignore 解决

precisi0nux

2019-05-18 07:21:46 +08:00 via Android

你这已经是好的了，既然用了 jb 系，就用 jb 系的套路来，根本不用 pull，直接 commit 后 push，万一有 conflict 的话会提示你然后你再 resolve 之后他会自动再 push，不要太方便。不要把用 cli 的思想带到 IDE 来。

WoodenTea

2019-05-18 07:31:55 +08:00

git 常用的命令没几个，看一下教程，自己动动手就能理解。
把不需要添加到仓库的文件添加到.gitignore，可以解决不需要的文件造成的冲突。
不要有问题就说队友这不对哪不好，方法总比问题多。

nicevar

2019-05-18 07:36:40 +08:00 via Android

说难听点你们这一群人都是瞎搞，技术团队水平堪忧，都在一个分支上操作能不乱吗，可以先锁死 master，按功能或者需求进行分支创建，完成之后先 merge 某个稳定的分支或者 master，这样谁的屁股不干净就自己擦，再由一个主要负责人进行 MR 审核

wpzero

2019-05-18 07:37:38 +08:00 via iPhone

同事的操作肯定不规范了，你们开发都在一个分支？ git 的好处就是分支轻量，如果不同分支，我感觉 pull 没关系的

dangyuluo

2019-05-18 07:39:56 +08:00

纯属瞎开发，团队效率 -80%

liaojl

2019-05-18 07:56:27 +08:00 via Android

没 commit 之前如果不 stash 的话 pull 不了的吧，如果 stash 了，pull 完之后 stash pop 有冲突的话，还是要 merge conflict 的。所以先 commit 再 pull，和先 pull 再 commit 按理来说应该是一样的，该有冲突的还是有冲突，唯一的区别可能是 stash pop 的冲突不会产生一个新的 commit。PS.我上一家公司也是团队 10 多个人在同一分支开发，经常有人代码编译都过不了就提交了，其他人一 pull 就 gg 了。

dengtongcai

2019-05-18 07:58:58 +08:00 via iPhone

一人一个分支

kmahyyg

2019-05-18 08:00:57 +08:00

都用 JB 了，还折腾这么多，JB IDE 很友好的，你两的用好 gitignore 就行。
个人习惯：pull commit push

swulling

2019-05-18 08:12:40 +08:00 via iPhone

都是惯的，为了避免瞎 commit

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

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

另外再做好 code Review，保证每个 commit 都写的不错就可以了。

chengluyu

2019-05-18 08:19:54 +08:00

为什么楼上都在说是工具的问题，不同 git 除了 diff 实现可能不同外，其余都是一样的。让楼主换别的工具，一切照旧，该打架还是要打架。

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

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

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

1. 不是你想不想学 CLI，你用了你就该学。
2. 前几次和同事冲突的时候，就该想怎么解决这个问题了，就算个人解决不了，也该 push 老大去解决。

trait

2019-05-18 08:26:40 +08:00 via iPhone

楼上把我惊呆了，这跟 cli 习惯有个毛的关系，用 jb 就必须按 ide 得来？？？团队连个开发流程都没有

Felldeadbird

2019-05-18 08:37:56 +08:00 via iPhone

不是一人一个分支吗？

3CH0

2019-05-18 08:38:19 +08:00

貌似 JB pull 有冲突的时候会自动 stash

wengjin456123

2019-05-18 08:43:13 +08:00 via Android

你们不发 pr 么？合并的时候觉得代码影响了直接不给通过就行了啊

keepeye

2019-05-18 08:43:14 +08:00

谁创建的项目 gitignore 都没弄好？连 .idea .vscode 这类目录还有日志要忽略是基本常识吧..

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

最后，自己尽量在自己的分支里开发，就不用这么扯皮了。

wengjin456123

2019-05-18 08:45:38 +08:00 via Android

每个人 fork 主仓库，在自己 fork 的仓库开发然后提交 pr，邀请负责人和同事 code review，通过就合并主仓库 master 分支

hhecoder

2019-05-18 08:46:14 +08:00 via Android

你们每个人的操作都有问题，一点不按 git flow 来，3 个人开发早就该出问题了。

wengjin456123

2019-05-18 08:46:33 +08:00 via Android

你们需要拟定个开发流程，吵架没用

fuxinya

2019-05-18 08:53:18 +08:00 via Android

我这习惯是 Ctrl T 更新，Ctrl K 提交，自动 stash，有冲突手动解决，坚决不自动 merge

sansanhehe

2019-05-18 08:57:01 +08:00 via Android

都挺不规范

ccpp132

2019-05-18 08:57:43 +08:00 via Android

加个 code review 就完事，自己机器上还怎么搞怎么搞

snappyone

2019-05-18 09:02:32 +08:00

多分支加 pr 跟 code review，我们这多提交一个空白行 pr 都过不了

ferock

2019-05-18 09:10:38 +08:00 via iPhone

一个需求一个分支…不就完了

deepdark

2019-05-18 09:35:32 +08:00 via Android

实在不行就一人一分支吧，隔几天 merge 一次

henryhu

2019-05-18 10:08:23 +08:00

分支、rebase 用起来

learnshare

2019-05-18 10:15:33 +08:00

明明有那么多值得争吵的东西，你们偏偏吵些没用的

bjjvvv

2019-05-18 10:32:08 +08:00 via Android

先 commit 永远是最保险的，反正没提交到远程，随时可以改

taotaodaddy

2019-05-18 10:36:38 +08:00 via Android

你们的技术负责人在哪里

watzds

2019-05-18 11:10:54 +08:00 via Android

鼓励随时 Commit，当然前提是要有自己的分支

KuroNekoFan

2019-05-18 11:24:08 +08:00

为什么会覆盖，难道你俩都是那种看到 conflict 然后 push -f 的人吗

Perry

2019-05-18 11:30:54 +08:00

这个不仅仅是会不会用 git 或者团队开发流程的问题，感觉同事之间已经很难好好沟通或者达成共识了。
建议让整个团队网上搜一下各种 git workflow 学习一下，确保所有人都会用之后再决定一个每个人都要遵守的 git workflow，推荐用 husky 来规范操作。

linchengzzz

2019-05-18 11:33:41 +08:00

使用方法

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

如果遇到冲突就解决冲突 = =

pkookp8

2019-05-18 12:00:36 +08:00 via Android

还是有点理由的，如果 pull 有冲突，不小心误操作把代码删了你得重新写
commit 之后就有历史记录了，即使删了文件或者有人 push -f 覆盖了你的代码也能回退

yoshiyuki

2019-05-18 12:12:53 +08:00

没有 git flow，没有规范，很显然你们没有 tech leader 或者他是吃干饭的

kuyuzhiqi

2019-05-18 12:30:18 +08:00 via iPhone

默默问一下，这种情况下你们会选择离职还是留？

newtype0092

2019-05-18 14:06:24 +08:00

看你们吵了一堆没用的，还是 1L 说的靠谱，git 不会用瞎 JR 操作各种问题太多了。。。

hanxiV2EX

2019-05-18 14:16:30 +08:00 via Android

都用 git 了，还舍不得建立分支开发？

GeruzoniAnsasu

2019-05-18 15:27:14 +08:00

1L + 1

换 svn

xuanbg

2019-05-18 15:37:11 +08:00

不要 rebase，一事一 commit 比较好。一般只有在需要联调才 pull 和 push

lionseun

2019-05-18 15:47:37 +08:00 via Android

感觉是毫无意义的争论

bigjack

2019-05-18 16:14:57 +08:00

这种事也值得生气

winglight2016

2019-05-18 17:00:54 +08:00

吵架都没吵到点子上，你们的团队应该统一去培训学习一下 git 最佳实践吧。具体怎么操作是需要统一一下的，这样不是谁对谁错，而是减少不必要的问题——特别是难以解决的问题。

lz 提到“大概率”如何如何，你要知道一旦发生小概率事件，那会让你记一辈子，git 虽然很稳定，但不是没有出错的时候，一旦出错，commit 是最基本的操作单位，所以没事儿 commit 一下是很好的习惯——绝对不是做完一个任务才 commit。

hirasawayui

2019-05-18 17:20:44 +08:00

打起来打起来，

danjk159

2019-05-18 17:26:33 +08:00

还是 svn 吧

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

2019-05-18 18:19:07 +08:00

我也是先 pull 再 commit push，如果有冲突的话直接 JB 里面 resolve 一下啊，很容易。。。
另外，如果互相做的功能不太相关，可以各自建 feature branch，然后最后往主分支里面 merge 就好。

sunocean

2019-05-18 19:52:33 +08:00

开个会吧, 规范流程. 这个没必要吵架.

Linxing

2019-05-18 20:15:58 +08:00

很好奇你们为什么会有这个问题不是都是自己一个分支吗最多 pull 下 rebase 不就好了

Lision

2019-05-18 20:17:30 +08:00

git pull --rebase

tyrealgray

2019-05-18 20:20:47 +08:00 via Android

你们不用分支的吗？争这么半天 git 的高效用法都没掌握

weizhxa

2019-05-18 21:19:53 +08:00

自己回下吧：
1、冲突原因：为什么产生冲突？如果说代码修改模块并不一样的话，那么：
a、代码的格式化不一致，这个是最容易导致大面积的 pull 下来红的原因，你们不知道有没有设置统一的代码格式化。
b、对于公共类是最容易碰到冲突的原因，说句难听话，如果你的队友修改了公共类，你又在使用旧的公共类库，那么冲突也是无可避免，他更新了代码，自然要冲突。
2、冲突解决：
a、好的习惯。
I、拉取习惯。拉取之前先看下队友的修改内容，来决定是否要完全下载，下载对于自己有什么问题，怎么解决，是否有必要这个版本下载。
II、当你修改了公共类时，最好向队友说一下，平时注意关系，多谦虚。公共类最好只扩展而不要修改原来的接口。
b、提交前的测试，基于提交的最新代码测试通过。如此即使最终的裁判，责任也不在于你。
3、后话
1、其实每个人因为性格的不一样，导致同一件事看法会有许多不同，那对于自己来说，尽量和团队成员相处好。当工作时候的冲突无可避免时，最好先私底下商量好，然后走公司路线。建议，即使工作冲突再大，也要保持私下关系良好。
2、一个 git 是否开分支或者不开分支，如何开分支，如何提交合并，如何保证最终的冲突最少，产品最可靠，亲身经历过，11 个人 5 种想法的人路过。

cqy2016

2019-05-18 21:28:24 +08:00

这根性格有毛关系，求求你们先学下 git 怎么用吧。。。

sdushn

2019-05-18 21:53:28 +08:00 via Android

@nicevar 😂😂没错啊，我也一脸懵逼，为啥都在一个分支上开发

anonym233

2019-05-18 22:02:50 +08:00

说实话，感觉你们争论的点不对，也没有把 git 的优势发挥出来。楼上说的很对，git 常用的命令就那几个，我的同事不擅长命令行的用的是 github desktop。我们项目是没有经过测试的稳定代码是不能随便推 master 的，代码冲突很正常，可以使用 vscode 进行解决冲突很方便。建议了解一下 git，毕竟 git 很强大，我用熟以后才后悔为什么没早点学 git(第一家公司是 svn).

whypool

2019-05-18 22:09:54 +08:00

git reset --hard --hard

icylogic

2019-05-18 22:17:01 +08:00

你本地怎么弄关别人什么事，只要你 push 不带 force 上去的东西保证正常不就好了。

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

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

我个人习惯是，准备解决冲突前（只要我和远程 diverge 了我就默认会有冲突），先 fetch+status 一下，有个心理预期。

yhxx

2019-05-18 22:21:20 +08:00

先不说什么团队规范，你怎么 pull 关他什么事。。。为什么他能发现你 pull 的方式不合他心意？
又不是 push

Cbdy

2019-05-18 22:39:26 +08:00 via Android

提交代码发 pr 多简单

yidinghe

2019-05-18 23:11:05 +08:00 via Android

先 pull 再 commit 这是有礼貌的表现，就是不管什么锅我先背了，冲突我来处理。

liukanshan

2019-05-19 00:07:09 +08:00

这种情况还和别人理论什么你去争你就是傻逼他说的一切都对也麻烦不要去纠正。

exonuclease

2019-05-19 00:31:14 +08:00 via iPhone

先 git stash 再 git pull

oneisall8955

2019-05-19 01:35:13 +08:00 via Android

git 不太会用，用 idea 只是简单的 Ctrl K 选 push，自动 merge，有冲突手动合并，最后自动 stash 提交到主分支。。。

passerbytiny

2019-05-19 08:25:32 +08:00

恕我愚钝，不知道为什么先 commit 会避免冲突，要不楼主把同事叫过来问一下。
@bjjvvv #28
@watzds #30
@pkookp8 #33
你们 commit 的信息怎么写？还是你们觉得修改历史后再 push -force 更不容易出问题。

kran

2019-05-19 09:27:11 +08:00 via Android

@passerbytiny 并不能避免冲突，昨天看这个帖子我想的是，他同事说的可能不是主贴上的问题

zqx

2019-05-19 09:55:05 +08:00 via Android

如果用 git 不用 git 最佳实践，不如不用 git，换 svn

bjjvvv

2019-05-19 11:04:12 +08:00

@passerbytiny #67 提交了 commit 你的代码才算进了 git 的仓库。你合并代码也好，其他什么切分支也好，反正遇到到了什么问题，你想回滚的时候，发现自己代码根本就没被 git 记录就蛋疼了。

siteshen

2019-05-19 11:58:13 +08:00

只要你不搞坏别人的东西，怎么操作都没问题。如果用自己的流程，搞出问题（或者要麻烦别人），就别怪别人发飙。

pkookp8

2019-05-19 12:33:53 +08:00 via Android

@passerbytiny 我没说 commit 可以避免冲突，我是说我的意思是 commit 之后代码就被 git 管理了，即使有什么操作导致你的代码丢失，只要不是整个仓库被删，都能恢复。冲突也可以在 commit+pull 之后解决
反之如果先 pull，解决冲突过程出了点意外，代码可能就没了。所以对方的想法并不是没有道理的
楼上很多人说可以用 git 的分支开发，我想说 svn 其实也支持分支开发模式，如今 svn 和 git 一样是差异存储。但是很多人认为 svn 一份分支就是一份存储，可能是以前的模式误导了吧。
commit 信息怎么写: 你改什么写什么。一两句话简单描述一下就行了。反正我是不会用 code 或者 update 之类的一个单词的描述