git

Name: git
Author: iuliandita

github.com/iuliandita開発1045 回インストール1 日前に更新

リポジトリ

git について

GitHub、GitLab、ForgejoをまたぐGit操作と本番ワークフローを扱うスキルです。日常の変更からリリース、復旧、セキュリティ、監査向け履歴までをカバーします。

主な機能

01コミット、ブランチ、マージ、リベースの手順
02複数リモートと複数Forgeの管理
03PR/MR作成とリリース準備
04署名、シークレットスキャン、履歴整理
05PCI-DSS変更管理の指針

活用シーン

01コミットの準備と検証
02複数ForgeでのPRまたはMR作成
03ブランチや履歴操作のミスからの復旧
04監査可能なリリース記録の維持

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/iuliandita/skills --skill git

インストール後、Claude Code で/gitを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/

agent-hygiene.md

forge-workflows.md

output-contract.md

recovery-and-maintenance.md

security-and-signing.md

詳細

Git：マルチフォージ本番ワークフロー

GitHub、GitLab、Forgejo 全体で、Git 操作、ブランチ管理、複数リモートの設定、PR/MR の作成、リリースの作成、監査に耐えうる変更履歴の維持を行います。目標は、エンジニアリング基準とコンプライアンス要件（PCI-DSS 4.0）の両方を満たす、整然として署名済みで追跡可能な履歴です。

対象バージョン（2026 年 10 月）：

git：2.56.0（最新安定版、2026-09-28）。追加機能には、git refs の作成・削除・更新・名前変更、fetch.followRemoteHEAD、git history drop が含まれます。2.55 では Linux の fsmonitor、リモートグループへのプッシュ、並列実行に対応したフックが追加されました。
GitHub CLI（gh）：2.102.0
GitLab CLI（glab）：1.120.0
Forgejo CLI（fj）：0.6.0（Codeberg の最新リリース。2026-10-02 に再確認済み。fj pr merge --help は 9 月 25 日に確認済み。ソースは codeberg.org/forgejo-contrib/forgejo-cli）。Rust 製の公式コミュニティ CLI です。PR（AGit を含む）、イシュー、リポジトリ、リリース、タグ、アクションに対応しています。
Forgejo：v16.0.5 が現行版、v15.0.9 が現行 LTS 版です（いずれも 2026-09-17）。重大な RCE（CVE-2025-68937）は v13.0.2 以降で修正されています。
prek：0.5.4（Rust 製、推奨）または pre-commit：4.6.2（Python 製、最大のエコシステム）
git-filter-repo：2.47.0
gitleaks：8.30.1（シークレットスキャン）
cosign：3.1.3（タグ／リリースの署名に関するコンテキストでの Sigstore）

このスキルは、状況に応じて次の 5 つの領域を扱います：

操作 - コミット、ブランチ、マージ、リベース、スタッシュ、二分探索、reflog、復旧
リモートとフォージ - 複数リモートの設定、GitHub／GitLab／Forgejo の違い、ミラーリング
PR/MR ワークフロー - フィーチャーブランチ、レビューの流れ、マージ戦略、リリースの作成
セキュリティ - コミット署名、認証情報の管理、フック、シークレットスキャン、履歴の除去
コンプライアンス - PCI-DSS 4.0 の変更管理、監査証跡、統制としてのブランチ保護

使用する場面

コミットを作成する（メッセージのスタイル、署名、作成者情報）
ブランチを管理する（作成、整理、保護、命名）
リモートを操作する（プッシュ、プル、フェッチ、複数リモートの同期）
PR/MR を作成する（タイトル、説明、レビュープロセス、マージ戦略）
リリースを作成する（タグ付け、変更履歴、GitHub／Forgejo のリリース）
マージコンフリクトを解決する、またはリベースする
ミスから復旧する（reflog、reset、revert、cherry-pick、二分探索）
git を設定する（エイリアス、フック、属性、認証情報、署名）
履歴から機密データを除去する（filter-repo）
ブランチ保護ルールまたはルールセットを設定する
マルチフォージのワークフロー（ミラーリング、トークン管理、SSH キー）
PCI-DSS の変更管理に関する証跡

使用しない場面

