第3~6章作业
参照阮一峰:Git 工作流程 制定本组项目Github版本控制更新流程
结合该文以及Git分支操作一文学习到以下内容：
在实际开发过程中经常使用的工作流程有
- Git flow
- Github flow
- Gitlab flow
Git flow是较早采用的流程，项目主要存在两个长期分支主分支(master)和开发分支(develop),前者用于存放对外发布的版本，任何时候拿到这个分支都是稳定的发布版，后者用于日常开发，存放最新的开发版。其次存在三种短期分支，功能分支(feature branch)、补丁分支(hotfix branch) 和 预发分支（release branch),一旦开发完成，它们就会被并入develop分支。个人认为很复杂但是利于修改和各种补丁操作，而且对于每种操作都有十分明确的划分，便于开发者理解各处修改的目的。
Github flow是Git flow的简化版，长期分支只有master。根据需求，拉出新分支不能区分功能或补丁分支。而其最大的优点是可以“持续发布“产品，但是不易于修改。
Gitlab flow是前两者的综合。Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支master，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。作为妥协过后的分支策略，综合了前两者的有点，但是要熟练掌握分支后才能实施。
本次项目开发，我们将会采用介于Git flow 和 Gitlab flow之间的分支策略管理方式。采用两个主要分支主分支(master)和开发分支(develop) 其中主分支用于发布上线产品，开发分支用于管理所有开发过程中的所有操作。在产品开发过程中，devlop分支的作用相当于 Github flow中的主分支功能。略微有所区别的是所有新分支的拉出除了功能性分支意外，主要的分支操作是小组内部成员每个人都需要一个独立不可见的分支向develop分支提交相应的更新。
基于此，我们将清空已有的远程版本库，重新创建新库用于管理代码和文档(代码也将重新构建提交)。
基本的分支操作：(个人分支以bruce为例)
$ git checkout develop #检出到开发分支
$ git checkout -b bruce
$ git add [update]
$ git commit -m ""
$ git push origin
//更新操作:
$ git fetch develop
$ git checkout -b bruce origin/bruce
// add something
$ git checkout develop
$ git merge bruce
$ git push origin
注：注意冲突的解决
文档及代码提交规范
注：本文代码规范以Java为例
1、排版详细规定：
- a) 程序采用缩进风格，缩进采用4个空格或一个Tab，其中一个Tab的缩进距离要设置为四个空格的距离。
- b) 分解符“{”应在引用他们的语句后面，间隔一个空格，“}”独占一行与引用他的语句对齐。在函数体的开始，类和接口的定义，以及if，for，do，while，switch，case语句的程序中都要采用如上的缩进方式。
eg：
for(...) {
...
}if(...) {
...
}
- c) 较长的语句、表达式或参数建议分成多行书写，进行适当缩进，可以参考eclipse的代码自动调节功能。
- d) 一行只写一条语句。
- e) 对于if, for, do, while, case, switch, default等语句自占一行，且其执行语句无论多少都必须要加上括号“{”和“}”.
eg:
if(t == 0) {
...
}
- f) 建议相对独立的语句块中间加空行。
- g) 采用松散的方式编写代码。在两个以上的关键字、变量、产量进行对等操作时，它们之间的操作符之前、之后或者前后都要加空格；对于非对等操作时，如果是关系密切的立即操作符则不加空格。
eg:
int a, b, c;
a = a + c;
a *= 2;
fglag = !isEmpty;
i++;
p.id = id;
- h) 访问限制一致的放在一起，但是不要求顺序。
eg:
类定义 {
私有属性
共有属性
保护属性
私有方法
共有方法
保护方法
}
3、注释详细规定
- a) 注释必须都是用于解释下面一行或多行的类、属性、方法或语句。注释不放在语句的后面或下面。
- b) 类、方法都要写注释，包括类或方法的功能作用、参数、返回值类型等。
- c) 类和接口的注释放在package关键字之后，class或interface关键字之前。
eg:
package com.htzy.pack; /** *注释内容 */ public class Message
- d) 注释注意排版，与被注释的内容首字母对齐
eg:
public void example() { // 注释 CodeBlock One // 注释 CodeBlock Two }
- e) 建议注释与上一行代码用空格隔开。如上。
- f) 对于分支，变量等写必要注释。
- g) 边写代码边注释，修改代码同时修改注释，删除无效过时注释。
- h) 注释要有价值，不要写无用注释。
- i) 注释中不用缩写。
- j) 要通过函数或过程、变量、结构等的正确命名以及合理组织代码的结构，使代码成为自注释。
- k) 在代码的功能、意图上进行注释，表明业务逻辑，提供有用的额外的信息。
- l) 在程序嵌套逻辑复杂时可以在结束行的右方加注释标记，唯一的注释在语句后面情况。
- m) 出于维护考虑，建议注释多使用中文。
4、命名详细规定：
- a) 采用Java常用的驼峰命名法，注意首字母大小写采用Sun公司推荐的Java常用方法。
- b) 命名要有意义，采用完整的英文描述。
- c) 共有变量和局部变量相同时用this区分。
- d) 组件类的命名采用组件类型结尾。
eg:
Application——MainApp
Frame——TopoFrame
- e) 含有集合意义的属性名，尽量包含其复数的意义
eg:
customers, orderItems5、项目开发规范
- a) 在没有特殊情况下，要求项目文档必须完整，要先进行需求，设计等文档的编写，在没有详细设计的情况下，不允许编写代码。
- b) 项目在开发过程中，要保证文档完整并实时更新，添加版本号说明，最后一个版本是最权威的版本。
- c) 详细设计要求
- i. 要求有对改模块的需求描述，功能概要描述。有各种图示说明问题。要求有对各种图的解释。
- ii. 设计的详细程度要求到变量名，接口，类名等。
- iii. 要求有最晚交工时间。
- iv. 要求在文档中写明设计人，时间，版本号等必要信息。
- d) 尽量满足OO设计原则：
- i 单一职能原则
- ii 开闭原则
- iii 里氏替换原则
- iv 依赖倒置原则
- v 接口隔离原则
- vi 最小知识原则
项目管理
人力管理
- 小组成员角色与职责如下表显示:
- 计划进度表如下图：
会议记录
前几周开会均在图书馆进行小组会议，没有记录！线上交流将在以后几周尝试。
