Day 20：开源个人项目时的一些注意事项

一、前言

首先声明这只是我的个人经验，我也没有上千 star 的热门开源项目，也不是什么开源大佬，这篇文章只是为了分享我在摸索开源的时候总结的一些小经验。如果你有一些更好的建议，希望大家一起讨论讨论。我将以我的这个项目来展开。github.com/Caoshenyang...

二、项目启动前：想清楚再开始

我这里说的开源是指，把项目当做一个完整的产品来做，而不是将仓库设置成 public 。

2.1. 明确项目目标与价值

我们做开源首先要明确项目的目标与价值。

在这个专栏的开篇我就提到过，要么提高自身能力，要么提高个人影响力，要么带来收入，哪怕是收入的可能性，不要"无私奉献"，我并不是说"无私奉献"不好，而是如果你一直"无私奉献"，当热情被消耗完之后，这个项目大概率走不长远。

以我这个项目为例：

项目的价值在哪里？

作为这个专栏的落地案例，提高这个专栏的真实性
尝试不同的架构，提升自身技术能力
做一个最小化模版，方便后续个人业务拓展

其实本质就是围绕了以上几点，提高个人影响力，为以后做付费服务做铺垫（这里我也不装高尚😄），本质就是如此，尊重自己的付出。

2.2. 选择合适的开源协议

对于开源协议这个我不细说，可以看一下 gitee 的介绍，这个是比较清晰的。根据自己情况选择即可。

2.3. 做好市场调研

相比目前市面上的产品，你的东西是否有亮点，对于类似产品，你的项目是替代、补充还是与他们集成。

还是以我这个项目为例，首先作为专栏的落地项目，毫无疑问，具有不可替代性，从这方面出发没有竞品。其次，相比于市面上的企业级的开源后台管理系统，我这个更倾向于个人，更加轻量化，结构更简单，不需要为了兼容各种情况做很多兼容性开发，这样代码结构会很清晰。很容易快速上手，而且完全在个人可控范围内，一个人也可以维护的过来。

三、项目初始化：打好基础

3.1. 创建一个清晰专业的 README.md

README 是你的项目门面，必须精心设计。

它应该包含：

项目名称和 Logo
一句话简介
详细的功能特性列表
安装和使用指南（快速开始）
截图、动图或演示链接（视觉效果至关重要）
指向更详细文档的链接

你不用刻意去做这些，等到上述一切都准备好才开始项目，应该是先有项目，再去根据项目不断完善他。

四、开发与维护：保持项目健康

这里需要注意：如果项目主要作为个人作品、教程或实验性项目存在，其目的不是构建社区，而是展示某种技术或思想。我建议是选择不接受 PR , 从这点来说，这个项目并不能说是一个真正的"开源项目"，而是一个"开放源码的个人作品"，在显眼的地方加上声明：❗️注意：本仓库不接受 Pull Request ，请改为提交 Issue 来描述你的建议或问题。

五、代码提交时的一些细节

5.1. 注意数据安全

当我们准备将项目托管到 GitHub 上的时候，一定一定要注意，特别是我们的配置文件，有的时候本地开发图方便，直接就把一些账号密码，签名密钥，直接写在配置文件里了，稍有疏忽就会提交出去，直接裸奔。

正确做法应该是这样的：通过读取配置的环境变量来做。

yml 复制代码

spring:
  application:
    name: ez-admin-springboot4
  datasource:
    url: jdbc:postgresql://${DB_HOST:localhost}:${DB_PORT:5432}/${DB_NAME:ez_admin_db}?useUnicode=${DB_USE_UNICODE:true}&characterEncoding=${DB_CHARSET:UTF-8}
    username: ${DB_USERNAME:postgres}
    password: ${DB_PASSWORD:postgres}
    driver-class-name: org.postgresql.Driver
  jpa:
    hibernate:
      ddl-auto: update
    show-sql: true
    properties:
      hibernate:
        dialect: org.hibernate.dialect.PostgreSQLDialect
        format_sql: true
    open-in-view: true  # 显式启用 OpenEntityManagerInView（消除警告）

5.2. 提交时账号配置

先看下面这张图，首先声明这个项目只有我一个人维护

注意到两点：

明明是我自己的 Github 账号提交上去的，为什么不显示头像
为什么有的提交记录上有 Verified 标签，有的没有。

第一点： 我配置了 GitHub 的授权，但是因为公司的项目，我全局设置了用户名和邮箱，导致实际的用户名和邮箱与 GitHub 的用户名不匹配了，所以出现了这种情况，只需要在项目目录下，局部更改一下

bash 复制代码

git config user.name "Your Name"
git config user.email "project-email@company.com"

我试了一下，主要是由邮箱决定的，名称其实不影响。

第二点： 如果想要有这个验证标签，可以详细看一下这里： docs.github.com/zh/authenti...

其实对于我这个项目来说，没什么意义，只是看到了，就去了解了一下。

SSH 密钥：像是你家的【门禁卡/钥匙】
- 目的：身份认证。 用于证明"你就是你"，从而获得访问权限。
- 应用场景： 在 GitHub/GitLab 上，用它来安全地推送代码 ，代替输入用户名和密码。它让你能够与远程仓库进行读写操作（如 git push, git pull）。
GPG 密钥：像是你文件上的【官方印章和蜡封】
- 目的：数字签名。 用于证明"这份文件（代码）确实是你本人发布的，并且在传输过程中没有被篡改"。
- 应用场景： 为你的 Git 提交 和 Tag 创建加密签名，使其在 GitHub 上显示为 "Verified" 标记。它验证的是代码的完整性和来源。

对比表格：

特性	SSH 密钥	GPG 密钥
主要用途	认证 - 安全访问服务器/代码仓库	签名 - 验证提交/标签的完整性和作者
GitHub 上的体现	允许你执行 `git push`等操作	在你的提交上显示 Verified 标记
是否必须	强烈推荐（几乎必备，为了安全和方便）	可选（为了更高的安全性和专业度）
配置复杂度	简单	相对复杂
对个人项目的价值	高（安全推送代码）	中低（除非项目非常严肃或用于协作）
对开源协作项目的价值	高	高（尤其是大型项目，用于确保提交可信）

六、总结

当我们想要做好一个产品的时候，思维只停留在编码层面还是不够的，在进行管理，推广等等，各方面有很多细节需要处理，我也是一个正在摸索的人，我尽量将我碰到的问题发表出来，或许有些片面，如果你有一些更好的意见欢迎评论区分享。

千里之行，始于足下。你的"个人公司"从这第一个2小时开始。欢迎在评论区分享你的进展或遇到的卡点，我会逐一查看，尽可能的帮助解决。我们下一篇文章见！