CI/CD パイプラインの設計 - ci-cd を使用してください。このスキルが扱うのはパイプライン内の git 操作であり、パイプラインのアーキテクチャではありません。
PR/MR のコードレビュー - code-review を使用してください。このスキルでは PR を作成しますが、その中のコードレビューは行いません。
アプリケーション全体のセキュリティ監査 - security-audit を使用してください。このスキルが扱うのは git の履歴内 のシークレットと git 固有のセキュリティであり、アプリケーションレベルの脆弱性評価ではありません。
Docker イメージのタグ付け戦略 - docker を使用してください。このスキルが扱うのは git タグであり、コンテナタグではありません。
セッション後またはマージ後のドキュメント一括更新（README、変更履歴、ランブック） - update-docs を使用してください。

AI のセルフチェック

AI ツールは、同じ git のミスを繰り返し起こします。git 操作を行う前に、必ず次のリストを確認してください：

パフォーマンス

リポジトリ全体の履歴を検索する前に、パスを限定して git log、git diff、git grep を使用します。
大規模なリポジトリでは、完全なプルーニングが不要な場合、必要なリモートやブランチのみを取得します。
レビューや二分探索ができる程度にコミットを小さく保ちます。ただし、1つの動作を複数のコミットに分割してしまうほど細かくしないでください。

ワークフロー

ステップ 1：フォージとプロジェクトのコンテキストを特定する

シグナル	フォージ
`.github/` ディレクトリ、`gh` CLI	GitHub
`.gitlab-ci.yml`、`glab` CLI、ユーザーが「work」と言う	GitLab
`.forgejo/` ディレクトリ、ユーザーが「home」と言う	Forgejo
`git remote -v` に複数のリモートがある	マルチフォージ

プロジェクトの指示ファイル（AGENTS.md または同等のファイル）を読み、以下を確認します。

コミット規約（メッセージ形式、スコープ一覧、作成者に関する上書き設定）
ブランチ戦略（トランクベース、フィーチャーブランチ、リリースブランチ）
リモートの設定（存在するリモート、プッシュ先、SSH キー）
リリースプロセス（バージョン更新ファイル、タグ形式、変更履歴）
署名の要件（GPG、SSH、または署名なし）
コンテンツの制限（Git の履歴に含めてはならないドメイン、ツール名、パス）

ステップ 2：操作を判断する

「これをコミットして」／「作業を保存して」 -> コミットワークフロー（ステップ 3a）
「PR/MR を作成して」 -> PR/MR ワークフロー（ステップ 3b）
「リリースを作成して」 -> リリースワークフロー（ステップ 3c）
「この混乱を修正して」／「元に戻して」／「復旧して」 -> 復旧操作（ステップ 3d）
「プルに失敗した」／「ブランチが分岐した」 -> 分岐したブランチの解決（ステップ 3e）
「ディレクトリ内のすべてのリポジトリをプル／更新して」 -> 一括リポジトリ更新ワークフロー（ステップ 3f）
「署名を設定して」／「git を設定して」 -> 設定（参考資料）
「履歴を整理して」／「シークレットを削除して」 -> 履歴の書き換え（参考資料）
「ブランチ保護を設定して」 -> 保護ルール（参考資料）

ステップ 3a：コミットのワークフロー

このチェックリストをコピーして、進捗を記録します。

状態と差分を確認する
選択したファイルのみをステージする
ステージ済みの差分を確認する（シークレット、デバッグコード、無関係な変更）
プロジェクトの規約に沿ってメッセージを書く
必要な作成者情報と署名を付けてコミットする
プッシュする前に作成者情報と署名を確認する

状態を確認する：git status（大規模なリポジトリでは -uall を使わない）と git diff（ステージ済みと未ステージの両方）
対象を選んでステージする：git add <specific files> - 含まれる内容を確認せずに git add -A や git add . を実行しないでください。シークレット、バイナリ、生成ファイル、AI ツールの生成物がないか確認します。
差分を確認する：git diff --cached - コミットしようとしている内容を読みます。デバッグコード、TODO コメント、無関係なファイルへの意図しない変更がないか確認します。含めるべきでないものがあれば、ステージを解除して（git restore --staged <file>）、ステップ 2 に戻ります。
メッセージを書く：プロジェクトの規約に従います。デフォルトの形式：

type(scope): concise description

Optional body explaining *why*, not *what*.

type は次から選びます：feat、fix、docs、refactor、chore、ci、build、revert。拡張タイプ（プロジェクトの規約で許可されている場合に使用）：test、perf、security。 必ず最初にプロジェクトの指示ファイルと最近の git log を確認してください。プロジェクトで異なるタイプ一覧や命名規約が定められている場合があります。プロジェクトの指示がこれらのデフォルトより優先されます。

