I'm Shelchin

Appearance

用好 Git ，让软件历史更清晰易懂 ​

漂亮的 Git 提交信息 ​

可以帮助团队成员理解代码历史，快速定位问题，并提高整体项目的可读性。

基本结构 ​

一个标准的 Git 提交信息通常包含三个部分：标题行（Header）、正文（Body）和页脚（Footer）。结构示例如下：

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

各部分说明 ​

  1. 标题行（Header）

    • type：提交的类型，表示这次提交的性质。
    • scope：可选，用来指明改动影响的范围。
    • subject：简短描述，说明改动的主要目的。

  2. 正文（Body）

    • 更详细地解释为什么需要这些更改，以及做了哪些更改。可以分为多行。

  3. 页脚（Footer）

    • 主要用于关联 issue 或拉取请求，例如：Fixes #123，Closes #456。

常用的 Type 类别 ​

  • feat：新功能（feature）
  • fix：修补bug
  • docs：文档（documentation）
  • style： 格式（不影响代码运行的变动）
  • refactor：重构（即不是新增功能，也不是修改bug的代码变动）
  • test：增加测试
  • chore：构建过程或辅助工具的变动
  • perf：性能优化

提交信息的一些实用原则 ​

  • 首字母大写：Subject 开始应使用大写字母。
  • 使用祈使句：Subject 应该使用祈使句，例如 "Fix bug" 而不是 "Fixed bug" 或 "Fixes bug"。
  • 避免句尾句号：Subject 结尾不应加句号。
  • 精简明确：尽量在50个字符以内简明扼要地描述主要变动。
  • 分隔清晰：在 Header、Body 和 Footer 之间应各保留一个空行。

示例 ​

feat(login): add the remember-me button
Add a remember-me checkbox to the login form to improve user experience.
Related to the user story #54321.

规范的分支命名 ​

规范的分支命名可以帮助团队成员快速理解分支的目的、类型和范围，从而提高工作效率和降低沟通成本。

1. 基本结构 ​

分支名通常由几个部分组成，可能包括但不限于：

<type>/<scope>-<description>

2. 分支类型（Type） ​

分支的类型表明了这个分支的目的或者它所代表的工作类型。常见的类型包括：

  • feat：新功能（features）
  • fix：错误修复（bug fixes）
  • docs：文档改动
  • style：代码格式（不影响代码运行的改动）
  • refactor：某个已有功能或代码块的重构
  • test：增加测试
  • chore：日常事务，如构建任务、包管理器配置等
  • hotfix：快速修复生产环境中的问题

3. 范围（Scope） ​

范围是可选的，指明了更改影响的特定部分，例如一个模块或组件的名称。

4. 描述（Description） ​

描述应该简洁明了，说明这个分支的主要更改或目的。描述采用 issue 编号开头，一个分支必须必须关联到一个 issue 。通常使用连字符（-）来连接详细描述的单词。

5. 示例 ​

下面是一些分支命名的示例：

  • feat/#1-user-auth：添加用户认证功能
  • fix/#2-login-bug：修复登录模块的一个错误
  • docs/#3-api-guide-update：更新 API 指南文档
  • refactor/#4-payment-logic：重构支付逻辑
  • test/#5-add-login-tests：添加登录功能的测试
  • chore/#12-setup-ci：设置持续集成环境
  • hotfix/#15-urgent-fix-account：紧急修复账户管理问题

6. 其他注意事项 ​

  • 避免过长的分支名：尽量保持简洁，避免过长的分支名，以便于查看和管理。
  • 使用小写字母：为了避免跨平台兼容问题，建议使用小写字母。
  • 使用斜线分隔类型和范围：使用斜线（/）来分隔类型和范围，使结构清晰。

GitHub Bug Issue 模板 ​

描述问题 ​

清楚而简洁地描述问题。

重现步骤 ​

步骤以重现行为：

  1. 前往 '...'
  2. 点击 '....'
  3. 向下滚动到 '....'
  4. 发现错误

预期行为 ​

描述你期望发生的事情。

实际行为 ​

描述实际发生了什么。

屏幕截图 ​

如果适用，添加屏幕截图来帮助解释你的问题。

