git-workflow

Feature-branch workflows isolate work by creating short-lived branches for each task, then merging via pull requests after review. This keeps the main branch stable and enables team collaboration. Start by establishing branch naming conventions, writing atomic commits with meaningful messages, and requiring PR reviews before merge.

Atomic commits paired with conventional commit syntax—prefixing messages with type (feat, fix, docs) and describing changes clearly—make history readable and enable automated tooling. Each commit should represent one logical change, not multiple unrelated fixes bundled together.

Merge conflicts occur when parallel branches modify the same lines. Resolve by examining conflicted sections, choosing or combining versions, then staging and committing the result. Rebase workflows prevent conflicts earlier by keeping branches short-lived and frequently synchronized with main.

Merge preserves complete history and is safer for shared branches; rebase rewrites history for a linear, cleaner log but should only apply to local or short-lived branches. Teams typically merge via pull requests to maintain traceability and enable reviews.

Branch protection prevents accidental overwrites by requiring pull request reviews, passing status checks, and dismissing stale reviews before merging. It enforces consistent workflow across teams and maintains history integrity.

Enforce atomic commits, use conventional commit syntax, delete merged branches promptly, and avoid force-pushing to shared branches. Squashing or rebasing feature branches before merge removes intermediate commits, keeping the main branch history focused and readable.