スコープの指定を強く推奨しますが、必須ではありません。スコープを付けると、git log --oneline を確認しやすくなります。例：fix(auth): token expiry と fix: token expiry。コンポーネント、モジュール、または領域の名前を使います。変更が本当に複数の領域にまたがる場合、またはプロジェクトでスコープを使っていない場合に限り、省略します。

破壊的変更：タイプまたはスコープの後に ! を付けます：feat(api)!: drop v1 endpoints。破壊的変更の詳細を記すには、コミット本文のフッターに BREAKING CHANGE: を追加します。

メッセージのガイドライン：

命令形にする（「added feature」や「adds feature」ではなく「add feature」）
1 行目は 72 文字以内
本文は 72 文字で折り返す
変更内容ではなく、変更した理由を説明する（変更内容は差分で確認できます）
該当する場合は、イシューやチケットの番号を記載する
くだけた自然な口調にすること。 AI ではなく、適切なスキルを持つ人が書いたようなメッセージにします。良い例：fix(caddy): self-healing volume permissions、feat(auth): add OIDC login 悪い例：「fix stuff」、「wip」、「update files」、「enhance the robustness of the authentication module」
ASCII 文字のみを使うこと。 コミットメッセージに em ダッシュ、カーリークォート、合字、装飾的な句読点を使わないでください。
コミットメッセージや本文で、ローカルの指示ファイルや AI ツールに言及しないこと。 コード変更と一緒にローカル限定の指示ファイルを更新する場合は、コミットに含めないでください。
Co-Authored-By や AI に関する帰属情報の行を追加しないこと。 Signed-off-by: AI も追加しないでください。コミットのメタデータで特定の AI ツールに言及しないでください。

コミットする：プロジェクト設定で必須とされている作成者情報の上書きや署名フラグを付けてコミットします。
確認する：git log -1 --format="%h %s%n Author: %an <%ae>%n Committer: %cn <%ce>" - プッシュする前に、作成者情報が正しいことを確認します。プッシュ前のコミットで誤っている場合は、ID 設定を修正して git commit --amend --reset-author --no-edit を実行し、このステップをもう一度行います。

ステップ 3b：PR/MR ワークフロー

最初に確認すること：プロジェクトではフィーチャーブランチを使用していますか？プロジェクトの指示ファイルを読んでください。一部のプロジェクト（特に個人開発のプロジェクト）では、方針として main で直接作業します。ここでの既定の手順は、レビューを伴う共同開発を想定しています。実際のプロジェクトのワークフローに合わせてください。

forge 固有の PR/MR 作成パターン（GitHub の gh pr create、GitLab の glab mr create、Forgejo の fj pr create または Web UI/API）については、references/forge-workflows.md を読んでください。まず forge CLI を検出し（command -v gh、glab、または fj）、見つからない場合は、そのリファレンスにあるインストール表か REST API の代替手順を使用してください。

差分とリポジトリのポリシーに基づいて検証項目を選んでください。PR を作成するだけで、完全なビルド、統合テストスイート、リリースパイプラインの実行が正当化されるわけではありません。変更の影響を受けるチェックを実行し、必須のマージゲートに従ってください。同じリビジョンと関連する入力に対して合格済みの結果は再利用してください。CI が不要な作業を行っている場合は、チェックを回避したりパイプライン全体を繰り返し実行したりするのではなく、ci-cd を使ってトリガーとジョブの範囲を調整してください。

一般的な流れ：

フィーチャーブランチを作成する：git checkout -b type/short-description（例：feat/user-search、fix/auth-bypass）。ブランチ名は小文字とハイフンを使い、種類のプレフィックスを付けてください。
変更を加える：早めに、こまめにコミットしてください。各コミットは論理的にまとまった単位にします。
ベースブランチにリベースする：git fetch origin && git rebase origin/main（またはベースブランチに該当するブランチ）。競合を解決します。<<<<<<<、=======、>>>>>>> のマーカーを探し、両側の正しい内容を残してください（多くの場合、両方の追加内容が必要です）。次に git add と git rebase --continue を実行します。依存関係ファイル（package.json、Cargo.toml、go.mod など）の競合を解決した後は、パッケージマネージャーを再実行してロックファイルを再生成してください。ベースブランチをフィーチャーブランチにマージしてはいけません。マージ戦略の詳細は references/forge-workflows.md を参照してください。

