如何看待项目组长不会用 Git 却指定用 Git？

[omysho]

先做一些定义的说明，以免意思理解的错误

• 项目组长：指的是既分派开发任务又参与项目实际开发（写代码）和管理的人。

• 不会使用 Git ：

  1. 整个开发团队共 5 人，只给了两个开发者权限（剩下的人他就直接不管了，也没有给任何的其他权限）
  2. 不会 resolve conflict ，直接保留了 git 用于指示 HEAD 和 commit 之间冲突位置的文本
  3. commit message 大量重复并意思极其模糊
  4. 没有 branch 、 merge 、 PullRequest 等概念，将 PullRequest 视为直接向 master 提交了 commit ，并且因此回滚了很多次代码。
     

我感觉我摊上这个项目组长之后，对生活感到十分绝望。

想听听大家有什么看法。

想了一想还是写个附言好了。
首先感谢一下大家，本人第一次发帖就能拿到这么多回复实属荣幸。

================== 关于沟通问题 ===========================
楼下的回复给我很大的启发，准备找组长好好沟通一下这个问题。
但是，正当我跟他约好一个时间准备谈谈的时候，他在项目组里面说

居然用手工合并代码！我已经被他的伟大所折服了。
我在想我是不是还要和他沟通交流 git 的问题。。。

================== 关于 “不会 Git 所以用 SVN ” ===================
楼下有提到 “虽说不会用，但是好歹比只会用 SVN 强啊！” 。
我个人的看法是这样的，用什么工具方法无所谓，但是，既然决定了使用 Git ，就应该遵守基本的 Git Flow ，或者拿出一套团队的协作方案来，而不是决定使用 Git, 到头来又不遵守规范。既然你不会用 Git ，就别指定用 Git ，用 SVN, CVS 之类的你熟悉的就行。
虽然到头来要付出一些学习成本，但是总比现在这样 不会用还硬要用，而且瞎用 来的要好。

================== 关于 PR 导向的工作流 ======================
我承认使用 PR 导向的工作流显得过于重，有时候就改那么几行也发个 PR 的确不妥，但是我们团队的成员不经常见面，在一些大改动的时候使用 PR ，有一种 “发帖回复” 式的工作方式可以加强团队之间的交流，减少一些代码方面的错误。不知道大家怎么看。

[popo233]

跑路吧

[FrankFang128]

我只关心能做出东西吗

[yangqi]

组长如果什么都会，还要你们这些组员干什么？

[omysho]

@FrankFang128 说的不错，项目组长是个研究生，据带队老师所说，他至少已经做过 4 个项目了。

[df4VW]

直接和带队老师说啊，最烦毛都不会还指手画脚的

[czheo]

工作中遇到这样的同事甚至上司是很正常的。工作不是上学，比谁技术好，谁成绩高。重要的是 teamwork ， member 之间取长补短，分工合作。 LZ 如果自己会，完全可以把自己的知识分享给你的 team 。

[cxbig]

Git 是个很简单的东西，开一个研讨会要不了多少时间，会的人发言。
把 git flow 的理念、流程过一遍，有问题当场提出解决，小组内部商讨出一套自己的执行方案。大家照做，谁不按规范来就踢出队伍。

[bbx]

其实关于 commit message, 每次写我都觉得很痛苦，很多时候自己也是写的大量重复和极其模糊。最后，我统一都用 ticket url 作为 commit message ，感觉舒服多了。

[maxiujun]

这么小的团队用 pull request 才蛋疼。
不要太矫情

[MayLava]

至少人家还在用 Git ，应该还能交流吧。
要不然标题就该变成“如何看待项目组长不会用 Git 坚持使用 SVN ？”了

[omysho]

@maxiujun 使用 PullRequest 是有理由的，因为只给了两个开发者权限，所以不得不 由其中一个人 fork 一个版本。在 Fork 下面进行开发。

[hqs123]

这是项目组长训练你们的第一课，他是故意弄错让你们指出错误的，楼主应该勇敢主动说明问题.

[wy315700]

如何看待项目组长不会用 Java 却指定用 Java ？
如何看待项目组长不会用 Python 却指定用 Python ？
如何看待项目组长不会用 PHP 却指定用 PHP ？
如何看待项目组长不会用 Linux 却指定用 Linux ？
如何看待项目组长不会用 English 却指定用 English ？
如何看待项目组长不会用 Mac 却指定用 Mac ？

[greatghoul]

感觉楼主好无聊，不会用，用着用着就会了么。

[pynix]

可能在别的方面有过人之处。。

[kslr]

不会可以学，规范要定起来

[clino]

不会但是有眼光也行
不会交给会的人去做也行

[SharkIng]

组长不懂，不会并不代表不能用，我觉得这没什么好纠结的。
尤其是这种学校的项目来说，肯定不会像公司那样规范一些

说个身边的例子：
有个朋友正在完成的某个学校项目的朋友，他们的组长是一个学工程的，技术上面一窍不通。但是依然做了他们的组长。难道这种就需要吐槽很久么？他们的产品依然完成了，也上线了，据说还不错。

在我看来，组长有着更重要的功能。
组长不会代码，但是也许组长会有更好的 Idea ，很好的头脑。
组长不会 Git ，但是也许组长画图可以。
组长不懂技术，但是也许会有更好的交际能力，能拉来赞助？

以上说的有点偏，但是总而言之组长需要的是综合能力，而不是某一个技术上面的能力。而且至少来说，他让你们用 Git ，而不是用网盘同步或者更老的方法用 Email 把代码发来发去的。这已经说很好了。至于他会不会，精通不精通，那是另外一回事。

再者，有建议可以和他提出，他做的不对的可以和他讲，听得进去的，就是好组长，听不进去的，那还是按照楼上说的，早点跑路比较好。

[amon]

项目组长用了 Git ：如何看待项目组长不会用 Git ，却指定用 Git ？
项目组长没用 Git ：如何看待项目组长不用用 Git ，指定用 SVN ？

Git 又不是多么复杂的东西，真想了解的话，人家半天就会了，甚至比你精通。
别 BB 了，该干吗干吗。

[Felldeadbird]

如果有意见，就提出，不要只在网上讨论。一会跟我去会议室说一下流程吧。

[Felldeadbird]

我只是吓唬一下楼主。

[BruceLi]

你的机会来了，还等什么。

[crazyxin1988]

组长也不是全能
如果 不会 你不是会吗 你可以说出来啊
你可以给大家讲讲 git workflow 啊
组长之所以组长 肯定有一定的道理

[Anran]

理解楼主。

组长不好好用 Git 肯定不是学不会，也许是从来就没在意 Git 工作流程这个概念。 Git 在他眼里只是个备份工具。楼主可以和气地向他安利下 Git （假设你还没有），如果还不接受，那就是态度问题了，最好离的远远的，以免感染上不好的习惯。

Git ，代码规范，这些东西都是团队协作过程中产生的，我不同意那类只关心最终产出而忽略这些规范的观点。如果你只是一个人自己玩，那当然怎么玩都可以。多人协作不遵守规范就是给别人添堵，浪费生命。

[donge]

如何看待马云代码都不会写，还招聘那么多码农？

[xmbaozi]

矫情

[gancl]

楼主不会教吗? 我们用 cvs 才崩溃呢

[chinuno]

既然组长指定用 git ，那么至少应该要了解一下 git 的操作和 git flow 等各种概念。组长是管理整个项目的人，做任何决定都应该为项目开发来考虑，怎样操作效率最高最合理是他应该考虑的问题。况且他还是实际参与开发写代码的的人没觉得现在这样效率低下特别怪异吗？

如果你们组长真的不了解这些概念那么你应该跟组长解释提出来，也是为了让自己后面的开发更加顺心。如果跟他说了之后他还执意保持现在这种状况，那么你才应该对这个项目的未来感到绝望

[wuyouchao]

如果看到组员有意见不直接沟通，却在网上吐槽

[500miles]

心态摆放好呀.

可以尽力吐槽, 可以尽力打趣奚落

但是 任何人和事都不能只盯一点不放呀... 尤其是 人这么复杂的动物

------

之前的一个技术 leader 不懂 rebase 和 merge 到底有什么区别,

他直接在 html 里面写了"\r\n"试图换行

但是公司整个业务线是这货架构的, 新项目都是他`打地基`

偶尔 review 代码, 指点一下, 总能三言两语让人顿悟...

------

还有另一位主管, 总和我们开心打 P, 也不知道他整天坐那儿搞毛, 好像都在浏览网页什么的吧...

代码 工程 啊什么的... 他真的经验不足...

他从来不让加班, 嚷嚷着我们要有自己的生活....

但是很奇怪, 需要时候, 我们都会主动加班

他整天和产品撕逼 恩 就连设计妹子也撕 ... 得益于此, 我们少了很多无畏的骚扰

有时, 误了工期 或者 出什么差错, 我们很愧疚 .. 他只说 '这个我去跟 xxx 解释, 你们抓紧解决'

还有 例会工作报告的时候, 他总能讲的头头是道 博得领导频频参与讨论 点赞

我们都信他 他是我们的老大

------

再说最后一个小例子. . .

还有一个妹子 天天开心的不得了 大大咧咧 心眼儿大的没谱

工作经常出岔子 讲话经常伤人( 尽管好多是无意的 )

所以 尽管挺漂亮 其实都不太受待见...

后来才知道 妹子是老板娘一个什么妹妹, 表妹还是堂妹来的

------

所以呀 今天我作为一个长者, 我有必要告诉你们一点人生的经验...

该吐槽吐槽 别老盯着人缺点不放 带上了有色眼镜 真不好

[jydeng]

是时候好好教育一下了 o(-"-)o

[bygreencn]

Git 又不是什么复杂的东西，弄个 github 的账号，装个客户端，半天就了解了。只是每个那么多提交权限，这个简单的跟 1 一样。
弄好你的正业，项目代码写的漂漂亮亮的比这个纠结这个强多了。
年轻人啊

[typcn]

谁也有不会的啊。。
楼主发的内容也是一种学习的过程啊，既然问题已经发现了，那么下次还会再犯同样的问题么

[xpol]

教育他。

[loudis]

组长确实不太对，但这就是真实的生活，以后到了公司会有更多的事情。

这点事就绝望了？如果你静心想想，这同样是个机会。你可以学习学习如何与不爽的人工作甚至被领导，也可以想想如果我做组长碰到不会的事情向下部署，应该如何做，最后还可以试试如何解决当前的局面。

[imn1]

李嘉诚说过，“我不用会开船啊，下面有人会就行了”，是当年 9 号码头的专访

[pepsin]

你应该直接给一个好的合作方式，然后让组长接受。

等着领导帮你打点好一切，那找你干嘛。

[matthewz]

明说吧 你们组长纱布

而那么多回复都在告诉你 lowB 公司这种人多的是 如果你也想成为一个 low B 你必须学对付这种人

以上

[djyde]

组长不会用 Git ，钦定你们用 svn 才可怕

[forcecharlie]

我反正 commit message 随便写，反正大伙看 diff 也不会不懂

[hantsy]

Git 要么用经典的 Git Flow(个人感觉比较复杂，但工具支持还行)，要么用 Github Flow 。当然现在项目用多到了，使用 Github 比较多，也比较倾向 Github Flow 。

1. Fork upstream master into your account
2. Create a branch for a task/issue/hotfix
3. Modify the codes
4. Commit & push into your remote branch
5. Create a pull request
6. Code review(maybe some code modification, some git merge, commit & push operations in this stage)
7. Make sure all codes are built(compiled and tested) successfully on CI server, then merge into upstream/master

[hantsy]

@forcecharlie Commit Message 必须是正式的有用的对 Commit 内容的描述，而且最好一个相关的 任务（任务片断），能够解决某些问题，否则 Commit 有什么意义。

我们经常可能另外一个 Branch 要事先合并分支的某个 Commit ，直接用 git reflog 查一下，然后用 cherry-pick 直接合并进来。

[linhua]

推荐他玩这个游戏
http://pcottle.github.io/learnGitBranching/?demo

[hantsy]

@omysho 所有的开发任务都应该用 Fork ， Branch 的方式进行， upstream/master 不应该直接提交任何代码。

[qiukun]

@hantsy google 躺

[hantsy]

@linhua Cool

Github 官方也提供简单的教程（一个小时 Step By Step 就可以了解 Github 的方式了），还有就是 atlassian 的 GIT 教程极好，我现在还经常看。

https://www.atlassian.com/git/

[Wenwei]

楼主会 git ，大可以给 team 做个分享，教育大家正确使用 git 。。。

[Lonely]

楼主这种就是矫情

[msg7086]

@hantsy 其实 github flow 就是 git flow 的 light 版……

[bk201]

看法就是要么你就直接正面肛，说出你的想法。要么你就别抱怨，做好你自己的工作。
当然还有就是直接走人。

[hxndg]

说实话，我看了以上诸位的回复，发现一部分程序员的回答有些令人尴尬，应当说可能对于技术关注的过分了一些，一开始本来打算写个帖子专门说说沟通的事情，不过转念一想太麻烦了。 lz 你可以看看楼里的回复，了解一下恰当的沟通不恰当的沟通是什么样子的。

[LINAICAI]

很正常啊，很多用 svn 多年的都不会 git 。。。
你得教教他～

[LINAICAI]

怎么说，这种组长很少不知道 git 吧，既然知道应该会去学，可能有他自己的考量，反正别人的习惯一时半会很难改，但你指出这种用法很坑的话，又太直接了不好，找个机会私下聊聊，他可能会接受一点。

[bupo]

边学边用，如果不会就不用那才叫坑

[bkmi]

哈哈哈哈 4 个项目好多哟，我曾经面试过一个，声称做过 50 多个项目，追问之下，原来是 eclipse 里有 50 多个 project

[4everLoveU]

人比人，总是有你会他不会，他会你不会的
开放的心态看待这个吧，技术团队多分享，共同提高才是王道

[hantsy]

@msg7086 重点完全不一般。

Github 强调首先是要 Fork 。

Git Flow 重点是 Branch ，还要维护几条 Branch 主线， Development, Release, HotFix 等。

[msg7086]

@hantsy Light 版没有那么多东西，主要就是 branch+merge 。
Github 的 Fork 无非就是强制 branch 而已， Git flow 如果禁用 dev push 的话效果是一样的。
Fork 并非是要强调的东西。

[chend]

要用 git ， 至少 说明 组长 还是 愿意 用新技术新工具的， 而且 git 也就一种工具， 很快就能学会的~~
如果因为 不会用 git ， 就说 用 会用 SVN FTP 什么的， 这应该更让你 桑心

[konakona]

虽说不会用，但是好歹比只会用 SVN 强啊！

[Balthild]

楼上好多人似乎都没抓住重点。

都在说什么“组长不会，手下会就行了”。然而，请你们仔细看描述，楼主的组长并没有让他收下会的人来管理 git ，而是自己在管理。

[yhylord]

我来歪个楼， ls 诸位遇到只会用 SVN 的怎么办……

[akira]

@yhylord 那就用 svn 呗，难道不用阿。

[yhylord]

@akira 那为什么上面都说什么“遇到不会用 Git 指定用 SVN 的”，我感觉如果没有什么大问题的话还是不要迁移对吧？

[publicAdmin]

git 是自己搭的么。我有点好奇他不会用居然会配置权限。- -

[ichou]

直接质问他 git 是这么用的么？

[forcecharlie]

@hantsy 确实是这样，不过对于本来就只有几个单词的改动了，简单也是可以的。并不一定要拧在条条框框上。一个很明显的例子，有的自从学了 flow 以后，就必须认为 master 丢 稳定版，然后建个 development 分支进行快速开发。实际上 对于 git 来说，分支是平权的，都是 引用，引用到一个 commit 点， commit 追溯寻宗到 初始 commit 就构成了 分支。

[omysho]

@publicAdmin 不是，用的是 Git@OSC 。

[ChiangDi]

我选择离职。

[JayFang1993]

这组长 怎么当上的，怀疑！

[wd]

不懂没关系 但是如果瞎指挥 劝楼主早点走人吧

[XianZaiZhuCe]

总有不会的东西，小组内部可以做技能分享，挺不错

[wwek]

楼主能抓起来了. 把规范定了.让大家强制执行
遇到问题要迎上解决掉

[hrong]

做日本项目更蛋疼， SVN 都没有 trunk,branches,tags ，所以楼主你要理解，你那种情况，如果不是大项目，根本就不是什么事。
如果你真的要很 Gitter ，自己建个本地分支，自动跟那个蛋疼的分支自动 merge ? 哈哈哈。。。。

[newghost]

不要迷信新技术

每个人在本地 commit 一堆代码后， Git 的 merge 和 sync 都会变得很复杂，非常容易造成冲突，而且 Git 免费的工具还很不完善，将几个有一大堆 chnage list merge 起来非常痛苦，很浪费时间。

个人感觉中心化的 SVN ， TFS 、 Perforce 之流，一个 change merge 一次，出错的机率更小，做 Massive Merge 版本管理，反而更省时间。

[wadahana]

@chend

[wadahana]

@chend
做过有一个项目 要用刻光盘同步代码。。比 FTP email 神马的牛逼多了。。

[ren2881971]

目测 LZ 刚毕业 或者是实习生。。。

[0987363]

svn 路过。无言以对。。

[saintatgod]

你可以试着和他谈一下,大家开个碰头会把这个流程啥的整理一下,一顿烧烤能解决的事情.