[T.4.5] 实验课/团队项目

项目 内容
这个作业属于哪个课程 课程社区
这个作业的要求在哪里 作业要求
我在这个课程的目标是 构建进行软件团体开发的流程，确定团队协作流程
这个作业在哪个具体方面帮助我实现目标 通过实验作业，实操了团队开发与项目管理流程，为后续合作开发打下了基础。

必要的内容

代码仓库链接：
代码仓库分支图示（仅展示本次实验任务后的更改）：

image

 

需要说明的情况：
  • 我们处理 Pull Request 时，先是使用了 Merge and Commit，后选择更换为 Squash and Commit。在提交记录中，可以看到这两种处理 PR 操作的不同记录。
  • 我们没有删除 Pull Request 对应的 feature 分支。
  • 在处理 hotfix 部分的任务时，彭子峻同学错理解成了从 main 分支 checkout 出 release 分支，并只在 release 分支上进行修改。后仔细品读指导书中 “依照分支规范的说明，在 release 分支上进行修复” 的隐式含义后，他惊讶地发现，流程实际上应该是这样的：这是一个 Bug，应该提 Issue，完成修复，然后提 PR 合并到 release 分支上。无奈，他选择在 Github 上删除一次 release 分支，重做一遍。此时 git 记录仍然记录下了第一次处理 release 分支的记录，包括：从 main 分支 checkout，在 release 分支上直接更改，后还选择把 dev 合并入 release.... 对此，彭同学对这种隐式声明深感无奈，并对自己弄乱的 git 提交记录面露难色...

心得体会

代码协作时，需要有人发号施令，统一进行 git 操作吗？

在我们进行实验的时候，我们事实上是有人统一告诉大家，我们所有的 Pull Request 已经处理好了，大家可以推进下一个任务了！这样，但现实的项目协作是这样吗？
看起来并不是。著名的开源项目中，有 Pull Request 未处理，而其他 Contributor 继续工作的例子比比皆是。特别是对于 Linux 这种体量的开源项目，有 Pull Request 没处理更是常态。
不难发现，此时有一个人同时“发号施令”，在处理完所有 Pull Request 之后，再告诉大家“可以继续”，在此之前不要做任何事情这样是不现实的，因为：
  1. 这样会严重拖慢开发效率；
  2. 在协作规模扩大之后，通知所有协作者统一进行工作，并不是一件好办的事情。
这就是协作规范要做的事情了。在有了这些规定之后，事情就会好办很多：
  • 开发者必须基于某个现有分支，在自己创建的分支上进行开发。如果对代码仓库的分支整洁度有要求，开发者可能还要先 fork 一份代码仓库，再创建自己的分支，进行开发。
  • 所有到主（开发）分支的新提交，都要开 Pull Request，在经过 Code Review 后再并入主（开发）分支。
  • 在提交 Pull Request 之前，开发者需要及时拉取主分支的上游更改，由功能开发者自行解决可能带来的冲突。这是去掉我们前述的“发号施令者”的关键。

Pull Request 的合并方式？

在处理 PR 时，我们可以见到三种并入目标分支的方式，他们的行为各有不同：
  • Merge and Commit：与 git merge 的效果一致，创建一个 Merge Commit，关联起目标分支和源分支。此外，merge 的 Commit 作者一般只有 PR 的处理者。
  • Squash and Commit：将源分支上的更新，合并到一个单独的 Commit，提交到目标分支。Commit 信息中一般会自动把 Co-author 信息补上。
  • Rebase and Commit ：与 git rebase 的效果一致。效果是，目标分支上，加入了源分支上所有的更新 Commit。
我们一开始选择了 Github 处理 Pull Request 的默认选项，即 Merge and Commit。
后经有团队协作经验的李奕宽同学指出，现代工程开发，为了保持主分支的提交记录简明，Squash and Commit 使用得更多，且这样做更有利于进行项目管理。对此，我们深以为然，在实验的后续过程中均采用了这种方式。

Pull Request 处理以后？

在 Pull Request 处理之后，PR 的源分支仍是被保留的。长此以往，这些 feature 分支会导致代码仓库中的分支数量持续上升，并不利于主分支的查找和代码管理。
因此，这样的一个协作规范应该被确立：
  • 每实现一个功能时，均需从主开发分支 dev 中 checkout 一个 feature 分支，在其上完成功能的开发。
  • 完成开发后，提交 Pull Request，请求将 feature 分支的内容合并到 dev 分支中。
  • Pull Request 被合并后，应该删除这些 feature 分支，且此 feature 分支上不应再有任何进一步的开发工作。 如果有，则跳到上述规范的第一步。
 
posted @ 2026-04-21 19:58  ISET  阅读(12)  评论(0)    收藏  举报