依存関係ファイルの競合（package.json、go.mod、pyproject.toml）：両方のブランチからの追加内容を残してください。同じ依存関係のバージョン指定が競合する場合は、両方のブランチの制約と意図を調整したうえで、パッケージマネージャーに互換性のあるバージョンを解決させ、影響を受ける動作を検証してください。ロックファイルを手動で編集してはいけません。マニフェストの競合を解決した後は、必ずパッケージマネージャー（npm install、go mod tidy、uv sync など）を実行して再生成してください。依存関係マニフェストの競合に --ours や --theirs を使ってはいけません。これらを使うと、一方のブランチで追加された内容が気付かないうちに失われます。
プッシュする：git push -u origin feat/short-description。その後、リモートが実際に更新されたことを確認します。git rev-parse HEAD と forge の PR/MR ヘッド SHA を比較してください（gh pr view ...、glab mr view ...、または forge API を使用）。簡潔な出力やエイリアス設定されたプッシュラッパーだけを根拠にしてはいけません。上流ブランチの追跡設定がない、または不自然な場合は、refspec を明示してプッシュし、PR/MR のヘッドを再確認してから、更新が反映されたと判断してください。
PR/MR を作成する：わかりやすいタイトル（70 文字未満）と、概要およびテスト計画を含む本文を作成します。
レビューサイクル：既定では、フィードバックに対応するフォローアップコミットを作成してください。ユーザーの明示的な確認を得て最新の状態をフェッチした後に限り、プライベートなフィーチャーブランチで --force-with-lease を付けてリベースおよびプッシュしてください。共有ブランチの履歴を書き換えてはいけません。
マージする：履歴を整理する場合は squash-merge（既定）を、コミット履歴に意味がある場合は rebase-merge を使用してください。
クリーンアップする：マージ後にリモートブランチを削除します。ローカルでは git branch -d feat/short-description を実行します。

ブランチ命名規則：

feat/description - 新機能
fix/description - バグ修正
refactor/description - コードの再構成
chore/description - メンテナンス、依存関係、設定
docs/description - ドキュメントのみ
ci/description - CI/CD の変更
security/description - セキュリティ修正（非公開のアドバイザリにすべきか検討してください）

ステップ 3c：リリースワークフロー

forge 固有のリリース作成については、references/forge-workflows.md をお読みください。

バージョニング方式：semver vMAJOR.MINOR.PATCH。プレリリースサフィックスは任意です。

バージョン	タイミング	CI の動作
`v0.12.0-alpha.1`	新しいマイナーバージョンの開始、新機能を反復開発中	タグ付け＋リリース（プレリリースとしてマーク）。イメージのビルドはプロジェクトによって任意です。
`v0.12.0-alpha.2`	反復開発の継続、まだ安定していない状態	上記と同じです。
`v0.12.0`	機能が安定し、本番環境で使用できる状態	完全なリリース：タグ付け＋リリース＋イメージのビルド＋デプロイ。
`v0.12.1`	安定版リリースへのパッチ修正	完全なリリース。

アルファ版ワークフロー：

新しいマイナーバージョンの作業を開始するときに、vX.Y.0-alpha.1 のタグを付けます
反復開発に合わせてアルファ番号を増やします（-alpha.2、-alpha.3）
安定したら、-alpha サフィックスを外して vX.Y.0 をリリースします
アルファタグでも GitHub／Forgejo のリリースが作成され（--prerelease としてマーク）、CI で任意にイメージをビルドできます
アルファタグでイメージのビルドを実行するかどうかは、プロジェクトの指示ファイルで定義します

このチェックリストをコピーして、進捗を記録してください：

バージョンファイルを更新済み
バージョン更新コミットを作成済み
注釈付きタグを作成済み
コミットとタグをすべてのリリース用リモートにプッシュ済み
Forge のリリースを作成済み
リリースパイプラインがタグに対して実行されていることを確認済み

一般的な流れ：

