因为 git pull 和同事闹僵了。

[codetnci]

同事:(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 正确使用方法

[impl]

换 SVN

[fhsan]

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

[iamdqncoder]

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

[mikicomo]

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

[precisi0nux]

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

[WoodenTea]

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

[nicevar]

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

[wpzero]

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

[dangyuluo]

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

[liaojl]

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

[dengtongcai]

一人一个分支

[kmahyyg]

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

[swulling]

都是惯的，为了避免瞎 commit

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

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

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

[chengluyu]

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

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

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

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

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

[trait]

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

[Felldeadbird]

不是一人一个分支吗？

[3CH0]

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

[wengjin456123]

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

[keepeye]

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

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

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

[wengjin456123]

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

[hhecoder]

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

[wengjin456123]

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

[fuxinya]

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

[sansanhehe]

都挺不规范

[ccpp132]

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

[snappyone]

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

[ferock]

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

[deepdark]

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

[henryhu]

分支、rebase 用起来

[learnshare]

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

[bjjvvv]

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

[taotaodaddy]

你们的技术负责人在哪里

[watzds]

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

[KuroNekoFan]

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

[Perry]

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

[linchengzzz]

使用方法

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

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

[pkookp8]

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

[yoshiyuki]

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

[kuyuzhiqi]

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

[newtype0092]

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

[hanxiV2EX]

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

[GeruzoniAnsasu]

1L + 1

换 svn

[xuanbg]

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

[lionseun]

感觉是毫无意义的争论

[bigjack]

这种事也值得生气

[winglight2016]

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

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

[hirasawayui]

打起来打起来，

[danjk159]

还是 svn 吧

[uxstone]

以功能模块或修改 bug 为一次 commit, 一般一天下来能有个 5 到 6 个 commit

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

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

还有没事别瞎 commit , commit 的信息要写清楚都干了啥
我就想说都这样做了还能有啥冲突？

[demonzoo]

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

[sunocean]

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

[Linxing]

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

[Lision]

git pull --rebase

[tyrealgray]

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

[weizhxa]

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

[cqy2016]

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

[sdushn]

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

[anonym233]

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

[whypool]

git reset --hard --hard

[icylogic]

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

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

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

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

[yhxx]

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

[Cbdy]

提交代码发 pr 多简单

[yidinghe]

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

[liukanshan]

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

[exonuclease]

先 git stash 再 git pull

[oneisall8955]

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

[passerbytiny]

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

[kran]

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

[zqx]

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

[bjjvvv]

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

[siteshen]

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

[pkookp8]

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

[hellomsg]

发帖子的时间可以去练一练 git 怎么用

[du5t6reak]

git add . 我也是醉了，在我们 team 这么玩儿要被骂死的，个人配置文件也 push 有病吧

[luozic]

找个 github flew 练习一下不就行了，三个都在哪胡搞，都还有理了。

[dNib9U2o8x]

建议你们使用更加强制化的流程, upstream/master 分支禁止 push，只允许从 pull request merge，这样你们本地愿意怎么玩就怎么玩

[moxiaonai]

流程有问题，不是操作的问题

[corningsun]

楼主是否 pull 后把别人的提交覆盖了？

上你们 git 提交历史图吧，看结果才能让大家评理。

[bdnet]

Gitflow、GitHub flow、Gitlab flow

更重要的是约定一个开发流程吧，至于操作方式，不需要定这么死。有人喜欢点鼠标，有人喜欢命令行，还有人直接快捷方式搞定。

[l00t]

菜鸡互啄