Skip to content
Joel Zeng Luo edited this page Aug 8, 2023 · 2 revisions
  1. Git Branch Naming Convention:

1.1. General Format: type/description

1.2. Types of Branches:

feature: New features for the application, e.g., feature/add-login-screen.
fix: Bug fixes, e.g., fix/login-button-alignment.
chore: Regular code maintenance tasks, e.g., chore/update-dependencies.
refactor: Code refactoring tasks, e.g., refactor/use-hooks-in-login.
arch: 
style: Styling and cosmetic code changes, e.g., style/revise-login-css.
test: Adding or updating tests, e.g., test/add-login-tests.
  1. Commit Message Conventions:

2.1. General Format: ():

type: Indicates the type of commit. Common types include:
    feat: A new feature.
    fix: A bug fix.
    docs: Documentation only changes.
    style: Changes that do not affect the meaning of the code (whitespace, formatting, missing semi-colons, etc.).
    refactor: A code change that neither fixes a bug nor adds a feature.
    perf: A code change that improves performance.
    test: Adding missing tests or correcting existing tests.
    chore: Changes to the build process or auxiliary tools and libraries.

scope (optional): Refers to the section/module of the codebase affected by the commit, e.g., auth, header, footer.

description: A concise explanation of the changes.

2.2. Examples:

feat(auth): add two-factor authentication
fix(header): adjust responsive design issues
style(buttons): standardize button padding
  1. Additional Best Practices:

3.1. Keep Commits Focused:

Each commit should represent a single logical change. Avoid mixing multiple unrelated changes in one commit.

3.2. Rebase Instead of Merge (when possible):

If working on a feature branch and the main branch has updated, use git rebase to apply your branch changes on top of the main branch. This avoids the "merge commit" and keeps the history linear.

3.3. Use Pull Requests (PRs) or Merge Requests (MRs):

When integrating changes from one branch to another, especially for features or bug fixes, use PRs/MRs. This provides an opportunity for code review and ensures code quality.

3.4. PRs/MRs should also follow naming conventions:

The title should briefly describe the change.
The description should provide context, mention related issues, and summarize the changes introduced.

3.5. Keep your local and remote repositories clean:

Once branches are merged and deployed, consider deleting them both locally (git branch -d <branch_name>) and remotely (git push origin --delete <branch_name>).

3.6. Use .gitignore:

React projects typically have node_modules, build folders, and environment-specific files. Make sure to include these in your .gitignore file to prevent them from being committed.

3.7. Regularly Fetch and Pull:

Frequently fetching and pulling the latest changes from the main branch helps avoid merge conflicts and keeps your local branch updated.

3.8. Avoid committing directly to the main branch:

Always make changes in a separate branch and use PRs/MRs to merge them into the main branch.

3.9. Write meaningful README and CONTRIBUTING documents:

Ensure that any developer can understand the project's purpose, setup, and contribution guidelines.

Following these best practices will help maintain a clean, understandable, and efficient development workflow for your React project.

Clone this wiki locally