Git

GitHub ActionsはGitHubリポジトリ内のYAMLでワークフローを定義し、プッシュやプルリクエストなどのイベントをトリガーにビルド

大規模なリポジトリで外部ライブラリや共通コンポーネントを別リポジトリとして再利用したいとき、Gitのsubmodule（サブモジュール

Gitで「いつからバグが入ったのか分からない」状況に直面したら、git bisectを使って問題を導入したコミットを高速に特定できます

Gitでブランチを削除しようとして「チェックアウト中なので削除できない」 あるいは「未マージのため -d では削除できない」と

Gitで作業を巻き戻したいときによく使われるのがrevertとresetです。どちらも「履歴を戻す」ためのコマンドですが、仕組みや使いどこ

Gitでソフトウェアのバージョンを明確に管理するために便利なのが「タグ（tag）」です。特定のコミットにラベルを付けることで、リリ

Gitで複数のブランチを統合する方法には、mergeとrebaseの2種類があります。どちらも目的は「別ブランチの変更を取り込む」ことですが

Gitはバージョン管理システムとして最も広く利用されており、開発の効率化に欠かせません。ここでは初心者から中級者が実務でよく使う

Git を使っていると「origin」と「upstream」という名前をよく目にします。どちらもリモートリポジトリを指しますが、役割や使い

rebase 中にコンフリクトや操作ミスで止まってしまったときは、まず「今どの段階で止まっているか」を把握し、適切なコマンドで前

GitHub を使っていると、リモートリポジトリへの接続時に以下のエラーが出ることがあります

pull の直後に「意図しないファイルが消えた」ように見える場合でも、原因を切り分けて対処すれば高確率で復元できます。 多くは

意図しないマージを取り消して履歴を元に戻したいとき、公開済みのブランチでは履歴を書き換えずに「マージを打ち消す」ことが基本

リポジトリの履歴にAPIキーやパスワードなどの機密情報を誤ってコミットしてしまった場合、単にrevertで変更を取り消すだけでは不十分

誤って master / main を削除してしまった——血の気が引く事故ですが、Gitには強力な復旧手段があります。 多くのケースでは、ローカ

サブモジュールの更新が手元に反映されない原因は、単なる「pullし忘れ」だけではありません。 “親リポジトリが指すコミット（

「pushしたら、別ブランチの変更まで混ざってしまった」——共同開発では珍しくありません。 原因の多くは、作業ブランチを切り忘れて

「コミット履歴が二重に並んで見える」「同じ変更が別のハッシュで繰り返し出てくる」という現象は、単なる見た目の問題ではなく、 履歴の

「さっき git stash したはずの変更が消えた？」——そんなときでも、慌てなければ高確率で復元できます。 stashは内部的には“

pullのたびにマージコミットが雪だるま式に増え、履歴が読みにくくなることがあります。 これはgit pullの既定動作が「フェッチ＋マ