0.新成员如何管理和使用这个工程？
对于后端而言，因为我们也是初次接触Django，因此从我们学习到程序编写过程中用到的各种知识都有学习笔记，比如Django的详细使用，Django数据库的使用、跨域通信以及用于WebSocket的Channels插件的使用。而我们的后端程序也基本上是按照这个框架来做的，其他具体的接口的定义也都已经发布在了GitHub工程中。
后端学习笔记博客如下：
http://www.cnblogs.com/14061216chen/p/5975450.html
http://www.cnblogs.com/14061216chen/p/5990610.html
http://www.cnblogs.com/14061216chen/p/5998376.html
对于前端，主要就是React Native环境的搭建，参照下面文档即可：
1.你的团队的源代码控制在哪里？用的是什么系统？如何处理文件的锁定问题？
我们团队使用的是GitHub进行代码管理，通过GitHub的客户端就可以进行各种源代码控制。比如显示与查看代码更改内容，更改历史，以及代码回滚等功能。
至于文件的锁定问题，GitHub是不支持对同一个文件进行不同的签入的，所以两个人不能修改同一个文件，而这一点的保证是通过我们的分工实现的，因为人比较少，所以每个人负责的部分分的比较开，而且大家比较容易交流，同时修改同一个文件的情况会被避免掉。
2.如何看到这个文件和之前版本的差异？ 如何看到代码修改和工作项(work item)，缺陷修复(bug fix)的关系。
在GitHub上每次签入代码都会有详细的更改记录，也有前后的对比，可以很清楚的看到前后版本的差异，当然再配上一个版本更新说明就更清晰明了了。
首先，GitHub可以看到每个修改文件以及修改前后的详细对比，然后版本更新说明中记录着本次更新解决的问题，两者结合就可以看到代码修改和工作项、缺陷修复的关系。
3.如果某个文件在你签出之后已经被别人修改，并且签入了，那么你在签入你的修改的时候， 如何合并不同的修改（merge)? 你用了什么工具来帮助你？
对于这种情况，GitHub是不允许签入的，他会提示你代码冲突，可以看到哪里有差异。所以想要签入两分不同修改的话，就需要人工的比对然后进行修改。
4.你有20个文件都是关于同一个功能的修改，你要如何保证这些文件都同时签入成功（修改的原子性），或者同时签入不成功？
首先在真正签入代码之前是需要经过测试的，测试无误后才会签入，这就在一定程度上保证了同一个功能的相关文件都被正确修改了，然后这时再一起签入。假如测试有遗漏，在之后的阶段还是可以查看到相应记录的，然后再进行相应修改。
5.你的PC 上有关于三个功能的修改，但是都没有完成，有很多文件处于半完工的状态，这时你要紧急修改一个新的 bug，如何把本地修改放一边，保证在干净的环境中修改这个 bug, 并成功地签入你的修改 --- changelist management。
这一点可以再创建一个分支，从GitHub上下载之前的代码，修改之后签入，这样就能解决上述问题了。
6.如何给你的源代码建立分支？
这种分支可以用不同的版本来替代，比如我的演示版本是1.0版，真正发布的版本是2.0版。这些版本都保存在记录中，都是可以下载的，管理者可以根据需要把某个版本当成当前的主分支，不用时再替换回去。
7.一个源文件，如何知道它的每一行都是什么时候签入的，为了什么目的签入的 （解决了哪个任务，或者哪个bug）？
在GitHub中，他会自动记录每行代码的签入时间和整个签入时的加入的标注，因此通过查看记录就可以知道上述问题。
8.如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？
因为GitHub每次签入时都要加标签和注释，我们可以根据这些说明来确定各个版本。
9.你的项目的源代码和测试这些代码的单元测试，以及其他测试脚本都是放在一起的么？ 修改源代码会确保相应的测试也更新么？你的团队是否能部署自动构建的任务？
对于前端的测试，暂时没有自动测试，如果有的话，这些测试脚本应该是单独创个文件夹放在工程里的。
对于服务端，如果修改代码签入之后，服务器会自动根据更新代码重新启动的。
至于自动构建的部署，暂时还没有时间做。