Gitの始め方｜個人のファイル管理から覚えるコミットとブランチの基本
差分の確認とコミットの分け方
変更してから記録するまでの手順
最初のコミットができたら、memo.mdの最後へ「サイズは持ち歩けるものを選ぶ。」と一行追記し、保存します。ここからは、記録済みのファイルを変更するいつもの流れです。コマンドをまとめて流さず、確認結果を読んでから次へ進みます。
git statusで、変更されたファイルが想定どおりか見ます。git diffで、まだステージしていない変更を読みます。git add memo.mdで、今回記録する内容を選びます。git diff --stagedで、コミットへ入る内容を読み直します。git commit -m "ノートのサイズを選ぶ条件を追記"で記録します。git statusとgit log --onelineで、残った変更と履歴を確認します。
通常のgit diffは、作業ツリーとステージングを比べます。git diff --stagedは、ステージングと直近のコミットを比べます。この二つの見ている場所は違うため、addの後で通常のdiffが空でも、記録予定の変更がなくなったわけではありません。git-diffの公式資料にも比較対象が整理されています。
まだ一度も追加していない新規ファイルは、通常のdiffだけでは内容を確認できません。statusで存在を確かめ、エディターで中身を読み、addした後にdiff --stagedを確認します。「差分が出ないから何もない」と判断せず、ファイル一覧と内容の両方を見る習慣を付けます。
差分の本文では、行頭の+が追加、-が削除です。一文字の訂正も、元の行の削除と新しい行の追加として見えることがあります。行全体を書き直した操作とは限りません。
一つの目的を一つのコミットにする
よい区切りの目安は、変更の目的を一文で説明できることです。「ノートのサイズを選ぶ条件を追記」と「メモの見出しを統一」は別の理由なので、分けると後で探しやすくなります。逆に、見出しと目次を合わせて直すなど、一緒に変えないと不自然になる変更はまとめてかまいません。
コミットの単位はファイル数で決まりません。三つのファイルでも、同じ設定の説明をそろえる目的なら一つにできます。無関係な変更が混ざりやすい場合は、一つの修正を記録してから次に取りかかると扱いやすくなります。
説明文は「修正」「更新」だけで終えず、対象と変更を入れます。「設定メモに保存先を追記」「買い物メモの重複項目を整理」のように書くと、一覧だけでも探せます。理由が本文から読み取れない変更なら、「持ち歩くためノートの条件を変更」のように、判断の背景を短く含めます。
個人用なら説明文を日本語にしても問題ありません。一日の終わりに一括で記録するより、説明できる区切りで残す方が、途中の案も探しやすくなります。
設定ファイルを管理する場合
設定ファイルも、変更した項目が見える点でGitに向いています。練習には秘密情報を含まないsettings-example.txtを作り、表示色などの例だけで試します。
改行や空白が自動整形されると、小さな変更でも差分が大きくなります。内容と書式の変更を分ければ、理由を読み取りやすくなります。改行の警告が出たときは、設定をむやみに変えず保存形式を調べます。
.gitignoreと秘密情報の扱い
記録しないものを先に決める
.gitignoreは、まだ追跡していないファイルをGitの管理対象から除外するための設定ファイルです。自動生成の一時ファイルやログ、個人専用の設定を候補に出しにくくできます。フォルダーの先頭に置き、必要なパターンを一行ずつ書きます。
例えば、.envを秘密の設定用、privateを個人資料用、tempを再作成できる一時ファイル用と決めた場合の記述です。実際の秘密情報で試す必要はありません。
/.env
/private/
/temp/
*.log先頭の/は、この.gitignoreの場所を基準にします。末尾の/はディレクトリの指定です。*.logは別の拡張子には効きません。用途に合うルールを決め、git statusで候補を確認します。
.gitignore自体も、git add .gitignoreで選んでコミットします。慣れるまでは一括追加を避け、ファイル名を指定すると、意図しない資料を混ぜにくくなります。
除外ルールは秘密情報の保護を保証しない
パスワード、APIキー、秘密鍵、トークンなどは絶対にコミットしません。用途に合う認証情報の保管方法を使い、サンプル設定には実際の値を入れず、形式や項目だけを示します。
.gitignoreに書いても、すでに追跡しているファイルには効きません。過去のコミットから内容を消す機能もありません。この点はgitignoreの公式資料に明記されています。名前を変える、ファイルを削除して次のコミットを作る、といった操作だけでは、以前の履歴にある秘密情報は残ります。
秘密情報を外部へ送ってしまった場合は、削除だけで安全になったと考えず、その鍵やトークンの無効化・再発行を優先します。履歴の修正は影響が広いため、サービスの公式手順を確認し、共同利用なら管理者にも相談してください。
ステージした段階で気づいたなら、コミットを止め、後述のステージ解除で対象を外して保管方法を直します。すでにコミットした場合は、外部へ送る前に気づくことが大切です。送信を止め、過去の履歴を含めた対応を確認するまで公開しません。判断に迷う鍵は交換を検討します。
対応の詳細は、GitHub公式の機密データ削除ガイドで確認できます。非公開でも、後で共有や複製があり得るため秘密情報は入れません。
ブランチで別案を試してマージする
ブランチは履歴の分かれ道
ブランチは、あるコミットから別の変更を進めるための名前です。今使う版を残し、別案を履歴として記録できます。個人のメモなら、日付順から目的別へ並べ替える案を試す場面で役立ちます。
mainを普段使う内容、organize-notesを整理案とします。切り替えると同じ作業フォルダーの中身が、そのブランチの記録に合わせて変わります。エディターの表示も確認してから編集します。
作成から取り込みまでの順番
以下は最初のコミットがあり、git statusで未コミットの変更がない状態から行います。.gitignoreの追加などが残っていれば、それを先に確認して記録します。
git switch -c organize-notesで、新しいブランチを作って移ります。memo.mdの表題を「休日の買い物メモ」へ直して保存します。git diffで読み、git add memo.mdで選びます。git commit -m "買い物メモの表題を用途別に変更"で記録します。git switch mainで元へ戻り、表題が元の状態に戻ることを見ます。- 整理案を採用するなら、
git merge organize-notesでmainへ取り込みます。 git statusとgit log --onelineで結果を確認します。
switch -cは作成と切り替え、switch mainは既存のブランチへの切り替えです。mergeは、今いるブランチへ指定したブランチの変更を取り込みます。取り込み先に移ってから実行する順番が大切です。git-switchの公式資料で指定の意味を確認できます。
この例では、通常はFast-forwardと表示され、整理案の先端までmainが進みます。両方で別々に進んでいる場合は、二つの流れを合わせるコミットが作られることがあります。
未コミットの変更は切り替え先へ残る場合も、上書きを避けて切り替えが止まる場合もあります。ブランチだけに保存されたと思わず、切り替え前に記録します。停止時は強制せず、変更を確認してください。
