前言
自从半个多月前写了这篇破了两万阅读量的博客，让我有点受宠若惊
https://blog.csdn.net/2302_79791164/article/details/139377719
想了想，或许是由于主流APP的普及程度，相较于网页，大伙儿更倾向于使用小程序。
由于二者之间在编写时都使用常见的前端框架和库，组件化开发，事件处理和绑定，所以在接触这个方面的时候就不会那么困难。
最近好久没有写博客了，因为自己琢磨了个项目在写。
本人来自宁波诺丁汉大学计算机科学与技术专业
正文
事先声明
项目仍处在开发阶段，目前正处于后端接口开发和管理端平台的开发阶段。
尚未涉及到用户端的小程序开发阶段，有点标题党了见谅，后续肯定会涉及到。
项目介绍
效果展示：
由于初始准备是想能够上线在校内推广该小程序，但由于接单和评论等功能涉及到增值业务审核需要有相应的营业执照等其他方面的因素。
而且后台管理需要招募人手，处理订单等诸多不可控因素，所以还是决定将这些代码，以开源项目的方式分享给大家。
API接口地址：https://apifox.com/apidoc/shared-4f188e54-2808-4958-9fd1-8acbb4c4072c
小程序项目地址：https://github.com/Pleasurecruise/NottinghamWall/tree/uniapp
管理平台项目地址：https://github.com/Pleasurecruise/NottinghamWall/tree/admin
后端接口项目地址：https://github.com/Pleasurecruise/NottinghamWall/tree/backend
如果你感兴趣的话，可以点击下面的地址更进一下。
会是后续博客中主推的一个仓库！
项目地址：https://github.com/Pleasurecruise/NottinghamWall
求求各位大佬走过路过千万不要错过，点个小星星，谢谢！这对我真的很重要。
关于Github的使用
由于没有什么技术性的知识可以分享，就写一点Github中你可能会遇到的一些问题。（让我凑个字数）
利用分布式版本控制系统（Distributed Version Control System, DVCS）来进行源代码的跟踪更改以及多人员的协同工作是一种常见的开发模式。
①贡献值的记录
当我们用IDEA在本地进行创作的时候，由本地Git仓库推送到远程Git仓库，贡献值（contribution）为什么有的时候不会记录？
首先确保登录的用户名和邮箱和账号匹配。
git config --local user.name
git config --local user.email然后每次在将commit，提交和推送的时候，一定要在作者栏内选择相应的账号。
②Github中的Project是什么
并不是顾名思义Project就是项目管理的意思，实际上这是一个类似看板的工具
用来记录待办事项或者是开发进程的规划，内容是从Issues中引入
③Release和Package有什么区别
Release
- 用途: 用于发布软件的版本。开发者可以创建一个新的发行版来发布重要的版本更新、修复和功能增强。
- 包含内容:
- 代码的特定版本（通常通过标签来标识，如
v1.0.0）。 - 二进制文件、源代码压缩包和发布说明（Release Notes）。
- 可以包括安装包、文档和其他相关文件。
- 代码的特定版本（通常通过标签来标识，如
- 特性:
- 版本控制：Releases 通过 Git 标签标记代码库中的特定点，表示这是一个稳定的版本。
- 历史记录：可以查看所有发布的版本，并下载对应版本的代码或二进制文件。
- 发布说明：发布时可以添加详细的说明，描述版本的变化、修复和新增功能。
Package
- 用途: 用于分发软件包。GitHub Packages 是一个包管理服务，允许用户发布和管理依赖包，可以用于多种包管理器如 npm、Docker、Maven 等。
- 包含内容:
- 软件包文件，这些文件可以是库、工具、应用程序等，依赖于使用的包管理器。
- 特性:
- 包管理：支持多种包管理器，适用于不同类型的项目（JavaScript、Java、Docker 等）。
- 版本控制：可以管理包的多个版本，便于依赖管理和版本升级。
- 私有和公共：可以创建私有包仅供团队内部使用，也可以发布公共包供全世界使用。
- 集成：与 GitHub Actions 集成，可以在 CI/CD 流水线中自动发布和更新包。
比较
| 特性 | Release | Package |
|---|---|---|
| 用途 | 发布软件版本 | 分发软件包和依赖 |
| 包含内容 | 二进制文件、源代码、发布说明 | 软件包文件，取决于使用的包管理器 |
| 版本控制 | 基于 Git 标签 | 基于包管理器的版本控制 |
| 使用场景 | 软件版本发布、下载和历史记录 | 软件包管理、依赖管理和分发 |
| 集成 | 适用于所有 GitHub 仓库 | 与 GitHub Actions、CI/CD 流水线集成 |
| 访问控制 | 公共发布 | 可以是公共或私有 |
④开源许可证之间的区别
MIT License:
- 特点: 非常宽松的许可证，允许代码的自由使用、修改、复制、合并、发布、销售和私有使用，只要包含原版权声明和许可声明。
- 适用场景: 适合希望代码被广泛使用和集成的开发者，无需对衍生作品使用相同许可证要求。
GPL-3.0 (GNU General Public License version 3.0):
- 特点: 强调开放源代码，要求任何基于或修改的软件必须以相同的GPL许可证发布，并提供源代码。
- 适用场景: 适合希望确保代码开放源代码，并保护开发者免受将私有代码闭源的风险。
Apache License 2.0:
- 特点: 允许代码的修改和衍生作品，允许将修改后的代码以任何形式分发，包括闭源，并且无需开源代码。
- 适用场景: 适合需要在开源和商业闭源之间取得平衡的项目，同时保持对知识产权的一定保护。
BSD License (包括BSD-3-Clause和BSD-2-Clause):
- 特点: 类似于MIT许可证，它也是一种非常宽松的许可证，允许代码的自由使用、修改、复制和分发，无需特别提供原始代码或衍生物的许可。
- 适用场景: 适合希望代码被广泛使用和整合，并且不希望对衍生作品施加太多限制的开发者。
尾声
后续由于该项目的编写，以及参加的校内的一些项目，可能不会更新的那么及时。
计划以这个校园墙项目为主要的例子，从编写中遇到的一些功能入手，比如话题评论的发布，订单功能的开发，第三方接口的调用，支付功能的处理，验证码的发送的等多个功能，来进行后续的博客。
