ProjectManagement

Git项目多远程仓库同步方法 同一个 Git 项目可以同时推送到多个远程仓库（如 Gogs 和 Gitee）。 1. 添加 Gitee 作为新的远程仓库 git remote add gitee <Gitee仓库的URL> 2. 验证远程仓库设置 git remote -v 3. 推送到 Gitee git push gitee master # 推送 master 分支 # 或推送所有分支： git push --all gitee 4.（可选）设置默认同时推送到两个仓库 修改 .git/config 文件，在 [remote “origin”] 部分添加多个 push URL： [remote "origin"] url = https://gogs.example.com/yourname/yourrepo.git fetch = +refs/heads/*:refs/remotes/origin/* pushurl = https://gogs.example.com/yourname/yourrepo.git pushurl = https://gitee.com/yourname/yourrepo.git 这样 git push 会同时推送到两个仓库。 5. （可选）从 Gitee 拉取更新 git pull gitee master 删除指定的远程仓库（如 gitee） git remote remove gitee 注意事项： 两个仓库的分支结构最好保持一致 如果两边都有新的提交，可能需要先合并再推送 大型项目首次推送到 Gitee 可能需要较长时间 这种方法可以让你保持代码在多个远程仓库同步，适用于需要备份或多平台协作的场景。

为什么需要开源许可证 把代码发布到 GitHub，并不意味着其他人就自动获得了自由使用、修改和分发代码的权利。 开源许可证的作用，就是明确告诉其他人：这个项目可以怎么使用、能不能修改、能不能商业使用、修改后是否需要公开源码，以及分发时需要保留哪些声明。 Choose a License 将开源许可证按照限制程度进行了整理，从 GNU AGPLv3、GNU GPLv3、GNU LGPLv3，到 MPL 2.0、Apache License 2.0、MIT License，再到基本没有额外条件的许可证，形成了一个从强 Copyleft 到宽松许可的连续范围。 因此，选择许可证真正需要考虑的不是「哪个许可证最好」，而是： 你希望别人如何使用你的代码？ 如果希望别人可以自由使用，包括商业项目和闭源项目，通常应该选择宽松许可证；如果希望衍生作品继续保持开源，则应该考虑 Copyleft 许可证。 开源许可证主要解决什么问题 选择许可证之前，需要先理解几个核心问题。 商业使用 商业使用是很多开发者首先关注的问题。 主流开源许可证通常允许商业使用，包括 MIT、Apache License 2.0、GPL、LGPL、MPL 和 AGPL。区别并不在于「能不能赚钱」，而在于商业使用过程中需要履行什么义务。 例如： MIT：可以用于商业软件，也可以制作闭源商业软件。 Apache 2.0：可以用于商业软件，并提供明确的专利授权。 GPL：可以用于商业软件，但分发衍生作品时需要遵守 GPL 的开源要求。 AGPL：可以用于商业软件，同时对网络服务场景增加了更强的源码公开要求。 因此，「允许商业使用」并不等于「可以随便闭源」。 修改和再分发 大多数主流许可证都允许修改代码，但对修改后的代码如何发布存在明显区别。 宽松许可证通常允许： 开源项目 ↓ 修改 ↓ 加入商业项目 ↓ 发布闭源版本 而 Copyleft 许可证则通常要求符合条件的衍生作品继续采用相同或兼容的许可证，并提供对应源码。 是否必须公开源码 这是选择许可证时最重要的区别之一。 可以简单理解为： MIT / Apache 2.0 ↓ 允许闭源 ↓ 商业软件可以不公开源码 GPL ↓ Copyleft ↓ 符合条件的衍生作品需要开放源码 LGPL / MPL ↓ 弱 Copyleft ↓ 只对特定范围的修改要求开放 AGPL ↓ 强 Copyleft ↓ 进一步覆盖网络服务场景 需要注意的是，具体的源码公开义务取决于许可证定义的触发条件，不能简单理解成「用了 GPL 就必须把整个公司所有代码开源」。...

GitHub 项目版本管理规范 Git 标签（Tags）和 发布（Releases） 在 GitHub 项目中定义和管理版本，通常结合 Git 标签（Tags）、发布（Releases） 和 语义化版本（SemVer） 来实现。以下是具体方法和最佳实践： 1. 使用 Git 标签（Tags）定义版本 （1）创建版本标签 # 创建轻量标签 git tag v1.0.0 # 创建附注标签（推荐，包含提交信息和签名） git tag -a v1.0.0 -m "Release version 1.0.0" # 推送标签到 GitHub git push origin v1.0.0 （2）语义化版本（SemVer） 版本号格式：MAJOR.MINOR.PATCH MAJOR：不兼容的 API 变更 MINOR：向后兼容的功能新增 PATCH：向后兼容的问题修复 示例： v1.0.0：初始稳定版本 v1.2.3：第 1 个大版本，第 2 次功能更新，第 3 次补丁 2. 通过 GitHub Releases 管理版本 （1）手动创建 Release 进入 GitHub 仓库 → Releases → Draft a new release...

