电子公文传输系统团队任务2-需求分析

Git的工作流：

在协作中，通常使用的工作流有一些不同的模型，但最常见的是Git Flow工作流，它基于分支管理。Git Flow 包括以下几个主要分支：

1. Master分支：这个分支包含最近发布到生产环境的代码，即稳定版本。通常，只有通过经过充分测试和审查的代码才会合并到 Master 分支。

2. Develop分支：Develop 分支是主要的开发分支，包含所有要发布到下一个 Release 的代码。这是开发团队的主要集成分支。

3. Feature分支：Feature 分支主要用于开发新的功能。每个新功能通常都会有一个对应的 Feature 分支。一旦功能开发完成，这个分支会合并回 Develop 分支，然后被删除。

4. Release分支：当准备发布一个新版本时，会基于 Develop 分支创建一个 Release 分支。这个分支用于解决小问题、版本号更新等准备工作。完成之后，会合并回 Master 和 Develop 分支，然后被删除。

5. Hotfix分支：Hotfix 分支用于修复在生产环境中发现的紧急 Bug。一旦修复完成，会合并回 Master 和 Develop 分支。这确保了 Bug 修复同时也包含在下一个 Release 中。

这个工作流程会根据我们小组具体的项目需求进行适当的调整，但其实大多数情况下git的主要工作流程就是这样的。

这些分支管理策略不仅确保我们小组团队协作，合理分工。同时保持项目的稳定性和可维护性。

主分支

实际开发中，一个仓库（通常只放一个项目）主要存在两条主分支：master与develop分支。这个两个分支的生命周期是整个项目周期。就是说，自创建出来就不会删除，会随着项目的不断开发不断的往里面添加代码。master分支是创建git仓库时自动生成的，随即我们就会从master分支创建develop分支，如下图所示。

• master：这个分支最为稳定，这个分支代表项目处于可发布的状态。

例如王二狗向master分支合并了代码，那就意味着王二狗完成了此项目的一个待发布的版本，项目经理可以认为，此项目已经准备好发布新版本了。所以master分支不是随随便便就可以签入代码的地方，只有计划发布的版本功能在develop分支上全部完成，而且测试没有问题了才会合并到master上。

• develop：作为开发的分支，平行于master分支。

例如王二狗要开发一个注册功能，那么他就会从develop分支上创建一个feature分支 fb-register（后面讲），在fb-register分支上将注册功能完成后，将代码合并到develop分支上。这个fb-register就完成了它的使命，可以删除了。项目经理看王二狗效率很高啊，于是：“二狗你顺带把登录功能也做了吧”。二狗心中暗暗骂道：日了个狗的，但是任务还的正常做，二狗就会重复上面的步骤：从develop分支上新创建一个名为fb-login的分支，喝杯咖啡继续开发，1个小时后登录功能写好了，二狗又会将这个分支的代码合并回develop分支后将其删除。

支持分支

这些分支都是为了程序员协同开发，以及应对项目的各种需求而存在的。这些分支都是为了解决某一个具体的问题而设立，当这个问题解决后，代码会合并回主分支develop或者master后删除，一般我们会人为分出三种分支。

• Feature branches：这种分支和我们程序员日常开发最为密切，称作功能分支。

必须从develop分支创建，完成后合并回develop分支

如下图所示。

• Release branches：这个分支用来分布新版本。

从develop分支创建，完成后合并回develop与master分支。

这个分支上可以做一些非常小的bug修复，当然，你也可以禁止在这个分支做任何bug的修复工作，而只做版本发布的相关操作，例如设置版本号等操作，那样的话那些发现的小bug就必须放到下一个版本修复了。如果在这个分支上发现了大bug，那么也绝对不能在这个分支上改，需要Featrue分支上改，走正常的流程。

实例：王二狗开发完了登录注册功能后决定发一个版本V0.1，那么他先从develop分支上创建一个Release 分支release-v0.1，然后二狗在这个分支上把版本号等做了修改。正准备编译发布了，项目经理说：“二狗啊，你那个登录框好像向右偏移量1个像素，你可以调一下吗？”二狗心中有暗暗骂道：日了个狗，但是。。。你们懂得，功能还的正常改。不过二狗发现这个bug特别小，对项目其他部分不造成不可预知的问题，所以直接在release分支上改了，然后愉快的发布了版本1.0.版本上线后，二狗将这个分支分别合并回了develop与master分支，然后删除了这个分支。

• Hotfix branches：这个分支主要为修复线上特别紧急的bug准备的。

必须从master分支创建，完成后合并回develop与master分支。

如下图所示：

git代码提交

1. 更新本地的 Develop 分支： 在你开始新的工作之前，首先确保你的本地 Develop 分支是最新的。你可以使用以下命令：