环境信息 ​

  • 操作系统: [例如 iOS]
  • 浏览器 [例如 chrome, safari]
  • 版本 [例如 22]

其他备注 ​

添加此问题的其他上下文。

示例: 移动应用崩溃 ​

描述问题 ​

每次尝试启动应用时，应用立即崩溃，显示一个错误消息。

重现步骤 ​

步骤以重现行为：

  1. 打开应用
  2. 应用加载屏幕出现
  3. 应用崩溃，错误消息显示“未知错误”

预期行为 ​

应用应该正常启动并进入主界面。

实际行为 ​

应用在启动时崩溃，无法使用。

屏幕截图 ​

[插入屏幕截图]

环境信息 ​

  • 操作系统: Android
  • 设备: Samsung Galaxy S20
  • 版本: 10

其他备注 ​

尝试过重新安装应用，问题依然存在。

GitHub Feature Issue 模板 ​

标题 ​

标题应简洁明了，能够概括功能的核心需求。例如：“添加用户登录功能”

描述 ​

简明扼要地描述这个功能要解决的问题或者要实现的效果。例如，"实现一个用户登录系统，支持邮箱和社交媒体账号登录。"

动机 ​

说明这个功能的添加是为了达到什么业务或技术上的目标。例如，"通过用户登录，可以实现个性化推荐和用户数据分析。"

预期效果 ​

具体描述功能实现后的预期界面、交互或其他效果。可以包括用户界面UI的变化、数据处理的流程等。

用户故事/用例 ​

描述一个或多个用户故事，以便开发者理解功能如何被实际使用。

  • 作为一个用户，我可以通过我的邮箱地址登录，以便访问我的个人账户。
  • 作为一个用户，我可以通过Facebook或Google账号登录，这样我不需要记住额外的密码。

验收标准 ​

列出具体的验收标准，这些标准将用来验证功能是否按预期工作。

  1. 用户可以选择邮箱、Facebook或Google账号进行登录。
  2. 登录后，用户应该能看到其个人资料页面。
  3. 如果登录失败，用户应该收到适当的错误提示信息。

预期时间框架 ​

例如，"希望在下个版本发布前，即2024年9月前完成。"

设计稿 ​

如果可能，附上UI设计稿或任何视觉参考，以帮助开发者更好地理解预期的用户界面。

其他备注 ​

任何其他需要注意的事项或特定的技术要求。

当然可以，接下来我将为一个假想的电子商务平台创建一个GitHub Feature Issue，用于实现一个新的产品推荐引擎功能。

GitHub Feature Issue 示例 ​

标题 ​

实现智能产品推荐引擎

描述 ​

开发一个智能产品推荐引擎，该引擎能够根据用户的购物历史和浏览行为推荐相关商品。该功能旨在提升用户体验并增加销售额。

动机 ​

该功能的引入旨在利用机器学习技术分析用户行为，从而提供更加个性化的购物体验。通过精准推荐，我们可以提高用户满意度和重复购买率。

预期效果 ​

  • 用户界面：在主页和产品页面展示个性化推荐。
  • 后端逻辑：利用用户数据（包括购买历史和页面浏览记录）来训练推荐算法。
  • 用户互动：用户可以选择“喜欢”或“不喜欢”推荐商品，以进一步优化推荐算法。

用户故事/用例 ​

  • 作为一个用户，我希望看到与我之前购买和浏览行为相匹配的产品推荐，以便我可以快速找到喜欢的商品。
  • 作为一个用户，我可以对推荐的商品表示“喜欢”或“不喜欢”，以便系统更好地了解我的偏好。

验收标准 ​

  • 用户登录后，首页和商品详情页能够显示个性化商品推荐。
  • 用户能够对推荐商品进行“喜欢”或“不喜欢”的反馈。
  • 推荐系统应每月自动更新其算法，以包括新的用户数据。

预期时间框架 ​

希望在下一季度结束前，即2024年12月前完成此功能。

设计稿 ​

  • 推荐模块视觉设计：[附上设计稿链接或图片]（请替换为实际的设计稿链接或嵌入图片）

其他备注 ​

  • 确保所有个人数据的处理遵循GDPR等数据保护法规。
  • 需要考虑系统的可扩展性，以便未来能够支持更多的用户和复杂的数据分析。