バージョン更新：すべてのバージョンファイルを更新します（対象の一覧はプロジェクトの指示ファイルを確認してください。プロジェクトごとに異なります）。
コミット：chore: bump version to X.Y.Z（または chore: bump version to X.Y.Z-alpha.N）
タグ付け：git tag -a vX.Y.Z -m "vX.Y.Z"（軽量タグではなく、注釈付きタグを使用します）。
プッシュ：コミットとタグの両方をプッシュします。git push origin main && git push origin vX.Y.Z。複数のリモートがある場合は、すべてにプッシュします。
リリース作成：GitHub（gh release create）、GitLab（glab release create）、または Forgejo（API／ウェブ）。アルファ版／プレリリースの場合：gh release create vX.Y.Z-alpha.N --prerelease --title "vX.Y.Z-alpha.N"
確認：CI/CD がタグを検出し、リリースパイプラインを開始したことを確認します。開始されていない場合は、タグがリモートに到達していること（git ls-remote --tags origin vX.Y.Z）と、ワークフローのタグトリガーに一致していることを確認してから、ステップ 4 に戻ります。

変更履歴の生成：既定ではプロジェクト既存のツールを使用します。ツールがない場合は、GitHub では gh release create --generate-notes（前回のタグ以降の PR タイトルを使用）を、プロジェクトでコミット済みの CHANGELOG.md を管理している場合は git-cliff を使用します。! マーカーと一貫したスコープを使うと、どちらの出力もより有用になります。

ステップ 3d：復旧操作

詳細な復旧手順（reflog、bisect、rerere、filter-repo など）については、references/recovery-and-maintenance.md をお読みください。

Git でデータが失われることはほとんどありません。reflog の保持期間は設定可能です。デフォルトでは、到達可能なエントリは 90 日、到達不可能なエントリは 30 日間保持されます。期限切れや GC によって、復旧データが削除されることがあります。

クイックリファレンス：

直前のコミットを取り消す（変更は保持）：git reset --soft HEAD~1
直前のコミットを取り消す（変更を破棄）：git reset --hard HEAD~1 - 破壊的な操作です。先に確認してください
プッシュ済みのコミットを取り消す：git revert <sha>（新しいコミットを作成するため、共有ブランチでも安全です）
失われたコミットを見つける：git reflog - 保持されている HEAD の移動を表示します。固定の復旧期間があると考えないでください
問題の原因となったコミットを見つける：git bisect start && git bisect bad && git bisect good <sha>
テストスクリプトを使った自動 bisect：git bisect start HEAD v1.0.0 && git bisect run bun test src/auth.test.ts - 各 bisect ステップでテストを自動実行します。終了コード：0 = 問題なし、125 を除く 1～127 = 問題あり、125 = このコミットをスキップ、128～255 = bisect を直ちに中止します。CI との統合に最適です：git bisect run ./scripts/ci-check.sh
直近の N 個のコミットをスカッシュする（対話型リベースなし）：git reset --soft HEAD~N && git commit -m "feat: combined change" - N 個のコミットをリセットしますが、すべての変更はステージ済みのまま保持し、それらを 1 つのコミットとして作成します。自動化された環境では git rebase -i より安全です。
削除されたブランチを復旧する：git reflog で SHA を見つけ、git checkout -b branch-name <sha> を実行します
履歴からシークレットを消去する：command -v git-filter-repo >/dev/null || { echo "install git-filter-repo (pipx install git-filter-repo, or the distro package)" >&2; exit 1; } を確認し、存在しない場合は停止します。次に、シークレットマネージャーまたはエコーを無効にした標準入力から値を設定した、モード 0600 の一時置換ファイルを GIT_FILTER_REPO_REPLACEMENTS に設定します。その後、: "${GIT_FILTER_REPO_REPLACEMENTS:?set a mode-0600 replacement file}" に続けて git filter-repo --replace-text "$GIT_FILTER_REPO_REPLACEMENTS" を実行します。使用後は通常の方法で一時ファイルを削除します。漏えいした値を argv、コマンド文字列、シェル履歴に絶対に含めないでください。その後、チームと調整し、明示的な承認を得たうえで、各 ref に対する --force-with-lease と書き換え前の bundle を使って、すべてのブランチとタグを強制プッシュします（詳細は references を参照）。references を参照してください。

ステップ 3e：分岐したブランチの解決

git pull が「divergent branches」で失敗する場合や、git status に「have diverged」と表示される場合：

