git-and-release-ops-edho-ferdian

Guides Git branching, commit conventions, PR triage, and release versioning workflows.

2|Updated Sep 6, 2026
One-click install
npx skills add https://github.com/edhoferdian/EEF --skill git-and-release-ops-edho-ferdian-edhoferdian
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: git-and-release-ops-edho-ferdian
Source: https://github.com/edhoferdian/EEF/tree/main/.agents/skills/git-and-release-ops-edho-ferdian
Command: npx skills add https://github.com/edhoferdian/EEF --skill git-and-release-ops-edho-ferdian-edhoferdian

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Teams and solo developers often lack consistent Git conventions, leading to messy histories, premature review requests, mishandled CI failures, and releases with unclear changelogs or wrong version bumps. This Skill provides a complete, opinionated workflow for branching, committing, reviewing, triaging, and releasing. ## Core Features & Use Cases - Branching & Commit Standards: Selects between GitHub Flow, trunk-based, and GitFlow strategies, enforces a conventional commit format, and defines safe merge-versus-rebase and conflict-resolution rules. - PR Readiness & Triage: Classifies issues and PRs into merge, port, close, or park states, enforces pre-review readiness checks, triages CI failures as flaky versus real, and treats all forge content as untrusted input. - Release & Changelog Cutting: Covers SemVer tagging with immutable annotated tags, trunk-based versus release-branch cutting, Keep a Changelog formatting, and version bump rules split for libraries versus applications. - Use Case: When a pull request shows a red CI pipeline, use this Skill to read the failing step, decide whether the failure is flaky or real before re-running, and classify the PR rather than merging with a caveat. ## Quick Start Ask the assistant to review whether the current branch and pull request are ready to merge and to draft the release notes for the next version.

Frequently Asked Questions about git-and-release-ops-edho-ferdian

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I choose between GitHub Flow, trunk-based, and GitFlow branching?

Default to GitHub Flow for solo work and small teams shipping continuously. Adopt trunk-based development only with strong CI and feature flags, and use GitFlow only when genuinely maintaining multiple released versions simultaneously.

When should I rebase versus merge a Git branch?

Never rebase a branch others have pulled, that is an open shared PR, or that is protected. Rebase your own feature branch before opening a PR for linear history, merge collaborative branches, and force-push only with --force-with-lease on branches you solely author.

How do I decide between a major, minor, or patch version bump?

For libraries, ask whether every consumer can upgrade with zero code changes and get correct behavior; if yes it is not a major bump. Breaking API changes are MAJOR, backward-compatible additions are MINOR, and bug fixes are PATCH.

How should I triage a failing CI pipeline before merging?

Read the failing step rather than the summary, then decide whether the failure is flaky or real before re-running. Re-running a real failure normalizes red builds; record flake patterns and quarantine them instead of retrying until green.

Can I move or retag a published release tag in Git?

No, published release tags are immutable because two pulls of the same tag must return identical code. If a release was wrong, ship a new patch version such as v2.4.2 instead of retagging v2.4.1.

When is a pull request ready to request review?

Request review only when automated checks are green, merge conflicts are resolved, and the branch is current with its target. A red pipeline or stale branch means reviewers read code that will change, wasting a review cycle.