(1) 你的团队的源代码控制在哪里？用的是什么系统？
答：我们团队的源代码控制在Git，Git是一款开源的分布式版本控制工具。用的是Win10系统。
(2) 一个代码文件被签出之后，另一个人可以签出这个文件，并修改么？有几种设计，各有什么优缺点？
答：签出文件后主要有两种设计：
① 此文件被加锁，其他人无法签出
优点：可以保证每个人获取的文件版本是最新的，也不会产生修改冲突。
缺点：这种方式花费的时间相对要长一些，因为其他人需要要等到其他人修改完文件后才能签出来进行自己的修改。
② 不加锁，所有人可以自由签出文件并进行修改
优点：大家可以各自修改自己需要修改的模块。
缺点：合并代码的时候，会产生冲突，需要人工去修改。特别是几个人修改一个文件涉及到相同函数的修改。
(3) 如何看到这个文件和之前版本的差异？
答：有以下方法看到这个文件和之前版本的差异：
① 查看两个提交版本id的修改记录差异
使用$ git diff commit-id1 commit-id2
② 查看两个提交版本id修改了那些文件
使用$ git diff commit-id1 commit-id2 --stat
③ 提交日志显示每个版本的提交主题和具体修改的文件名字
使用$ git log --name-only
(4) 如果某个文件在你签出之后已经被别人修改，那么你如何合并不同的修改（merge)?
答：在Git中，会对有冲突的代码做出相应的提示(conflict)，届时进行手动合并就可以合并不同的修改了。
在Github中，可以通过git log命令来查看历史提交记录后进行合并不同的修改。
(5) 你有20个文件都是关于同一个功能的修改，你要如何保证这些文件都同时签入成功（修改的原子性）
答：可以通过git中的commit先将所有本地修改保存到本地版本库中，再统一push到服务器版本库中，这样就保证了修改的原子性。
(6) 你的PC上有关于三个bug的修改，但是都没有完成，这时你要紧急修改第四个bug，如何把本地修改放一边，保证在干净的环境中修改第四个bug，并签入修改？
答：首先备份在本地一份工程，然后在本地新建一个分支，在新的分支上进行bug的修复，当前分支的内容就被保存在原地。
(7) 如何给你的源代码建立分支？
答：在Github中：① 打分支：有条件地合并分支和主分支
② 新建一个分支，在这个分支上，回滚到用户所用的版本
在Git中：通过git reset --hard + 哈希值：回溯到指定版本
(8) 一个源文件，如何知道它的每一行都是什么时候签入的？
以Github为例：执行git blame命令，即可显示每一行都是什么时候签入的，为了什么目的签入的，签入人是谁。
或者在Github页面上：
(9) 如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？
答：① 在Git上可以使用打基线（针对项目源码）的方式，打基线是将每次发布的版本源码放到一个文件夹下面，例：这次发布的是1.1版本，就在版本管理库(Git)里面的目录(tag)下，建立一个名字V1.1的分支，然后把V1.1版本的源码都放进去。但这样做的方式维护起来比较麻烦，V1.1发布以后，如果要改一些临时修复的紧急bug，还要在tag下的V1.1文件夹中建立一个patch文件夹来放修改bug涉及的源码文件。
② 在Github上发布的时候，可以编辑想要release的文件信息，创建标签并设置版本号并上传文件。这样的话，看提交历史就可以很清楚的找到LKG版本，而且也容易回滚。
(10) 你的团队是否能部署自动构建的任务
- （自动同步所有文件，自动构建，自动运行单元测试，碰到错误能自动发邮件给团队）
答：鉴于水平有限，在部署自动构建的任务尝试不成功后，我们团队决定进行手动测试，更新修改源代码后会自动更新备份，单元测试及其他测试也会在更新修改源代码后手动进行，有错误会在测试代码中修改，然后也会更新时间线上传修改过的代码，因此没有部署自动构建的任务。
团队总结：我们在一点点深入学习和探索Github和Git代码管理平台的过程中，遇到了一些困难和问题，并花费了不少的时间去解决问题（有问题因水平问题暂无法解决），这让我们发现我们只是接触了Github和Git代码管理平台的皮毛，仍需继续努力学习Github和Git代码管理平台。