分岐の状況を把握する：git log --oneline HEAD..origin/branch（リモート側にあるコミット）と git log --oneline origin/branch..HEAD（ローカル側にあるコミット）を確認します。
状況に応じて方針を選ぶ：
- 自分のコミットが重要な場合（個人作業でよくあるケース）：git pull --rebase origin branch - ローカルのコミットをリモートの先頭にリプレイします。
- リモートのコミットが重要な場合（誰かが強制プッシュした、またはローカルの変更を破棄したい場合）：git reset --hard origin/branch - 破壊的な操作です。先に確認してください。
- 双方に実作業がある場合（共同作業での分岐）：git pull --rebase origin branch を実行し、各ステップで競合を解決してから git rebase --continue を実行します。
- まだ状況がわからない場合：方針を選ぶ前に、両方の履歴とリポジトリのポリシーを確認します。設定に依存する pull を調査目的で実行しないでください。
解決後：git log --oneline -10 で履歴が正しいことを確認します。
再発を防ぐ：共有ブランチへの強制プッシュが原因の場合は、ブランチ保護を設定します。コミット前に pull を忘れたことが原因の場合は、pull 時のデフォルトをリベースにする git config pull.rebase true の設定を検討してください。

Step 3f: リポジトリの一括更新ワークフロー

ディレクトリ内の多数のリポジトリを取得または更新するよう依頼された場合は、順次実行し、監査可能で慎重な手順を維持してください。リポジトリごとに、以下を記録します。

ブランチ、アップストリーム、変更状態を記録済み
フェッチしてファストフォワード済み（または理由を添えてスキップ済み）
あればスタッシュを再適用し、検証済み
ahead/behind と porcelain ステータスを確認済み

まず実際のリポジトリルートだけを検出します。通常は、ユーザーが明示的に再帰的なスキャンを求めない限り、指定されたディレクトリの直下にあるディレクトリです。ベンダー管理のリポジトリ、ワークツリー、依存関係キャッシュ、生成されたチェックアウトは避けてください。
リポジトリは並列ではなく、順次処理します。これにより、SSH リモートへの過剰なアクセス、レート制限、ファイアウォールによる保護の作動を防げます。
各リポジトリについて、変更を加える前にブランチ、アップストリーム、変更状態を記録します。
git fetch --all --prune を実行し、アップストリームがある場合に限り git pull --ff-only --recurse-submodules を実行します。一括メンテナンス中にマージコミットを作成してはいけません。サブモジュールがある場合は、プル後に git submodule update --init --recursive も実行します。--recurse-submodules は既存のサブモジュールのチェックアウトを更新しますが、最後のプル以降に追加された新しいサブモジュールは初期化しないためです。
ローカルの変更をスタッシュする許可を得ている場合は、元のインデックスとワークツリーの差分を記録し、名前付きスタッシュを作成してファストフォワードした後、そのスタッシュの正確なオブジェクト ID を指定して git stash apply --index を実行します。内容とステージ済み／未ステージの区分の両方を検証するまで、スタッシュを保持してください。
インデックスの適用で競合が発生した場合は、スタッシュを保持し、そのリポジトリの更新を停止します。保存したステージ済みパッチと未ステージパッチを慎重に照合して解決してください。ユーザーの作業を一括でステージ解除してはいけません。未解決のリポジトリを報告し、独立した他のリポジトリの処理を続けます。
各リポジトリで git rev-list --left-right --count HEAD...@{u} と git status --porcelain を実行して検証します。変更が残っているリポジトリ、またはアップストリームがないリポジトリを報告してください。

複数 Forge のパターン

多くのプロジェクトでは、複数の Git リモートを使用します（例：セルフホスト可能な CI 用の Forgejo と公開リリース用の GitHub、または職場の GitLab とオープンソースミラー用の GitHub）。

origin は主要な開発用リモートとして維持し、ミラーには明示的な名前を付けます。
複数のリモートへのプッシュは明示的に行い、「すべてのリモートにプッシュ」をデフォルトにしないでください。
Forge ごとに別の SSH キーを使用します。
CLI 認証は環境変数（特に GITHUB_TOKEN）によって上書きされる場合があることを忘れないでください。

詳細な複数 Forge のワークフローについては、references/forge-workflows.md を参照してください。

コミット署名

署名されていないコミットの作成者情報は簡単に偽装できるため、コミットに署名してください。
ほとんどのチームでは、SSH 署名をデフォルトとして推奨します。
長期間にわたる鍵のライフサイクルやポリシー上の要件がある場合は、GPG も引き続き重要です。
gitsign は管理負担の少ないオープンソースのワークフローに適していますが、信頼モデルが変わります。

署名の詳細な設定については、references/security-and-signing.md を参照してください。

セキュリティ

