スキル git-workflow
📦

git-workflow

安全

Git ワークフローを自信を持ってマスター

こちらからも入手できます: Cain96,0xDarkMatter,0xDarkMatter,Joseph OBrien,Doyajin174,Joseph OBrien,Barnhardt-Enterprises-Inc,AI-Vibe-Prompts

Git のブランチ、マージ、コンフリクトに悩んでいませんか？このスキルは、チームコラボレーションのためのベストプラクティスを含む、すべての Git 操作に対する明確でステップバイステップのガイダンスを提供します。

対応: Claude Codex Code(CC)
📊 71 十分
1

スキルZIPをダウンロード

2

Claudeでアップロード

設定 → 機能 → スキル → スキルをアップロードへ移動

3

オンにして利用開始

テストする

「git-workflow」を使用しています。 ログイン機能追加のためのコミットメッセージを書いてください

期待される結果:

feat(auth): implement user login system

- Add login form component with validation
- Create authentication API endpoint
- Integrate session management middleware
- Add unit tests for login flow

Closes #156

「git-workflow」を使用しています。 最後のコミットを元に戻したいのですが、変更は保持したままにできますか？

期待される結果:

使用: git reset --soft HEAD~1

これによりコミットが削除されますが、すべての変更はステージングされたまま保持されます。ステージングも解除したい場合は、git reset HEAD~1 を使用してください。

セキュリティ監査

安全
v2 • 3/9/2026

This skill is a documentation-only guide for Git workflows. Static analysis flagged 77 shell command patterns, 6 URLs, and 14 crypto patterns, but all are false positives. The detected patterns are Markdown code blocks (```bash) and inline code markers (`command`) used for documentation formatting, not executable code. URLs are reference links to official Git documentation. No actual security risks exist.

2
スキャンされたファイル
550
解析された行数
0
検出結果
2
総監査数
セキュリティ問題は見つかりませんでした
監査者: claude 監査履歴を表示 →

品質スコア

38
アーキテクチャ
100
保守性
85
コンテンツ
33
コミュニティ
100
セキュリティ
87
仕様準拠

作れるもの

新規開発者のオンボーディング

ジュニア開発者が、ブランチング、コミット、コードのマージを安全に行うためのガイド付き例を通じて、適切な Git ワークフローを学べるように支援します。

チームワークフローの標準化

開発チーム全体で、一貫性のあるコミットメッセージ形式とブランチ命名規則を確立します。

コンフリクト解決の支援

機能統合中に複雑なマージコンフリクトに直面した際、明確なステップバイステップのガイダンスを提供します。

これらのプロンプトを試す

基本的なコミットメッセージ 
アプリケーションに JWT トークンを使用したユーザー認証を追加する変更のためのコミットメッセージを書くのを手伝ってください。
ブランチの作成とセットアップ 
ショッピングカートの新機能の作業を開始する必要があります。どのブランチを作成すべきで、どのように作成すればよいですか？
マージコンフリクトの解決 
機能ブランチを main にリベースする際にコンフリクトが発生しています。ステップバイステップで解決方法を教えてください。
クリーンアップのためのインタラクティブリベース 
機能ブランチに 5 つのまとまりのないコミットがあります。main にマージする前に、これらを squash して整理するのを手伝ってください。

ベストプラクティス

  • 一度に 1 つのことだけを変更する、小さく焦点を絞ったコミットを書く
  • 慣用的なコミット形式を使用する：type(scope): subject
  • 新しい作業を開始する前に、常に最新の変更をプルする
  • main ブランチに直接コミットしない
  • 履歴をクリーンに保つために、マージ後は機能ブランチを削除する

回避

  • 'fix'や'update'などのメッセージでコミットする - 何を変更したか具体的に記述する
  • --force-with-lease なしで git push --force を使用する - チームメイトの作業を上書きする可能性がある
  • 無関係な変更の大きなバッチをコミットする - レビューとロールバックが困難になる
  • マージコンフリクトを無視して強制プッシュする - コードの損失につながる

よくある質問

git merge と git rebase の違いは何ですか？
merge は 2 つのブランチを結合する新しいコミットを作成し、履歴を保持します。rebase はコミットを別のブランチの上部で再再生成することでコミット履歴を書き換え、直線的な履歴を作成します。共有ブランチには merge を、ローカル機能のクリーンアップには rebase を使用してください。
すでにプッシュされたコミットを元に戻すにはどうすればよいですか？
git revert <commit-hash> を使用して、変更を元に戻す新しいコミットを作成します。これは共有ブランチの場合、履歴を保持し force push が不要になるため、reset より安全です。
間違ったブランチにコミットしてしまった場合はどうすればよいですか？
git branch correct-branch で現在の状態から新しいブランチを作成します。次に git reset --hard HEAD~1 で間違ったブランチをリセットします。最後に、正しいブランチを checkout します。
どのくらいの頻度で main から変更をプルすべきですか？
長期間の機能作業中は、少なくとも 1 日 1 回 main から変更をプルしてください。これにより、ブランチをチームの変更に最新の状態に保ち、マージコンフリクトを軽減できます。
git stash とは何ですか？いつ使用すべきですか？
Git stash は、コミットされていない変更を一時的に保存し、ブランチを切り替えることができるようにします。作業のコミット準備ができていないが、すぐにコンテキストを切り替える必要がある場合に使用します。
慣用的なコミットとは何ですか？なぜ使用するべきですか？
慣用的なコミットは標準形式を使用します：type(scope): description。タイプには feat、fix、docs、refactor、test、chore があります。これにより明確な履歴が作成され、自動変更ログ生成が可能になります。

開発者の詳細

作成者

supercent-io

ライセンス

MIT

リポジトリ

https://github.com/supercent-io/skills-template/tree/main/.agent-skills/git-workflow/

参照

main

ファイル構成

📄 SKILL.md

📄 SKILL.toon