git-workflow

name	git-workflow
description	Use short-lived branches and small pull requests
domain	version-control
confidence	high
source	template

Context

This repository should use a simple, template-friendly Git workflow that works for forks and new projects.

Patterns

Branching

• Create short-lived feature branches from the repository's active integration branch
• Use descriptive branch names such as feature/news-filters, fix/rss-parser, or docs/setup-guide
• Keep one logical change per branch when possible

Pull requests

• Open small, reviewable pull requests with a clear summary
• Link related issues when they exist
• Update tests and documentation in the same pull request as the code change
• Rebase or merge the latest target branch before final review when needed

Commits

• Use descriptive commit messages that explain intent, not just files changed
• Avoid mixing unrelated refactors with behavior changes in the same commit

Examples

✓ Good:

• Branch: feature/category-filters
• PR: "Add category filtering to the news catalog"
• Commit: feat: add category filter controls

✗ Poor:

• Branch: stuff
• PR with multiple unrelated fixes and docs rewrites
• Commit: updates

Anti-patterns

• Long-lived branches that drift from the main line
• Massive pull requests that combine unrelated work
• Making API changes without updating tests or docs
• Using branch naming rules tied to another team's process