Git ルール

git commit や git push は絶対に実行しない — コミットは GPG で署名されるためです。
あなたの仕事は 変更を準備してステージングするだけ (git add) です。ユーザーが GPG + TTY が動作する自身のターミナルで手動でコミットおよびプッシュします。
git stash、git diff、git status、git log、git add、および読み取り専用の git コマンドはすべて問題ありません。
元に戻す/取り消す場合は、git blame を使用して変更を特定し、ミスを減らします。
変更を行う前に、まず現在のリポジトリをフェッチします。上流から進行中の変更がある場合は、マージ/リベースが必要かどうかを尋ねます。

ターゲットブランチへのマージ/リベース

上流の変更を統合する前に、以下の手順を順に実行します。

上流をフェッチ
```
git fetch origin
```
分岐を確認 — 現在のブランチにないターゲット上のコミット
```
git log HEAD..origin/<target> --oneline
```

重複するファイル変更を確認

git diff --name-only HEAD...origin/<target>

マージまたはリベースの前に、現在のブランチの作業と重複する上流のスペック/テスト変更がないかスキャンします。

git diff HEAD...origin/<target> -- \
  '*_spec.rb' '*.spec.*' '*.test.*' \
  'spec/' 'test/' '__tests__/' 'tests/'

上流でスペック/テストファイルが変更された場合:

差分を表示 — どのテストファイルが変更されたか、および何が変更されたかを示します。
ドメインの重複をフラグ — 変更されたテストが、現在のブランチが変更する同じ機能やファイルをカバーしているかどうかを特定します。
先に進む前に尋ねる — 現在のブランチの実装が古いまたは新しく変更されたスペックによってテストされる可能性がある場合は、最初にブランチを更新するか、そのまま進めるかをユーザーに尋ねます。

根拠: 新しい実装を含むブランチに上流のテスト変更をマージすると、CI で false-negative が発生します。テストは古い動作をテストするため合格します。マージ前にスペックのずれを捕捉することで、混乱を招く下流の障害を回避できます。