版本控制：回答问题

此作业要求参见：https://edu.cnblogs.com/campus/nenu/2020Fall/homework/11435
一，问题回答
  0. 在吹牛之前，先回答这个问题： 如果你的团队来了一个新队员，有一台全新的机器， 你们是否有一个文档，只要设置了相应的权限，她就可以根据文档，从头开始搭建环境，并成功地把最新、最稳定版本 的软件编译出来，并运行必要的单元测试？
      回答：是的，我们开发完小程序后，我们都会把需要搭建的环境和操作相关的步骤都会写在相应的文档上，这样做不仅可以节省新队员熟悉项目的时间，而且以后还会把项目和文档分享到github上，供更多人进行开源共享。

  1. 你的团队的源代码控制在哪里？用的是什么系统？如何处理文件的锁定问题？
     回答：项目在 github上，使用 git 进行版本控制。使用 win10 系统。我们团队的在处理文件的锁定问题时没有加锁，我们的项目比不上大型企业的项目，所以没有对文件迁入迁出进行过多的限制。将文件在迁入迁出时加锁，显然可以保证源代码修改的同步性，减少不必要的冲突和错误，但是这样的缺点是显而易见的，由于缺乏了并行性，项目开发的效率就被极大地降低了，以我们小组现在的项目规模就不需要加锁。当然对于文件锁定问题：可以这样，在主分支master中,若要实现一个大的功能，可以在当前master分支开一个新的分支用户对文件进行改写。下一个人也开在当前master分支开一个分支新的用户分支进行bug的修复，修复完成之后与master进行合并，完成了功能的实现之后再与master分支进行合并。

  2. 如何看到这个文件和之前版本的差异？ 如何看到代码修改和工作项 （work item），缺陷修复 （bug fix) 的关系。
    回答：通过查看日志来了解各个版本的差异，可以看到相关的变化。我们在提交时会在修改的源码上添加修改备注，这样就能看到代码修改和工作项 （work item），缺陷修复 （bug fix) 的关系了。

  3. 如果某个文件在你签出之后已经被别人修改，并且签入了，那么你在签入你的修改的时候， 如何合并不同的修改（merge)? 你用了什么工具来帮助你？
    回答：一般不会出现这样的情况，大家都只负责自己的功能版块，修改自己的部分，因为都是提前商量好，不会和别人的产生冲突，即使产生了问题，也会即使与对方交流然后解决。

 4. 你有20个文件都是关于同一个功能的修改，你要如何保证这些文件都同时签入成功（修改的原子性），或者同时签入不成功？
    回答：通过组员之间私下交流，保证文件与文件之间同步。

 5. 你的PC 上有关于三个功能的修改， 但是都没有完成，有很多文件处于半完工的状态，这时你要紧急修改一个新的 bug，如何把本地修改放一边，保证在干净的环境中修改这个 bug, 并成功地签入你的修改 --- changelist management。
    回答：在原来的基础上，重新建立一个分支，专门用来处理bug。

 6. 规范操作和自动化
    你的团队规定开发者签入的时候要做这些事情：
   - 运行单元测试，相关的代码质量测试。
   - 代码复审 （要有别的员工的名字）
   - 和这次签入相关的issue 编号，任务/task，缺陷/bug 编号，等等， 以备查询。
    请问你的团队有这样的自动化工具让开发者方便地一次性填入所有信息然后提交么？ （高级功能， 代码提交之后， 相关bug 的状态会改动为 “fixed”， 并且有链接指向这次签入。）
     回答：我们目前还没有使用这样的工具。

 7. 如何给你的源代码建立分支？
     回答：在master上建立分支，找历史记录，并将历史版本下载到本地，需要哪个版本都可以进行安装，继而重现用户报告的问题。

 8. 一个源文件，如何知道它的每一行都是什么时候签入的，为了什么目的签入的 （解决了哪个任务，或者哪个bug）？
    回答：在GitHub上每次提交，都会留下commit记录，也可以通过工作日志来了解什么时候解决了哪个任务或者哪个bug；或者通过添加相关注释备注来解决。

  9. 如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？
     代码每天都在变，有时质量变好，有时变差，我们需要一个 Last Known Good （最后稳定的好版本） 版本， 这样新员工就可以同步这个版本， 我们如果需要发布，也是从这个版本开始，那么如何标记这个 Last Known Good 版本呢？
    回答：在github上每次提交的时候将自己所写的内容标记好是什么，然后在后同步的时候就能够清晰。当然也可以在 Last know Good版本时建立分支，需要的时候从最后一个Last know Good版本中导出。

10. 你的项目的源代码和测试这些代码的单元测试，以及其他测试脚本都是放在一起的么？ 修改源代码会确保相应的测试也更新么？你的团队是否能部署自动构建的任务？

 在签入之前，程序员能否自动在自己的机器上运行自动测试，以保证本地修改不会影响整个软件的质量？

在程序员提交签入之后，服务器上是否有自动测试程序， 完成编译，测试，如果成功，就签入，否则，就取消签入？

团队是否配置了服务器，它自动同步所有文件，自动构建，自动运行相关的单元测试，碰到错误能自动发邮件给团队

      回答：由于处在Alpha阶段，完成功能搭建是主要的任务目标，团队目前没有进行单元测试和其他的测试脚本，后期会进行测试，也会找一些组员进行测试体验。

 

 二.作业题，分析比较各种软件构建环境：

①github

优势：

        1.完整的支持Markdown语言，而且支持Emoji表情
        2.支持直接复制图片到页面，会自动上传图片
       3.使用github原生的功能，就可以进行类似评论的功能
       4.支持@用户功能
       5.强调个人，符合hacker更看重名誉/成就感的天性
       6.功能设计简洁实用上手很快，可用性好。

劣势：

　　1.GitHub 使用 git 分布式版本控制系统，于Windows不太友好。
　　2.国内访问速度太慢，经常出现connect time-out。
　　3.不能很好的解决GB2312/GBK，对中文不够友好。
       4.代码保密性差。

②coding

优势：

     1.某分支开发完成后向主分支提交合并请求，得到管理者允许后才可合并到主分支，设置合并请求，便于多人协作管理，保护代码质量。
     2.除了 Git 分布式控制系统，还支持通过 SVN 客户端访问，满足使用 SVN 做代码管理的团队需求。
     3.支持创建、编辑、筛选代码分支，并可将特定分支设为保护分支，方便版本管理。
     4.可选择不同的分支版本进行对比，查看代码改动前后版本差异和文件改动。
劣势：

    1.需要遵守一定的格式来编写模块，也就是说开源的模块大部分都不适用，所以 coding 适合组织自己的代码，就像 jquery 一样。
    2.每个模块即一个变量，会导入到全局之中，所以模块之间需要避免重名，但是支持设置 global，设置了的话所有变量会导入到 global 下。
    3.域名需要备案，需要申请。

③Visual Studio Team Foundation Server

优势：

  1.数据库建模功能包括概念工具、逻辑工具和实体设计工具，以及对使用存储过程、索引、视图等等（涵盖企业数据库开发的各个方面）的集成支持。
  2.强大的语义错误检查功能简化了创建完全兼容模型的过程。
  3.强健而灵活的软件建模
  4.综合数据库开发功能

劣势：

  1.界面设计没有充分考虑空间占用
  2.输出显示过于单调
  3.设置代码格式不够灵活