因为 git pull 和同事闹僵了。

2019-05-18 01:48:08 +08:00
 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 正确使用方法

15560 次点击
所在节点    职场话题
80 条回复
impl
2019-05-18 04:54:02 +08:00
换 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
emm。。折中一下 git stash 然后 pull 然后 git stash pop
mikicomo
2019-05-18 07:13:32 +08:00
我是 commit pull push 的,有时候不想提交就先 stash,有时候真的觉得 commit 比较多难看了,就 rebase 一下,至于 idea 文件夹的问题…可以用 gitignore 解决
precisi0nux
2019-05-18 07:21:46 +08:00
你这已经是好的了,既然用了 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
说难听点你们这一群人都是瞎搞,技术团队水平堪忧,都在一个分支上操作能不乱吗,可以先锁死 master,按功能或者需求进行分支创建,完成之后先 merge 某个稳定的分支或者 master,这样谁的屁股不干净就自己擦,再由一个主要负责人进行 MR 审核
wpzero
2019-05-18 07:37:38 +08:00
同事的操作肯定不规范了,你们开发都在一个分支? git 的好处就是分支轻量,如果不同分支,我感觉 pull 没关系的
dangyuluo
2019-05-18 07:39:56 +08:00
纯属瞎开发,团队效率 -80%
liaojl
2019-05-18 07:56:27 +08:00
没 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
一人一个分支
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
都是惯的,为了避免瞎 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
楼上把我惊呆了,这跟 cli 习惯有个毛的关系,用 jb 就必须按 ide 得来???团队连个开发流程都没有
Felldeadbird
2019-05-18 08:37:56 +08:00
不是一人一个分支吗?
3CH0
2019-05-18 08:38:19 +08:00
貌似 JB pull 有冲突的时候 会自动 stash
wengjin456123
2019-05-18 08:43:13 +08:00
你们不发 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
每个人 fork 主仓库,在自己 fork 的仓库开发然后提交 pr,邀请负责人和同事 code review,通过就合并主仓库 master 分支

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/565241

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX