github 如何运用 git 进行多人合作开发？

[uniquecolesmith]

问题描述

• 在多人和做的时候，两个人同时从同一个分支branch自己的分支, 他们修改完代码提交的自己的分支后，管理员何必的时候出问题了，因为他们在同一行添加了自己的代码，导致何必失败，现在怎么办？怎么合作git开发才是正确的姿势？？

[mahone3297]

有conflict，肯定要手动fix吧。。。
支持lz chi种头像。。。

[MrGba2z]

手动merge啊...

[xiaogui]

git 的理念是沟通。

[finab]

冲突了肯定需要管理员自己解决冲突呀，解决冲突算个commit。。
他们就可以pull一下继续开发

[uniquecolesmith]

@mahone3297 好吧，只能这样了... Please Call it キム·ウッドリサーチ，　哈哈

[uniquecolesmith]

@MrGba2z 好吧，谢谢

[uniquecolesmith]

@xiaogui 嗯，有理，我现在很需要沟通，他们不会=_=

[uniquecolesmith]

@finab 嗯，人多了，感觉更麻烦, 唉

[xiaogui]

@uniquecolesmith 很久很久以前使用 svn 的时候，用自动合并，然后发现程序总是自作聪明的合并的乱七八糟。还是人跟人沟通才是王道。

[uniquecolesmith]

@xiaogui 关键是有些人太固执，也来交流，沟通不来怎么办...最难的还是人与人之间啊.....学生都不把这当回事，邋遢死了

[lululau]

开发人员自己merge，遇到 conflict 互相沟通，自己解决，解决后提 PR。对于不能 auto merge 的PR，管理员打回，由开发人员处理后重新提交 PR

[xiaogui]

@uniquecolesmith
1、在尽可能的情况下，减少开发人员，这样可以降低沟通成本；
2、在划分功能、模块或者其他的时候，要分得仔细一些，减少“在同一行添加了自己的代码”的可能性。另在划分以后，要求优先完成与其他人有交叉，联系的部分，这样不至于严重影响其他人的开发进度；
3、队伍磨合是最困难的事情，学生的话个人更难沟通一点，让大家都认可的人推动这件事情，可能效果会更好一点。

[uniquecolesmith]

@lululau 嗯，不错，换个思路，减轻了管理员负担，但是那些开发人员都不熟悉, 而且很懒，这个，自己得解决

[hjc4869]

我们内部做项目用的就是git，一般协商好尽量不两个人改同一个文件。如果两个人改了同一个文件那么就需要resolve conflicts.

[uniquecolesmith]

@xiaogui 嗯，这个过程得很长，因为它们都用windows，不喜欢命令行，不喜欢*nix，强迫他们半年都没学到最基本的命令，带这它们真累....虽然我代码方面的成就比他们好很多，但是我和它们同级，感觉这是个问题，不知任务都不做，只是当时积极报项目，三分钟做项目的热度。。真难

[xiaogui]

@uniquecolesmith 对于懒虫来说，就推荐他们使用 https://windows.github.com/ 。

[9hills]

管理员去解决冲突。这是管理员的事情，和那两个人没啥关系

[timonwong]

1. master 禁止任何人提交，除了管理员（可以是CI）；
2. 提交者创建 feature 或 bugfix 分支，提交后进入 Code Review 阶段（同时 CI 进行测试）；
3. Code Review 和测试通过，管理员进行合并；
4. 若合并不成功（冲突），直接打回。

使用 Stash 加一个 CI，Jenkins/Bamboo/TeamCity，这些都还是比较好实现。

[mornlight]

不喜欢命令行就不要强制他们用命令，用Github 官方客户端或者SourceTree 都挺好的。

[drivedreams]

Git分支功能强大，可以在同一工作目录快速切换。所以应该充分利用该功能。
如果人多的话，建议每个人在工作的时候，针对当前自己的工作建立一个新分支。为新建分支时注意分支名称要说明该分支正在工作内容（合作者要经常查看别人建立的分支，通过名称分析是否与他人冲突，降低冲突的可能性）。每个新建的分支解决的问题要相对简单,，每个分支建立的时间不宜太长。最好是两三天之内关闭及合并。此外新建分支在服务器有备份，在处理冲突时降低冲突带来的风险。

建立多个分支，可通过Github提供的图表功能清晰的看见每个人做了分别做了哪些工作。便于后期维护。