Gitlab未必最佳实践
背景及目标
公司使用git和gitlab有相当一段时间了，一直只是用来做代码管理，gitlab的很多功能都没有用上。经过一段时间的试用，从上周开始，在一个项目中开始推行gitlab的其他功能，重点是代码评论，里程碑和Issue，主要想达到的目标是：
- 项目节奏能有一个更好的把控。
- 更加有效的进行bug管理。
- 使得code review可以进行下去。
先说说这一周多团队试用的结果：
- bug管理方面的确有了很大的提升。
- 节奏好了点，但是里程碑规划还不够科学，主要项目处在测试阶段，大家对自己的开发时间还没有比较好的把握。
- 单纯试用gitlab的代码评论功能来做code review略显单薄，没有比较好标识是否审核过的状态。
里程碑
里程碑功能主要用来把控项目的进度及节奏，对于我们来说，我们是以周为单位进行跟进。只有项目的master用户有权限设置和编辑里程碑。
- 所有项目以周为单位建立里程碑
- 原则上本周的里程碑不接受新的Issue，除非是严重的bug，需要马上修复
- 除了本周正在进行的里程碑之外，还应该往后规划一个或者多个里程碑
- 里程碑的名字以周五的日期为标识，例如“v2015.06.05” （方便可以根据里程碑的名字对个人的工作进行汇总查看）
Issue
- Issue是谁提出的，谁就要负责跟进Issue的解决情况。
- 每个Issue从属一个里程碑
- 提Issue的时候需要指定给一个人（谁来完成这个Issue），如果有些Issue不知道应该指派给谁，就直接指派给项目负责人
- 一个Issue可以是一个bug，一个建议，一个特性，总之是一项可以指派给一个具体的人的任务。
- 可以自己提Issue指派给自己，例如发现某块代码需要优化或者重构等等。
- 如果是代码相关的Issue，最后在git commit时最好能够关联对应的Issue
- 指派错误时可以重新指派：例如A被指派给一个Issue，但是A觉得这个应该由B来完成，这时A可以把这个Issue重新指派给B
- 当Issue被关闭时，其发起人应该定时（例如每天的某个时间）检查那些关闭列表（或者可以直接查看邮件列表），并检查，如果确实已经完成，可以打上一个已完成的标签，否则可以评论后重新打开该Issue。
- Issue的标题应该基本说明了问题，里面的描述应该更多的是辅助性描述
Code Review
- 大家提交的每次commit都会有记录，可以直接进行diff操作，并且可以评论。
- 除了指定需要相互review的同事，你对谁的代码有兴趣，都可以直接查看或者评论。