Github Names

💻 Contributing to Git Projects Like a Pro

Contributing to open source (or even private repos at work) is more than just writing code—it's about making your contributions easy to understand, review, and maintain. Whether you're submitting a bug fix, adding a feature, or updating docs, a consistent and thoughtful approach helps the whole team.

Let’s break down a few key tips to keep your Git contributions clean and impactful.

🧠 Before You Start

Before diving into the code, always:

• Check open issues and discussions to avoid duplicate work.
• Ask questions if something’s unclear—most maintainers appreciate contributors who clarify before coding.
• If it's a large change or new feature, open a discussion first. Better to align early than rework later.

🔤 Conventional Commits: Naming That Makes Sense

One of the simplest ways to make your Git history readable is by using Conventional Commits. This naming convention categorizes commits by their purpose. Here’s the basic syntax:

cpp

CopyEdit

type(optional-scope): short description

Common types:

• feat: for new features

  feat: add search functionality to product page

• fix: for bug fixes

  fix: prevent crash on empty user list

• docs: for documentation-only changes

  docs: update README with setup instructions

• chore: for maintenance tasks (refactors, test setup, deps)

  chore: update ESLint config

• style: for formatting changes (no logic changed)

  style: reformat code with Prettier

• test: for adding or updating tests

  test: add unit tests for login handler

• refactor: for code restructuring without changing behavior

  refactor: simplify conditionals in payment flow

Optional scopes help narrow down what you're changing:

1feat(auth): add 2FA to login flow
2fix(ui): resolve layout issue on mobile
3

🧪 Testing Your Changes

Whether you're writing a bug fix or feature, it's good practice to:

• Add tests (unit, integration, or e2e depending on the scope).
• Keep test files organized by feature or module.
• Test locally using your environment or config setup.

If the repo has a test/ directory or a dev command to start a test suite—use it. It’s there to help you validate your work.

📄 Writing Good Pull Requests

When opening a PR:

• Keep it focused—1 PR = 1 logical change.
• Write a clear description of the problem and your solution.
• Link to related issues with Closes #123 or Fixes #456.
• If you made any UI changes or updated translations, mention it.

Bonus points for screenshots, logs, or GIFs showing the change.

🌍 Internationalization (Optional but Helpful)

If your PR adds new text visible in the UI:

• Add the English translation key (usually in a en.json or similar).
• If possible, translate it to other supported languages.
• Use a utility like t('yourKey') if the project supports i18n.

No worries if you can’t translate—just mention it, and maintainers can handle the rest.

🎯 Final Tip: Use pnpm, nvm, or Other Required Tools

Some projects are picky about tools. Read the contributing guide or root README.md. If the project uses pnpm, don’t sneak in npm install. That’s asking for trouble.

Example post written with AI.