開源日報每天推薦一個 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/