1.GitHub版本更新流程
题目：请参照此文：http://www.ruanyifeng.com/blog/2015/12/git-workflow.html 制定本组项目的GitHub版本更新流程。
广泛使用的工作流程有Git flow、Github flow和Gitlab flow。比较了三种工作流程，我们选择了Github flow流程。有以下几点原因：
1.项目规模较小，用Git flow的简化版就能达到我们的需要。
2.它长期只有一个分支 master，利于管理
3.因为项目要不断修改，不断改进，需要“持续发布”
4.小组成员编码能力有限，很多地方需要大家一起协作，所以不便分成很多分支
（引用：http://www.ruanyifeng.com/blog/2015/12/git-workflow.html）
具体Github flow更新流程操作如下：
第一步：创建新的分支
首先我们用git checkout -b flowtest 命令 创建一个分支，git branch 命令可以看出现在有两个分支，并且现在在flowtest 分支。
第二步：发起一个pull request
以代码规范文档为例。首先将文档在本地创建之后，用git add、git commit、git push命令之后，上传到远程分支flowtest中。这时，这个分支目前的工作已经完成，可以进行合并操作了。因为是多人协作，所以我们要通知其他Collabrators。我们可以在Github网站上看到pull request页面。这时Pull request数量还是0。
此时发起一个pull request有两种方法。一个是点开pull request页面，读完introduction之后，会有一个create a pull request的链接，点击直接可以发起。
另一种方法是在code选项卡这点击New pull request按钮。
最后在Open a pull request页面填写相关的文字。（文档支持markdown）就可以发起一个pull request了。
第三步：评审文档、代码
当一个pull request发起后，小组的所有成员都可以用自己的账号看到这个请求。这时，大家可以提交自己的想法，有什么需要改进的，如果觉得已经达到要求，就可以通过Merge pull request按钮，将这个分支merge到主分支。
第四步：删除分支
pull request被接受后，这个分支就没有作用了，此时我们将该分支删除即可。
这时，分支就被我们删除了，同事pull request也被我们关闭了。这时就剩下master主分支了，可以继续进行开发。但我们也可以随时查看之前的pull request的操作历史。
因此，以后我们小组的Github版本更新流程就采取Github flow的方式，具体操作就按照上面的说明来操作。
2.代码规范、GitHub提交源码标准
题目：制定本组的代码规范、GitHub提交源码的标准。
①代码规范
经讨论，我们决定用ajax+C#.net开发网页，用Visual Studio IDE开发。因此，我们制定了C#的代码规范。
因为代码规范特别多，就不在这一一列举了，以下是代码规范的简单目录。具体的代码规范，请前往https://github.com/Hahalovejava/Calculate 在Github 中，我们上传了C#_code_standard.docx和Code_Standard.md两个版本的代码规范。
一、代码注释
1、代码注释约定
2、模块头部注释规范
3、方法注释规范
4、代码行注释规范
5、变量注释规范
二、命名规则
1、命名的基本约定
2、类和接口命名
3、方法命名
4、变量命名
5、组件名称缩写列表
三、其它规范
1、编程风格
2、空白
3、错误处理
4、其它
②GitHub提交源码标准
1、创建自己需要的分支，分支命名要能体现是谁创建的分支，或者需求是什么
2、clone主分支上的文件到本地，在本地，自己的分支上进行自己的工作。然后通过git add、git commit、git push上传到远程GitHub中。要注意的是，一定要先传到自己创建的分支上，先不要直接传到主分支master上。即 git push origin <分支名>（不可以是master）
3、发起pull request，等待其他小组成员的评价和确认。这里注意，每次必须要让每位小组成员回复一下。这样能确保每个人确认项目的进度。如果着急需要进行下一步的时候，可以微信，短信通知小组其他成员。
4、由组长将分支merge到master上，并delete该分支
注意：每次进行操作的时候，必须写好comment，便于以后查看。
3.例会
题目：组长组织每周例会（可以使用群微信群试验一下每天沟通项目开发进度的方法）需要有证据能够在博客上公布
我们四个因为住在毗邻的两个宿舍，沟通特别方便，所以多数情况以线下交流为主。但同样的我们在9月7日建立了微信群，便于交流。
①第一周
创建微博后，和大家首先沟通了第一篇自我介绍的博客，定下了大体的方向，由组长进行整理。
之后，我们就第一周的作业进行了分工。本着我们四人小组的原则，题目分得相当随意~
②第二周
第二周大家都是分别在进行学习，线下沟通，调试和修改bug都是在线下。相应的线上交流有些欠缺。
通过线上交流，我们发现了博客园账号不能同时编辑修改的问题。这个我们也反映在了上周的博客中。之后将小组帐号变成了组织也都及时在微信上通知了大家。所以说及时沟通是相当重要的~
③第三周
第三周我们首先上网查找资料，然后由晓丽同学整理了代码规范，并编辑成word文档。之后由组长上传到github上并制定了github提交源码标准。之后小组对项目的时间上和分工上做了一下讨论
4.分工和时间计划
题目：根据邹欣老师的教材相关内容，确定小组成员的角色，细化项目需求、时间计划、列出产品积压工作项和预计开发时间
①小组成员角色
根据邹欣老师的教材相关内容，和我们小组自身的情况，我们确定了团队的模式为功能团队模式（Feature Team)。因为小组成员的编码能力有限，都有待提高，所以我们选择功能团队模式。就是小组成员之间平等协作，共同完成一个功能，在这个功能完成之后，再一起去完成下一个功能。这个模式需要小组内的交流比较频繁，我们四个住的比较近，每天沟通非常方便，也很适合这种模式。
之后我们按照MSF基本原则，大家共同讨论制订了大家的小组成员角色。
②细化项目需求
经讨论，我们暂时将项目的需求进行如下的细化。剩下的细节，功能完善还要在不断开发的过程中进行完善。
③时间计划和预计开发时间
④产品积压工作项
目前的产品积压工作项是用户的需求还不够完善，目前只考虑到用户是小学生，应该考虑到很多小学生可能还不太会使用电脑，可能由家长来操作。本周要将需求做的更完善，要调查取证。同时小组成员的环境有的还没有完全配置成功，这周要尽快将环境匹配好。Github的使用率还有待提高，大家已经学会了使用，要充分利用起来。