开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
开源日报第1113期：可移植到其他支持框架的React库 《hydrogen》
2024年2月22日，开源日报第1113期：
今日推荐开源项目：《hydrogen》
今日推荐英文原文：《Be a better developer with these Git good practices》

开源项目

今日推荐开源项目：《hydrogen》传送门：项目链接

推荐理由：Hydrogen旨在与Remix（Shopify的全栈Web框架）配合使用，但它还提供了一个可移植到其他支持框架的React库
直达链接: hydrogen.shop

英文原文

今日推荐英文原文：Be a better developer with these Git good practices

推荐理由：主要介绍工作中常用的 Git 的使用技巧，包括分支命名规范、提交信息的编写以及 Conventional Commits 规范。分支命名应该清晰、简洁、具有描述性，提交信息也应该遵循一定的规范，例如使用命令语气、首字母大写、不超过 50 个字符等等，非常值得学习

Be a better developer with these Git good practices

If you're a developer, you probably use the versioning system called Git on a daily basis. The use of this tool is crucial for the development process of an application, whether working in a team or individually. However, it's common to encounter messy repositories, commits with unclear messages that don't convey useful information, and misuse of branches, among other issues. Knowing how to use Git correctly and following good practices is essential for those who want to excel in the job market.

Naming Conventions for Git Branches

When we're working with code versioning, one of the main good practices that we should follow is using clear and descriptive names for branches, commits, pull requests, etc. Ensuring a concise workflow for all team members is essential. In addition to gaining productivity, documenting the development process of the project historically simplifies teamwork. By following these practices, you'll see benefits soon.

Based on it, the community created a branch naming convention that you can follow in your project. The use of the following items below is optional, but they can help improve your development skills.

1. Lowercase: Don't use uppercase letters in the branch name, stick to lowercase;

2. Hyphen separated: If your branch name consists of more than one word, separate them with a hyphen. following the kebab-case convention. Avoid PascalCase, camelCase, or snake_case;

3. (a-z, 0-9): Use only alphanumeric characters and hyphens in your branch name. Avoid any non-alphanumeric character;

4. Please, don't use continuous hyphens (--). This practice can be confusing. For example, if you have branch types (such as a feature, bugfix, hotfix, etc.), use a slash (/) instead;

5. Avoid ending your branch name with a hyphen. It does not make sense because a hyphen separates words, and there's no word to separate at the end;

6. This practice is the most important: Use descriptive, concise, and clear names that explain what was done on the branch;

Wrong branch names

  • fixSidebar
  • feature-new-sidebar-
  • FeatureNewSidebar
  • feat_add_sidebar

Good branch names

  • feature/new-sidebar
  • add-new-sidebar
  • hotfix/interval-query-param-on-get-historical-data

Branch Names Convention Prefixes

Sometimes the purpose of a branch isn't clear. It could be a new feature, a bug fix, documentation updates, or anything else. To address this, it's a common practice to use a prefix on the branch name to quickly explain the purpose of the branch.

  • feature: It conveys a new feature that will be developed. For example, feature/add-filters;

  • release: Used to prepare a new release. The prefix release/ is commonly used to do tasks such as last touched and revisions before merging the new updates from the branch master to create a release. For example, release/v3.3.1-beta;

  • bugfix: It conveys that you're solving a bug in the code and it's usually related to an issue. For instance, bugfix/sign-in-flow;

  • hotfix: Similar to bugfix, but it is related to fixing a critical bug present in the production environment. For example, hotfix/cors-error;

  • docs: To write some documentation. For example, docs/quick-start;

If you're working in a workflow with task management, like Jira, Trello, ClickUp, or any similar tool that can create User Stories, each card has a number associated. So, is commonly use these card numbers on the prefix of branch names. For example:

  • feature/T-531-add-sidebar
  • docs/T-789-update-readme
  • hotfix/T-142-security-path

Commit Message

Let's go talk about commit messages. Unfortunately, is so easy to find projects with commit messages like "added a lot of things" or "Pikachu, I choose you"... Yeah, I once found a project where the commit messages were related to a Pokémon fight.

Commit messages are really important in the development process. Creating a good history will help you a lot of times in your journey. Like branches, commits also have conventions created by the community, which you can learn about below:

  • A commit message has three important sections: Subject, Description, and Footer. The subject of a commit is required and defines the purpose of a commit. The description (body) is used to provide additional context and explanation for the commit's purpose. Lastly, there's the footer, commonly used for metadata like assigning a commit. While utilizing both the description and footer is considered a good practice, it's not required.

  • Use the imperative mood in the subject line. For example:

Add README.md ✅;
Added README.md ❌;
Adding README.md ❌;

  • Capitalize the first letter of the subject line. For example:

Add user authentication ✅;
add user authentication ❌;

  • Don't end the subject line with a period. For example:

Update unit tests ✅;
Update unit tests. ❌;

  • Limit the subject line to 50 characters, i.e., be clear and concise;

  • Wrap the body at 72 characters and separate the subject from a blank line;

  • If your body of commit has more than one paragraph, so use blank lines to separate them;

  • If necessary, use bullet points instead of only paragraphs;

Conventional Commit's

"The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history."

The quote below was obtained from the Conventional Commit's official website. This specification is the most used convention to commit messages in the community.

Structure

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Commit Type

The first structure that we have to study is the commit type. It provides a clear context about what's done in this commit. Below you can see the list of commit types and when to use them:

  • feat: Introductions of new functionalities;

  • fix: Rectifications of software bugs;

  • refactor: Employed for code alterations preserving its overall functionality;

  • chore: Updates not impacting production code, involving tool, config, or library adjustments;

  • docs: Additions or modifications to documentation files;

  • perf: Code changes enhancing performance;

  • style: Adjustments related to code presentation, like formatting and whitespace;

  • test: Inclusion or correction of tests;

  • build: Modifications affecting the build system or external dependencies;

  • ci: Alterations to CI configuration files and scripts;

  • env: Describes adjustments or additions to configuration files within CI processes, such as container configuration parameters.

Scope

A scope is a structure that can be added after the commit's type to provide additional contextual information:

  • fix(ui): resolve issue with button alignment
  • feat(auth): implement user authentication

Body

The body of a commit message provides detailed explanations about the changes introduced by the commit. It's typically added after a blank line following the subject line.

下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/