~ Contribute

Suggest a correction or improvement. The author reviews it before it goes live.

Comment0 / 300

en/tutorials/git/18git-best-practices

# Git Best Practices

Following consistent conventions makes your codebase easier to understand and collaborate on.

## Commit Messages

Use the imperative mood, keep the subject under 50 characters, and separate with a blank line:

```
Add user authentication

- Implement login form component
- Add JWT token handling
- Update API middleware
```

The subject line is what shows up in `git log --oneline`. Write it like a command: "Add feature" not "Added feature".

## Atomic Commits

Each commit should do one thing. If you fix a bug and refactor a function, those should be two separate commits. This makes it easier to:
- Review changes in pull requests
- Revert specific changes with `git revert`
- Understand the history with `git log`

## Branching Strategy

```bash
git checkout -b feature/user-auth
git checkout -b fix/login-redirect
git checkout -b chore/update-dependencies
```

Use descriptive branch names with prefixes: `feature/`, `fix/`, `chore/`, `docs/`. Keep `main` stable and always deployable.

## Pull Request Workflow

1. Create a feature branch from `main`
2. Commit changes with clear messages
3. Push and open a PR
4. Get review and address feedback
5. Merge and delete the branch

## Code Review Tips

- Keep PRs small and focused on one change
- Write a clear PR description explaining what and why
- Address all review comments before merging
- Use `git rebase -i` to clean up commits before merging

## Protecting Your Work

- Pull before starting new work to avoid conflicts
- Run tests locally before pushing
- Use `git stash` when you need to switch contexts quickly
- Never force-push to shared branches

## Checklist

- Add `.gitignore` before your first commit
- Never commit secrets, keys, or credentials
- Keep commits small and focused
- Write meaningful commit messages
- Use branches for all non-trivial work
- Review diffs before committing with `git diff`
- Pull before starting new work to avoid conflicts

## Common Mistakes

- Committing directly to `main` for new features
- Writing vague messages like "fix" or "update"
- Bundling unrelated changes in one commit
- Leaving stale branches unmerged and undeleted
- Forgetting to pull before starting new work
- Not using `.gitignore` and committing `node_modules/`

No changes yet

cancel