원클릭으로 Manus에서 모든 스킬 실행

git-workflow

스타6

포크0

업데이트2026년 6월 25일 13:05

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.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

Eslzzyl

Eslzzyl/tidev

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

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/<short-description> or <username>/<feature-name>
- Bug fixes: fix/<issue-number>-<description>
- Chores/refactoring: chore/<description>
- Base feature/fix branches off the default branch (main, master, dev)

Committing

Write clear, conventional commit messages:

<type>: <short summary>                 (subject, max 72 chars)

<body>                                   (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 <from-tag>..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

git merge <branch> or git rebase <branch> will stop at conflicts
Use git status to find conflicted files
Open each file and resolve conflict markers (<<<<<<<, =======, >>>>>>>)
git add <resolved-file> to mark as resolved
git rebase --continue or git merge --continue
Verify the build still works after resolution

이 저장소의 다른 Skills

같은 저장소

code-review

Eslzzyl/tidev

General code review methodology covering logic, security, performance, readability, testing, and breaking changes. Use when asked to review code, check a pull request, evaluate a diff, or assess code quality in any language.

2026-06-256

debug

Eslzzyl/tidev

Systematic debugging methodology for any programming language or project. Use when investigating a bug, unexpected behavior, test failure, or error condition. Provides a structured approach to isolate root causes and verify fixes.

2026-06-256

skill-creator

Eslzzyl/tidev

Create or improve AgentSkills for this coding assistant. Use when asked to create a new skill, package a skill, edit an existing skill, or set up skill infrastructure. Guides designing SKILL.md with proper YAML frontmatter, writing effective prompts, organizing companion files, and testing skills.

2026-06-256

inspect-tidev-db

Eslzzyl/tidev

Debug tidev's database by searching session titles, exporting decompressed copies, and inspecting messages. Use when investigating session data, diagnosing storage issues, or auditing conversation history.

2026-05-176

name	git-workflow
description	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.

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/<short-description> or <username>/<feature-name>
- Bug fixes: fix/<issue-number>-<description>
- Chores/refactoring: chore/<description>
- Base feature/fix branches off the default branch (main, master, dev)

Committing

Write clear, conventional commit messages:

<type>: <short summary>                 (subject, max 72 chars)

<body>                                   (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 <from-tag>..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

git merge <branch> or git rebase <branch> will stop at conflicts
Use git status to find conflicted files
Open each file and resolve conflict markers (<<<<<<<, =======, >>>>>>>)
git add <resolved-file> to mark as resolved
git rebase --continue or git merge --continue
Verify the build still works after resolution