1. 文件规范 1.1 文件扩展名 Markdown 文件必须使用 .md 扩展名。 正确： docker-installation.md docker-compose.md mysql-index.md 错误： docker-installation.markdown docker-installation.txt 1.2 文件名 文件名统一使用小写字母。 多个单词之间使用 - 分隔，不使用空格、下划线或驼峰命名。 推荐： docker-installation.md docker-image-optimization.md mysql-deep-pagination.md 不推荐： DockerInstallation.md docker_installation.md docker installation.md 1.3 文件编码 Markdown 文件必须使用 UTF-8 编码。 2. 标题规范 2.1 文档标题 按照 FEX 规范，文档标题可以使用 Setext 风格： Markdown 编写规范 ================ 如果项目使用 Hugo 等现代 Markdown 工具链，也可以使用： # Markdown 编写规范 但是，如果严格遵循 FEX Team 原规范，则推荐使用 Setext 风格作为文档标题。 对于 Hugo 技术文章，如果 Front Matter 已经提供 title，正文通常不再重复一级标题。 例如：...

在软件开发流程中，Git已经成为版本控制的事实标准。每次提交代码都需要填写commit message，否则不允许提交。然而，在日常开发中，我们经常会看到各种各样模糊不清的提交信息，如“fix bug”、“更新代码”、“修改问题”等。这些不规范的commit message充斥在git history中，导致后续维护人员无法快速定位问题，有时甚至连提交者自己都不记得某次提交的目的。因此，我们需要一套统一的规范来管理和约束commit message。 规范概述 目前业界最知名的规范是Angular团队的commit message规范，它结构清晰、易于实施，已被广泛应用于开源项目和商业项目中。同时，许多IDE（如IntelliJ IDEA）也提供了相应的插件（如Git Commit Template）来辅助开发者遵循这一规范。 本文将以Angular规范为基础，详细介绍一套通用的Git commit message规范，并提供具体的操作示例。 Commit Message整体结构 规范的commit message包含三个部分：Header、Body和Footer。其格式如下： <header> <BLANK LINE> <body> <BLANK LINE> <footer> 重要说明： Header是必需的，包含type、scope和summary三个子元素 Body是必需的，用于详细描述提交内容 Footer是可选的，用于记录不兼容变更或关闭issue 关键规则：Header和Body之间必须有一个空行分隔，这是许多Git工具正确解析提交信息的前提。 整体结构示例 feat(用户认证): 增加短信验证码登录功能 为了提升用户登录体验，增加了通过手机号接收验证码进行登录的方式。 - 集成阿里云短信服务 - 新增验证码生成与校验逻辑 - 更新登录页面UI Closes #245 Header详解 Header是commit message的“标题”，格式为： <type>(<scope>): <summary> 其中，type和summary为必填项，scope为可选项。 Type：提交类别 Type用于说明本次提交的类别，必须使用以下标准化标识之一： Type 说明 使用场景 feat 新功能 新增用户可见的功能特性 fix 修复bug 修复线上或测试环境发现的缺陷 docs 文档更新 仅修改文档，不涉及代码变更 style 代码格式 不影响代码运行的格式调整（空格、缩进、分号等） refactor 代码重构 既不是新增功能，也不是修复bug的代码结构调整 perf 性能优化 提升系统性能或用户体验的代码变更 test 测试相关 新增或修改测试用例 chore 构建/工具变动 构建流程、依赖管理、辅助工具等变更 revert 回滚提交 撤销之前的某次提交 Type使用示例：...

Git同时配置github和gitee 想要同时使用GitHub和Gitee，但是每次输入密码就会很麻烦。为此，本文将介绍 Git 同时配置 github和 gitee 的ssh key #查看git配置 git config --global --list #没配置过的话先配置用户名和邮箱信息 git config --global user.name “username” git config --global user.email “email” #默认没有.ssh目录， ssh-keygen -t rsa -C "xxxxxxx@xx.com" #在windows下会生成.ssh目录 [c盘/用户/用户名/.ssh] 1. 查看ssh文件 cd ~/.ssh** ls 2. 删除之前的.ssh rm -rf id_rsa id_rsa.pub 3. 生成gitee和github 的 SSH Key ssh-keygen -t rsa -C "xxxxxxx@xx.com" -f "id_rsa_github" ssh-keygen -t rsa -C "xxxxxxx@xx.com" -f "id_rsa_gitee" 4. 查看SSH Key cat id_rsa_github.pub** 5. 拷贝 ssh-rsa 开头的 ssh key，然后到github上添加ssh key 6....