収録問題 40問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
共有済みコミットの変更を安全に打ち消したい。適切な操作は？
答え： git revertで逆変更コミットを作る
revertは公開履歴を書き換えず逆変更を追加するため、共同作業に適します。
機能ブランチへmainの最新変更を取り込み、共同作業者の履歴を壊したくない。適切なのは？
答え： mainをfeatureへmergeする
共有ブランチではmergeなら既存コミットIDを保持したまま変更を統合できます。
誤って別ブランチに作成した1コミットだけを現在のブランチへ取り込みたい。使う操作は？
答え： git cherry-pick <commit>
cherry-pickは指定コミットの変更を現在のブランチへ新しいコミットとして適用します。
コミット前に一部の変更だけをstagingし、残りを後のコミットへ分けたい。適切なのは？
答え： git add -p
git add -pは差分をhunk単位で選んでstagingできます。
秘密鍵を直前の未公開コミットへ誤って含めた。最初に行うべき対応は？
答え： 鍵を失効・交換し、履歴から除去して再発防止する
秘密は履歴に残り得るため、漏えい前提で失効・交換し、履歴除去とsecret scan等を行います。
レビューしやすいPull Requestにする方法として最も適切なのは？
答え： 目的を1つに絞り、小さな差分と検証方法を説明する
小さく目的が明確なPRは影響範囲と検証方法を把握しやすくします。
競合解消後に必ず行うべき確認は？
答え： 競合マーカーがなく、テストと差分確認が通ること
競合解消は構文上成功しても意味的に壊れるため、差分とテストの確認が必要です。
追跡中ファイルを手元には残し、今後はGit管理から外したい。適切なのは？
答え： git rm --cached後に.gitignoreへ追加する
.gitignoreは既に追跡中のファイルには効かないためindexから外す必要があります。
障害を導入したコミットを多数の候補から効率よく特定したい。適切なのは？
答え： git bisectで良否を二分探索する
bisectは既知のgood/bad間を二分探索し、テストを組み合わせて原因を絞れます。
一時的に作業中変更を退避して緊急修正ブランチへ移りたい。適切なのは？
答え： git stash pushで退避し、後で復元する
stashは未完成の変更を一時退避し、作業ツリーを切替可能な状態にします。
リリース時点を後から確実に参照し、署名や説明も残したい。適切なのは？
答え： annotated tagを作成する
annotated tagはタグ作成者・日時・メッセージを持ち、署名も利用できます。
巨大な生成物やバイナリを通常のGit履歴へ繰り返し追加する問題は？
答え： 履歴が肥大化しcloneやfetchが遅くなる
Git履歴は過去版を保持するため大きなバイナリは容量と転送コストを増やします。
mainへの直接pushを防ぎ、レビュー済み変更だけを取り込みたい。適切なリポジトリ設定は？
答え： branch protection rulesでPRレビューと必須checkを要求する
保護ルールは直接pushを制限し、レビューやcheck成功をmerge条件にできます。
履歴を書き換えるrebaseを安全に使いやすい場面は？
答え： まだ共有していない自分のlocal branchを整理するとき
未共有履歴なら他者の参照を壊さずコミット整理ができます。
force pushが必要な自分専用branchで、他者の更新を誤って消すリスクを下げる方法は？
答え： --force-with-leaseを使う
--force-with-leaseは想定したremote先端から変わっていない場合だけ更新します。
CIの主な目的として最も適切なのは？
答え： 小さな変更を頻繁に統合し、自動検証で問題を早期発見する
CIは変更を早く統合・検証し、競合や欠陥の発見を前倒しします。
同じcommitをstagingで検証後、本番へ昇格したい。適切な方法は？
答え： 一度buildしたimmutable artifactを環境間で昇格する
同一artifactの昇格は検証物と本番物の差を防ぎます。
flaky testが時々失敗する。適切な対応は？
答え： 原因を特定して修正・隔離し、無条件retryで隠さない
flaky testを放置するとCIへの信頼が下がり、本物の障害も見逃します。
DB schema変更を後方互換に展開する基本方針は？
答え： expandで追加し両版対応後、切替を確認してcontractする
expand/contractは旧新アプリが混在する期間の互換性を保ちます。
本番デプロイ直後の異常を早く検出する方法は？
答え： 重要SLIとエラー率を自動監視し、閾値超過で停止・rollbackする
リリース判定には利用者影響を表す複数の指標と自動guardrailが有効です。
blue-green deploymentの特徴は？
答え： 旧新2環境を用意し、トラフィック切替でreleaseとrollbackを行う
blue-greenは切替前検証と迅速な戻しをしやすい一方、二重環境コストがあります。
canary releaseの狙いは？
答え： 一部利用者へ新versionを出し、指標確認後に段階拡大する
canaryは影響範囲を限定して本番挙動を検証します。
pipeline secretの扱いとして適切なのは？
答え： secret storeから短期資格情報を取得し、ログをmaskして最小権限にする
短期・最小権限・非表示により漏えい時の影響を抑えます。
依存packageの再現性を高める方法は？
答え： lock fileをcommitし、CIで固定versionを検証する
lock fileは同じ依存解決結果を共有し、予期せぬ更新を減らします。
CI cache設計で避けるべき問題は？
答え： 不十分なkeyで異なる依存状態のcacheを誤共有する
誤ったcache hitは古い依存物を使い、再現しにくい障害を生みます。
並列jobを増やす前に考えるべきことは？
答え： 依存関係、共有resource競合、コスト、律速区間を測る
並列化は高速化できますが、競合・コスト・順序違反を招く場合があります。
本番deploy jobに適した保護は？
答え： 保護環境、承認、限定資格情報、監査ログを設定する
本番は権限と実行条件を絞り、誰が何を出したか追跡可能にします。
pipeline自体の変更を安全に行う方法は？
答え： code reviewし、検証環境またはdry-runで確認して段階反映する
pipelineはproduction経路を制御するcodeなので、アプリ同様のreviewと検証が必要です。
供給網攻撃を減らすpipeline対策は？
答え： 外部actionや依存を信頼済みversion/SHAへ固定し検証する
固定と検証により上流の予期しない変更をそのまま実行するリスクを下げます。
長時間pipelineを改善する最初の一手は？
答え： 各stage/jobの時間を計測し、critical pathを特定する
測定により本当の律速を特定してからcache・並列化・test分割を選べます。
GitHub ActionsでworkflowをPull Request作成時に動かす基本設定は？
答え： on: pull_request
onはworkflowを開始するeventを定義します。
job Bをjob A成功後にだけ実行したい。使うkeywordは？
答え： needs
needsでjob間の依存関係を宣言できます。
古いcommitのdeployをcancelし、同一環境への多重deployを防ぎたい。使う設定は？
答え： concurrencyとcancel-in-progress
concurrency groupで同じ対象のrunを制御し、古いrunをcancelできます。
GITHUB_TOKENを安全に使う方針は？
答え： workflow/jobのpermissionsを必要最小限に明示する
permissionsを限定すると侵害されたstepの影響範囲を小さくできます。
複数repositoryで同じdeploy手順を保守したい。適切な機能は？
答え： reusable workflow
reusable workflowはworkflow全体を共通化し、callerから入力を渡せます。
複数OS・複数versionで同じtestを実行したい。使う機能は？
答え： strategy.matrix
matrixは変数の組合せごとにjobを展開します。
外部action参照の改ざんリスクを最小化する最も厳格な方法は？
答え： 検証済みの完全commit SHAへpinする
完全SHAは実行codeを特定commitへ固定します。更新は監査して明示的に行います。
本番deploy前に承認と環境secretを適用したい。使うものは？
答え： GitHub environmentのprotection rulesとsecrets
environmentは対象jobへ承認規則や環境別secretを適用できます。
fork由来PRのworkflowでsecretを扱うときの安全な考え方は？
答え： 信頼できないcodeへsecretやwrite tokenを渡さず、権限昇格eventを慎重に分離する
forkのcodeは攻撃者が制御可能とみなし、機密処理と分離します。
失敗したworkflowの調査で最初に見るべきものは？
答え： 失敗job/stepのlog、入力context、直前の変更
失敗箇所のlogと変更差分から、権限・入力・環境・command失敗を切り分けます。