git-workflow

Name: git-workflow
Author: krzysztofsurdy

39installs1forks

How to install git-workflow?

krzysztofsurdy/code-virtuoso/git-workflow

$npx -y skills add krzysztofsurdy/code-virtuoso --skill git-workflow

Installs into the current project.

Summary

Git workflow patterns and version control best practices for teams of any size. Use when the user asks to choose a branching strategy (trunk-based, GitHub Flow, Git Flow, GitLab Flow), define commit conventions, set up PR workflows, plan release management, structure a monorepo,

Files · 1

View on GitHub

SKILL.md

1	# Git Workflow
2
3	Effective version control is not just about tracking changes - it is about enabling teams to collaborate predictably, release confidently, and maintain a history that tells a coherent story. The right workflow depends on team size, release cadence, and how much process the project can absorb without slowing down.
4
5	## Choosing a Branching Strategy
6
7	No single branching model fits every team. The right choice depends on how often you release, how large your team is, and how much ceremony you can tolerate.
8
9	### Strategy Comparison
10
11	\| Strategy \| Release Cadence \| Team Size \| Complexity \| Best For \|
12	\|---\|---\|---\|---\|---\|
13	\| Trunk-Based \| Continuous (multiple per day) \| Any (works best with strong CI) \| Low \| SaaS, cloud-native, teams with mature CI/CD \|
14	\| GitHub Flow \| On-demand (per merged PR) \| Small to medium \| Low \| Web apps, startups, teams wanting simplicity \|
15	\| Git Flow \| Scheduled / versioned releases \| Medium to large \| High \| Packaged software, mobile apps, multiple supported versions \|
16	\| GitLab Flow \| Environment-promoted \| Medium to large \| Medium \| Teams needing environment-specific branches (staging, production) \|
17
18	### Decision Guide
19
20	1. Do you deploy continuously? - Use trunk-based development. Short-lived branches (hours, not days), feature flags for incomplete work, and strong CI are prerequisites.
21	2. Do you deploy on merge but want review gates? - Use GitHub Flow. One long-lived branch (main), feature branches, pull requests as the merge gate.
22	3. Do you ship versioned releases on a schedule? - Use Git Flow. Separate develop and main branches, release branches for stabilization, hotfix branches for emergency patches.
23	4. Do you promote through environments? - Use GitLab Flow. Environment branches (staging, production) sit downstream of main, and merges flow in one direction.
24
25	See [Branching Strategies Reference](references/branching-strategies.md) for detailed mechanics, feature flag integration, and migration paths between strategies.
26
27	---
28
29	## Commit Message Conventions
30
31	Good commit messages serve three audiences: reviewers reading the PR, developers reading `git log` next month, and automation tools generating changelogs and version bumps.
32
33	### The Conventional Commits Format
34
35	```
36	<type>(<scope>): <description>
37
38	[optional body]
39
40	[optional footer(s)]
41	```
42
43	### Common Commit Types
44
45	\| Type \| Purpose \| Version Impact \|
46	\|---\|---\|---\|
47	\| `feat` \| New feature visible to users \| Minor bump \|
48	\| `fix` \| Bug fix \| Patch bump \|
49	\| `refactor` \| Code restructuring with no behavior change \| None \|
50	\| `perf` \| Performance improvement \| Patch bump \|
51	\| `test` \| Adding or updating tests \| None \|
52	\| `docs` \| Documentation only \| None \|
53	\| `chore` \| Tooling, dependencies, build config \| None \|
54	\| `ci` \| CI/CD pipeline changes \| None \|
55	\| `build` \| Build system or dependency changes \| None \|
56
57	### Breaking Changes
58
59	Append `!` after the type or add a `BREAKING CHANGE:` footer to signal incompatible changes. Either notation triggers a major version bump when used with automated release tooling.
60
61	```
62	feat(api)!: remove deprecated /v1/users endpoint
63
64	BREAKING CHANGE: The /v1/users endpoint has been removed. Use /v2/users instead.
65	```
66
67	### Semantic Versioning Alignment
68
69	\| Commit Contains \| Version Bump \| Example \|
70	\|---\|---\|---\|
71	\| `fix:` \| Patch (1.0.0 -> 1.0.1) \| Bug corrections \|
72	\| `feat:` \| Minor (1.0.0 -> 1.1.0) \| New capabilities \|
73	\| `BREAKING CHANGE` or `!` \| Major (1.0.0 -> 2.0.0) \| Incompatible changes \|
74
75	See [Commit Conventions Reference](references/commit-conventions.md) for scope naming patterns, multi-line body guidelines, changelog automation setup, and git hook validation.
76
77	---
78
79	## Pull Request Workflow
80
81	Pull requests are the primary collaboration point in most git workflows. Their quality directly affects review speed, defect discovery, and team velocity.
82
83	### PR Size Guidelines
84
85	\| PR Size (lines changed) \| Review Quality \| Recommended \|
86	\|---\|---\|---\|
87	\| < 50 \| Excellent - reviewer catches most issues \| Ideal for stacked PRs \|
88	\| 50-200 \| Good - manageable cognitive load \| Sweet spot for most changes \|
89	\| 200-400 \| Acceptable - requires focused review time \| Upper bound for single reviews \|
90	\| 400+ \| Poor - reviewer fatigue, defects slip through \| Split into smaller PRs \|
91
92	### Core PR Practices
93
94	- One concern per PR - A PR should do one thing: add a feature, fix a bug, refactor a module. Mixing concerns makes review harder and reverts

