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

手动merge啊...

git 的理念是沟通。

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

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

@MrGba2z 好吧，谢谢

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@hjc4869 嗯，这样也不错

@xiaogui 谢谢

@9hills 额，好吧
@mornlight 嗯
@timonwong 我是这么要求的，可是打回去，它们不干=_=
@drivedreams 看来还有好多工作要做

@uniquecolesmith 标准流程是merge第一个发出merge request的，后一个冲突了打回让他改。

但是你威信不够。。就只能管理员自己改了。。

先merge a
两人pull
再merge b呀
至于先后 让他两猜拳去吧~

搬进 Github http://gitbeijing.com/

每个人玩儿自己的分支

合并提merge request ，管理员来看。
有问题单独说，做好的，群体表扬。

这不光是技术问题，也是管理员的管理艺术。

采用详细的分好task，每个人任务要分开，在就是采用pull request 模式！

@ilotuo 哈哈

@9hills 威信技能不够，哪里购买

@nijux thanks
@colorfulberry 嗯，谢谢，我还没理解透PR, 载学习学习
@ferock 嗯，这艺术得学好久，3Q