# Git Workflow > Standard git workflow for everyday development — branching, committing, rebasing, pull requests, reviewing, merging, and changelog generation. Use when asked to perform git operations, prepare a PR, resolve merge conflicts, or generate release notes. Use when this capability is needed. - Skill: `tomevault-io/git-workflow-6` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/git-workflow-6` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/git-workflow-6/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/git-workflow-6 --- # Git Workflow Standard git operations for any project. ## Branching - **Never create a new branch for simple commits or pushes.** Always commit directly to the current branch unless the user explicitly requests otherwise. - **PRs are the exception.** When the user asks to open a pull request, creating a feature/fix branch is expected as part of the PR workflow. - Conventions when branching IS explicitly requested: - **Feature branches**: `feat/` or `/` - **Bug fixes**: `fix/-` - **Chores/refactoring**: `chore/` - Base feature/fix branches off the default branch (`main`, `master`, `dev`) ## Committing Write clear, conventional commit messages: ``` : (subject, max 72 chars) (optional, wrap at 72 chars) ``` Common types: `feat`, `fix`, `chore`, `refactor`, `docs`, `test`, `style`, `perf`, `ci` Guidelines: - One logical change per commit - The subject line should complete "This commit will..." (e.g., "fix: handle empty input gracefully") - Use imperative mood ("add" not "added" or "adds") - Reference issue numbers when applicable: `fix #123: ...` ## Pull Requests ### Before Opening - Rebase onto the latest target branch: `git rebase origin/main` - Resolve any merge conflicts locally - Run tests: build, lint, typecheck, test - Review your own diff before submitting - Ensure each commit compiles and passes tests (bisect-friendly) ### PR Description ``` ## Summary What this change does and why. ## Changes - Bullet list of key changes - Focus on what is notable, not every file touched ## Testing How the change was tested: specific commands, scenarios, edge cases. ## Breaking Changes List any breaking changes and migration steps, or "None." ``` ## Code Review - Respond to review comments promptly - Each comment should get a reply or a fix - After addressing feedback, re-request review - Keep conversations focused on the code ## Merging ### Strategies - **Squash merge**: For feature branches with many small/pending commits. Produces one clean commit. - **Rebase merge**: When you want to preserve individual commit history with linear history. - **Merge commit**: For collaborative branches where multiple people committed. ### After Merge - Delete the feature branch (remote and local) - Update any related issues ## Changelog Generation To generate changelog from git history between two references: ``` git log --oneline ..HEAD --no-decorate ``` Categorize changes by type (feat, fix, chore, etc.) using the commit message prefixes. Group breaking changes separately with a "⚠️ Breaking Changes" header. ## Handling Merge Conflicts 1. `git merge ` or `git rebase ` will stop at conflicts 2. Use `git status` to find conflicted files 3. Open each file and resolve conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`) 4. `git add ` to mark as resolved 5. `git rebase --continue` or `git merge --continue` 6. Verify the build still works after resolution --- > Source: [Eslzzyl/tidev](https://github.com/Eslzzyl/tidev) — distributed by [TomeVault](https://tomevault.io).