People who liked this also viewed

6 picks

Type

git-workflow

39installs1forks

View on GitHub

How to install git-workflow?

krzysztofsurdy/code-virtuoso/git-workflow

$npx -y skills add krzysztofsurdy/code-virtuoso --skill git-workflow

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Git Workflow
2
3	Effective version control is not just about tracking changes - it is about enabling teams to collaborate predictably, release confidently, and maintain a history that tells a coherent story. The right workflow depends on team size, release cadence, and how much process the project can absorb without slowing down.
4
5	## Choosing a Branching Strategy
6
7	No single branching model fits every team. The right choice depends on how often you release, how large your team is, and how much ceremony you can tolerate.
8
9	### Strategy Comparison
10
11	\| Strategy \| Release Cadence \| Team Size \| Complexity \| Best For \|
12	\|---\|---\|---\|---\|---\|
13	\| Trunk-Based \| Continuous (multiple per day) \| Any (works best with strong CI) \| Low \| SaaS, cloud-native, teams with mature CI/CD \|
14	\| GitHub Flow \| On-demand (per merged PR) \| Small to medium \| Low \| Web apps, startups, teams wanting simplicity \|
15	\| Git Flow \| Scheduled / versioned releases \| Medium to large \| High \| Packaged software, mobile apps, multiple supported versions \|
16	\| GitLab Flow \| Environment-promoted \| Medium to large \| Medium \| Teams needing environment-specific branches (staging, production) \|
17
18	### Decision Guide
19
20	1. Do you deploy continuously? - Use trunk-based development. Short-lived branches (hours, not days), feature flags for incomplete work, and strong CI are prerequisites.
21	2. Do you deploy on merge but want review gates? - Use GitHub Flow. One long-lived branch (main), feature branches, pull requests as the merge gate.
22	3. Do you ship versioned releases on a schedule? - Use Git Flow. Separate develop and main branches, release branches for stabilization, hotfix branches for emergency patches.
23	4. Do you promote through environments? - Use GitLab Flow. Environment branches (staging, production) sit downstream of main, and merges flow in one direction.
24
25	See [Branching Strategies Reference](references/branching-strategies.md) for detailed mechanics, feature flag integration, and migration paths between strategies.
26
27	---
28
29	## Commit Message Conventions
30
31	Good commit messages serve three audiences: reviewers reading the PR, developers reading `git log` next month, and automation tools generating changelogs and version bumps.
32
33	### The Conventional Commits Format
34
35	```
36	<type>(<scope>): <description>
37
38	[optional body]
39
40	[optional footer(s)]
41	```
42
43	### Common Commit Types
44
45	\| Type \| Purpose \| Version Impact \|
46	\|---\|---\|---\|
47	\| `feat` \| New feature visible to users \| Minor bump \|
48	\| `fix` \| Bug fix \| Patch bump \|
49	\| `refactor` \| Code restructuring with no behavior change \| None \|
50	\| `perf` \| Performance improvement \| Patch bump \|
51	\| `test` \| Adding or updating tests \| None \|
52	\| `docs` \| Documentation only \| None \|
53	\| `chore` \| Tooling, dependencies, build config \| None \|
54	\| `ci` \| CI/CD pipeline changes \| None \|
55	\| `build` \| Build system or dependency changes \| None \|
56
57	### Breaking Changes
58
59	Append `!` after the type or add a `BREAKING CHANGE:` footer to signal incompatible changes. Either notation triggers a major version bump when used with automated release tooling.
60
61	```
62	feat(api)!: remove deprecated /v1/users endpoint
63
64	BREAKING CHANGE: The /v1/users endpoint has been removed. Use /v2/users instead.
65	```
66
67	### Semantic Versioning Alignment
68
69	\| Commit Contains \| Version Bump \| Example \|
70	\|---\|---\|---\|
71	\| `fix:` \| Patch (1.0.0 -> 1.0.1) \| Bug corrections \|
72	\| `feat:` \| Minor (1.0.0 -> 1.1.0) \| New capabilities \|
73	\| `BREAKING CHANGE` or `!` \| Major (1.0.0 -> 2.0.0) \| Incompatible changes \|
74
75	See [Commit Conventions Reference](references/commit-conventions.md) for scope naming patterns, multi-line body guidelines, changelog automation setup, and git hook validation.
76
77	---
78
79	## Pull Request Workflow
80
81	Pull requests are the primary collaboration point in most git workflows. Their quality directly affects review speed, defect discovery, and team velocity.
82
83	### PR Size Guidelines
84
85	\| PR Size (lines changed) \| Review Quality \| Recommended \|
86	\|---\|---\|---\|
87	\| < 50 \| Excellent - reviewer catches most issues \| Ideal for stacked PRs \|
88	\| 50-200 \| Good - manageable cognitive load \| Sweet spot for most changes \|
89	\| 200-400 \| Acceptable - requires focused review time \| Upper bound for single reviews \|
90	\| 400+ \| Poor - reviewer fatigue, defects slip through \| Split into smaller PRs \|
91
92	### Core PR Practices
93
94	- One concern per PR - A PR should do one thing: add a feature, fix a bug, refactor a module. Mixing concerns makes review harder and reverts

People who liked this also viewed

6 picks

Type