git checkout develop
git pull origin develop

这将确保你的本地 Develop 分支包含了团队的最新更改。

2. 创建并切换到 Feature 分支： 创建一个新的 Feature 分支，以进行你的工作。命名这个分支可以根据你的项目规则，通常是与功能或任务相关的名字。例如：

git checkout -b feature/new-feature

3. 开始工作并频繁提交： 在 Feature 分支上进行你的工作，按照你的项目需求和开发流程逐步实现功能。确保你经常提交你的更改。使用以下命令：

git add .
git commit -m "描述你的更改"

这将保存你的更改到 Feature 分支。

4. 同步 Develop 分支： 为了确保你的 Feature 分支与 Develop 分支保持同步，你可以定期将 Develop 分支合并到你的 Feature 分支：

git checkout feature/new-feature
git merge develop

这将确保你的代码基于最新的 Develop 分支。

5. 完成并提交 Feature 分支： 当你的功能开发完成时，进行最后一次提交：

git add .
git commit -m "完成新功能"

6. 推送到远程仓库： 确保将 Feature 分支的更改推送到远程仓库：

git push origin feature/new-feature

7. 发起 Merge 请求（Pull Request）： 在 GitLab 或其他代码托管平台上，导航到你的仓库，然后选择 Feature 分支，并发起 Merge 请求。这将通知团队成员来审查你的代码。

8. Code Review： 等待团队成员对你的代码进行审查。他们可能会提出建议或需要你进行一些更改。

9. Merge： 一旦你的 Merge 请求通过审查，团队成员会将你的代码合并到 Develop 分支。

代码审查

由仓库管理员进行统筹安排，审查各个issue的完成情况，各个代码的测试使用情况。

代码合并

具有主要开发者权限，可以进行最后的合并操作，feature的分支合并到dev分支，dev分支合并到release或master分支。
需要添加标签、里程碑！方便后面的成员管理。

团队任务计划

（一）执行计划

• Issue 使用： Issue 是一个强大的工具，可以用来记录各种信息和计划。在你的团队中，你可以使用 Issue 来制定 OKR（Objective and Key Results，目标与关键成果）、记录项目讨论、发布任务、积累重要的技术信息，或者分享创意想法。

• 主要应用：

  • 制定周目标（OKR）：使用 Issue 来记录每周的工作目标，可以在其中列出需要完成的任务。
  • 发布任务：团队成员可以认领任务并将任务状态更新为正在做、待认领或已完成。
  • 发布公告：记录重要的技术点或项目公告，供团队内部参考。

（二）里程碑

• 里程碑（Milestone）： 用于标记代码提交和任务发布的阶段，有助于了解项目的进展情况。通过将任务和代码与里程碑相关联，团队可以清晰地看到目前项目所处的阶段。

• 应用场景：

  • 标记每个迭代周期或版本的发布。
  • 确定项目的重要时间点，如测试、审核和上线日期。
  • 了解项目整体进展情况，查看每个里程碑的完成情况。

（三）标签/标记

• 标签/标记： 可以用于对任务进行分类、指定优先级、追踪参与的成员以及标记任务状态。

• 主要应用：

  • 标记优先级：可以使用不同的优先级标签，如 "优先级1"、"优先级2"、"优先级3"，以便团队了解任务的重要性。
  • 标记参与的成员：通过为任务添加标签，可以查看每个成员认领了哪些任务以及任务的进展情况。
  • 标记任务状态：使用标签来指示任务的状态，如 "正在做"、"待认领"、"已完成"，以方便团队协作。
  • 标记任务类型：可以将任务分类为不同的类型，如 "文档"、"部署"、"公告"，以区分任务的性质和需求。

需求分析

参考蓝墨云班课中资源，撰写本项目的《需求规格说明书》，并提交至码云。

在随笔中附《需求规格说明书》的Git链接（markdown文件及pdf文件，tip：pdf可由markdown转pdf工具得到）。
链接如下：https://gitee.com/xiao-zhancheng/requirement-specification/tree/master/

撰写《需求规格说明书》的工作流程、组员分工和组员工作量比例

工作流程

1. 小组讨论，确定基本方向
2. 组长将任务切分为五部分，小组成员认领
3. 相关负责同学汇总和提交
   分工
   · 张顺扬：统筹安排和负责验收标准部分
   · 徐元琦：负责用户场景部分和功能描述部分
   · 沈楗翔：负责管理团队公众号，汇总小组成员介绍博客。负责引言部分
   · 李欣怡：负责管理团队git仓库，负责界面设想部分
   · 肖权城：负责管理团队git仓库和学习相关知识，负责撰写基础技能部分