.env ファイル、鍵、埋め込み接続文字列などの認証情報をリポジトリに含めないでください。
平文での保存ではなく、安全な認証情報ヘルパーを使用してください。
シークレット、Lint、ブランチ保護にはフックを使用できますが、信頼できないフックの設定はコード実行の入り口として扱ってください。
シークレットが履歴に含まれていた場合は、履歴から消去してローテーションしてください。履歴を書き換えても、漏えいが取り消されるわけではありません。
.gitignore と .gitattributes は意図的に管理してください。AI ツールの生成物は、デフォルトではリポジトリに含めないでください。

セキュリティと署名に関する詳しいガイダンスについては、references/security-and-signing.md を参照してください。

PCI-DSS 4.0 変更証跡

PCI の対象範囲に含まれるリポジトリでは、保護されたブランチ、必須レビュー、テストおよびセキュリティチェックとの紐付け、ならびに組織に適用されるソフトウェア変更管理に関する統制のために、forge の監査証跡を保持またはエクスポートしてください。各統制を現行の PCI DSS の文面に対応付ける際は、評価担当者と確認してください。Git の設定だけでは、トレーニング、環境の分離、または変更管理プロセス全体の証明にはなりません。署名付きコミットは、選択した信頼モデルに基づいて署名鍵を認証します。署名者がセキュリティトレーニングを修了したことや、変更がレビュー、テスト、または承認されたことを証明するものではありません。

参考ファイル

references/forge-workflows.md - GitHub、GitLab、Forgejo 固有の PR/MR、リリース、ブランチ保護、ルールセット、CLI の使用方法、API 呼び出しのパターン
references/security-and-signing.md - コミット署名の設定（SSH/GPG/gitsign）、認証情報の管理、シークレットスキャン、CVE 参照、git セキュリティの強化
references/recovery-and-maintenance.md - reflog、bisect、rerere、filter-repo、stash、worktree、submodule/subtree、大規模リポジトリの最適化、ハウスキーピング

出力仕様

仕様の全文については、references/output-contract.md を参照してください。

スキル名： GIT
成果物の分類： audits
モード： 条件付き。既存のリポジトリコンテンツの分析、レビュー、監査、改善を依頼された場合は、references/output-contract.md にあるレポートの分量と証拠に関するルールに従い、成果物を docs/local/audits/git/<YYYY-MM-DD>-<slug>.md に作成してください。質問への回答、概念の説明、新しい成果物の作成、コンテンツの生成を依頼された場合は、仕様に縛られず自由に回答してください。
重大度の尺度： P0 | P1 | P2 | P3 | info（共通仕様を参照。監査／レビューモードでのみ使用）

ルール

上記の AI セルフチェックには、操作ごとのガード（破壊的な操作の確認、作成者情報、選択的ステージング、フック、タグ、force-push、管理者の承認）が定められています。これに加えて、以下を適用します。

クリーンアップの対象を事前に表示してください。 ブランチ、タグ、または無視対象ファイルを削除するコマンドは、削除対象を先に列挙せずに実行してはいけません。
共有ブランチでは履歴の書き換えより revert を優先してください。 履歴の書き換えには force-push が必要となり、他のすべてのクローンに影響します。
共同作業にはフィーチャーブランチを使用してください。 他の人が作業をレビューする場合は、PR/MR を伴うフィーチャーブランチを使用してください。ユーザーが明示的に希望する場合、個人プロジェクトでは main への直接の変更も許容されます。
Rebase ワークフロー。 フィーチャーブランチをベースブランチの上に rebase し、ベースブランチをフィーチャーブランチに merge しないでください。コミット履歴に意味がある場合を除き、履歴を整理するため、マージ時に squash してください。
リリースには注釈付きタグを使用してください。 軽量タグではなく、git tag -a vX.Y.Z -m "vX.Y.Z" を使用してください。注釈付きタグにはメタデータ（タグ作成者、日付、メッセージ）が含まれ、forge がリリースに使用するタグです。
PCI-DSS の証跡。 規制対象の環境では、git 履歴そのものが監査証跡です。署名付きコミット、ブランチ保護、必須レビュー、リリースブランチでの履歴の書き換え禁止によって保護してください。

Markdown 対応

ログインしてコメント

基本情報

作者: iuliandita
リポジトリ: iuliandita/skills
カテゴリ: 開発
インストール数: 45
GitHub スター: 10

問題を報告

git