BUAA-2023软件工程团队项目—

项目
这个作业属于哪个课程	2023北航敏捷软件工程
这个作业的要求在哪里	团队项目-代码管理准备
我们在这个课程的目标是	学习并实践软件工程开发的方法论。在把握整体流程和内容要素的基础上实践细节，培养开发技术、开发思维、团队协作等能力。
这个作业在哪个具体方面帮助我实现目标	进行团队代码管理的规范化实践，为后面的开发做好准备

零、团队代码仓库地址

Fork主仓库的仓库地址：Agile - TVC

删除敏感数据后新建的代码仓库地址：Agile - TVC - Delete

一、情况说明

任务看板与团队协作

本次任务的Maintenance是PM——Enqurance。

我们使用Notion实现了一次规模较大、周期较长、任务量不大的团队合作任务，团队成员对这一管理方式感到满意。我们在Notion上进行任务的布置、签到和完成情况的展示，同时附有一些比较困难的操作的说明。在后续的开发中，或许可以布置一个QA表和技术交流区以提高合作的效率。

团队代码管理任务布置链接：Agile - 代码管理任务

删除开发分支

我们在处理完一个PR后，通常会把额外检出的分支删除。在实际开发中，我们不一定会删除每一个额外分支，可能会保留一些比较重要的分支以便于代码回滚和检查。

HotFix

我们使用bfg.jar作为删除敏感信息所用的工具。在修复之前，我们在main分支的commit历史记录下找到了助教插入的SUPER-SENSITIVE-DATA.txt文件。

随后，我们clone了一份远程仓库代码并使用bfg脚本对该敏感文件进行删除。经检查后发现commit信息当中的确不存在该文件了。

误操作

在本次任务当中，由于对Git工具不熟悉，我们出现了一些误操作的情况：

Commit信息格式有误。部分团队成员（记不清了）在提交commit信息的时候出现了格式错误
代码复审不严格。xkslttt同学疏忽了任务要求，发起了一个半对半错的PR，PM在合并的时候并没有发现，还是合并了这个PR，最后xkslttt同学修复了这个bug并且重新发起了一个PR
修复冲突失误。wzy2001wzy同学在进行feature/game-2任务时忘记更新dev分支，把qmy同学的代码丢弃了，并发起了一个错误的PR。好在PM发现并及时解决了
不会发布版本。PM在发布Task.1版本的时候不知道Release操作，在Task.2版本才想起来。
部分issue忘记和PR直接关联。

这些错误可能会导致Git仓库的历史信息和助教所的期望不符，故而在此说明。

二、团队代码管理安排

DevOps选择以及分工

我们计划选择Github作为代码托管平台和CICD平台，选择腾讯云作为远程部署平台。各个小组的成员将会共同提前商议好开发环境以及主要工具，并且对开发时下载的各种工具包进行记录，便于在CICD和云服务器上进行部署。

对于代码版本管理，我们计划选择三名成员进行Pull Request的维护（PM，以及一名前端成员和一名后端成员），以便能够“小步快跑”地维护main分支。

Name	Obligator
PM	Enqurance
前端	Xu Kai
后端	WAN

团队代码管理方案

我们的团队代码管理方案采取课程组推荐的方案，并且布置在团队仓库当中。我们一致认为这是一个比较好的方案，并且对其中的一些可能造成理解偏差的内容进行了修改。

Agile - 代码管理方案

代码审查与发布

PM和PR的负责人员在合并PR之前需要对代码进行复审。此时，需要围绕新提交的代码考虑以下的问题：

代码质量：如可读性、可维护性、可扩展性、性能等方面。
安全性：代码审查可以帮助团队发现潜在的安全漏洞和风险，并采取措施来修复它们。
一致性：代码审查可以确保团队中所有成员都遵循相同的编码规范和指南，从而实现代码的一致性。

另外，其他的开发人员也要及时了解代码的变动与修改内容，以便他们维护自己的分支和代码功能。

代码在发布之前，需要经过一以下的步骤

代码审查：代码通过团队内部的审查流程，确保质量、安全性、一致性等方面。
功能测试：对代码的基本功能进行测试。
部署：代码部署到目标环境中。
后期维护：代码发布后，需要对上线的服务进行维护，及时修复错误。

代码风险管理

团队成员操作失误

虽然本次任务每一步操作都不难，PM在实践中发现，大家对Git工具的熟悉程序不尽相同，从而产生了各种各样的问题。几个比较关键的问题是：

合并分支时操作错误。有的同学合并操作出现错误，没有rebase就进行操作，导致别人写的代码丢失了
合并PR时不规范，代码审查不够严格。PM犯了一次这样的错误，导致有一些PR产生的顺序不符合要求
commit信息不规范。这里包括描述格式不规范、commit内容说不清变动等问题

当然，多踩了几次坑之后，大家对操作的熟悉程度逐渐提高了。有部分同学操作经常出现错误的情况下，需要额外的帮助。

这一类问题可以通过培训、检查减少，并且通常不会产生致命的错误。为了降低管理风险，在开发到一定程度时也需要整理一下开发分支，确保分支的简洁。

代码安全漏洞

如果提交历史记录中出现了敏感数据和信息，需要通过bfg等工具删除历史信息，同时更换关键信息，及时止损。

开发人员在编码的时候，也要注意不要引入关键的信息和危险的第三方库，避免代码安全从内部被攻破。

代码托管平台和云服务器都有可能被黑客攻击。在这种情况下，保本地备份是最好的办法；设置更强的服务器密码也会有帮助。

三、心得

git rebase和git merge

git merge 会为合并的目标分支创建一个新的提交节点，这样的好处是合并的信息“有迹可循”；当然，坏处就是分支历史记录会变得多而杂乱。

git rebase 可以将一条分支的更改应用到另一条分支的顶部，而不是创建一个新的合并节点。这种方法可以保持分支历史记录的简单和清晰（多出来的分支被嫁接到主分支之上），但可能会丢失一些合并信息。相较于git merge，git rebase操作需要使用者更加专注于操作的规范性。

在进行rebase操作的时候，最好是将最新的公共分支rebase到自己的开发分支上，并且遵循rebase的黄金法则，不要再在公共分支上执行rebase操作。
PR（Pull Request）

经查询资料后，在处理PR的时候（尤其是多个PR），要遵循一些原则。
1. 按照紧急程度处理PR。按照提交的信息，优先处理紧急程度高的PR。
2. 根据复杂程度处理PR。尽早合并易于合并的PR，这可以减小合并时发生错误的成本
3. 在发起PR和处理PR的时候相互告知
4. 在处理完PR后，可以删除不重要的分支
PR的处理由三位同学负责，这样能够覆盖更多的时间，而不需要一位同学每隔一小时就刷新一次Github。

在所有成员都发起PR后，我们经过讨论，认为应当先处理新增文件的PR、再处理BugFix的PR、最后处理风格修改的PR，这样可以减少冲突发生的可能性。不过在实际开发中，先处理新功能的PR还是先处理BugFix的PR取决于具体情况。