Gitの始め方｜個人のファイル管理から覚えるコミットとブランチの基本
コンフリクトの理由と直し方
一人でも同じ箇所を別々に変えると起こる
コンフリクトは、複数の変更をGitだけでは安全に合わせられない状態です。例えば、同じコミットから分かれた二つのブランチで、同じ表題をそれぞれ別の言葉へ変更した場合です。どちらを採用するかは文章の意図に関わるため、Gitが自動で決めずに待ちます。
別の箇所の変更なら、自動で取り込める場合もあります。一方で、片方が削除、もう片方が編集したファイルなども競合します。どの変更同士を合わせようとしているか確認します。
前の節の例では通常は競合しません。ここでは、二つのブランチで表題を別々にコミットした後、mainでgit merge organize-notesを実行した別の状況を考えます。再現するなら別の練習フォルダーで、未コミットの作業を残さず始めます。
止まったファイルを一つずつ直す
テキストの競合では、次のような印が入る場合があります。どちらの内容かを示す印で、本文には残しません。設定により表示は変わります。
<<<<<<< HEAD
# 毎週の買い物メモ
=======
# 休日の買い物メモ
>>>>>>> organize-notesこの通常のマージの例では、上側が取り込み先として開いているmain側、下側が取り込もうとしているorganize-notes側です。HEADは今見ているコミットを指し、普段のブランチ上ではそのブランチの先端を示します。「上側が常に正しい」「下側が新しい」とは決められません。
git statusで競合したファイルを確認します。- ファイルを開き、両方の変更の目的と周囲の文章を読みます。
- 採用する内容へ手で直し、競合の印と不要な行を取り除きます。
- 保存後に全文を読み、表題や参照先も含めて意味が通るか見ます。
git add memo.mdで、そのファイルを解消済みとして登録します。git statusで残る競合がないか確認し、git diff --stagedも読みます。- すべて解消できたら、
git commit -m "買い物メモの表題の競合を解消"で完了します。
二つの表題を単純に両方残す必要はありません。最終的に「週末の買い物メモ」という別の表題へまとめても、目的に合っていれば解消になります。設定ファイルでは、印を消すだけでなく、項目の重複や書式の誤りがないか、その形式に合う方法で確かめます。
addの成功は、内容の正しさの保証にはなりません。エディターで「両方を採用」しても、文章の重複や設定の矛盾は自分で確認します。公式のマージの解説にも確認手順があります。
restoreで取り消す前の確認
ステージ解除と内容の破棄を分ける
取り消すときは、次のコミットから外す操作と、編集内容を捨てる操作を分けます。戻す先と失う内容が異なります。以下は最初のコミットが済んだ、通常の追跡済みファイルの例です。
| 操作 | 戻す対象と基準 | 作業中の本文 |
|---|---|---|
git restore --staged memo.md |
ステージングを直近のコミットに合わせる | 編集した内容は残る |
git restore memo.md |
作業ツリーをステージングに合わせる | そこからの未ステージ変更を失う |
git restore --staged memo.mdは、「今回の記録にはまだ入れない」と選び直す場面で使います。実行後にgit statusを見れば、変更がステージ済みから未ステージへ移ったことを確認できます。ファイルの本文を元へ戻す操作ではありません。
git restore memo.mdは作業中のファイルを書き換えます。例えば、本文の一行を直してaddした後、もう一行を追記していた場合は、addした時点へ戻ります。必ず直近のコミットへ戻るわけではありません。git-restoreの公式資料では、--stagedの有無で既定の復元元が違うことを確認できます。
実行する前に残す内容を選ぶ
取り消す前は、git status、git diff、git diff --stagedで変更の場所を確かめます。残すか迷う本文は、秘密情報にも注意して別の適切な場所へ控えます。対象はフォルダー全体にせず、一つのファイルを指定します。
コミットしていない変更を捨てると、Gitから戻せないことがあります。エディターの取り消し履歴があるはず、とも考えないでください。restoreは過去のコミットを一つ消す操作でも、間違った記録を自動で修正する操作でもありません。履歴に残した内容の訂正とは分けて扱います。
競合の処理中は通常の編集時と状態が違います。分からなくなったらrestoreを繰り返さず、statusの説明を読んで止まります。相談時は鍵や個人情報を除き、状態と実行したコマンドを伝えます。
Gitの向き不向きとバックアップ
行ごとに見比べたいものに向いている
Gitが扱いやすいのは、Markdownのメモ、プログラム、秘密情報のないテキスト設定などです。行ごとの差分と変更理由を残したいものなら、少量でも役立ちます。実験前後の記録にも向いています。
冒頭のWord文書も記録自体はできますが、標準のテキスト差分で修正を読みやすく追えるとは限りません。版の混乱に悩んでいても、形式によっては文書作成アプリの履歴機能の方が、比較や共同編集に合います。
写真や動画、大きな圧縮ファイルを繰り返し更新すると、過去のデータも蓄積して複製や移動の負担が増えやすくなります。写真検索や動画プレビューには専用の道具を選び、Gitには編集手順や素材一覧だけを置く使い分けもできます。
小さな画像も含め、更新頻度、過去の版の必要性、履歴を含む容量で判断します。
履歴と元のファイルを同時に失わないようにする
同じパソコンにしか履歴がなければ、故障や紛失で本文と履歴を同時に失う可能性があります。コミットしても別の機器へは複製されません。必要な資料を別の保存先へバックアップします。
ホスティングサービスに送った履歴があっても、未コミットの変更や未追跡のファイル、除外した個人用データまで含まれるとは限りません。復元したいものが何かを先に決め、Gitで残す範囲とバックアップする範囲を確認します。仕組みの違いは、バックアップと同期の違いとは？大切なデータを守る保存と復元の基本で整理できます。
フォルダーをバックアップするなら、履歴に必要な.gitも対象か確認します。別の場所へ復元して、メモと履歴を読めるか確かめます。秘密情報を含む管理対象外の資料は、保存先の保護方法も考えます。
迷ったら「いつ、なぜ変えたかを知りたいファイル」を一つ選びます。最新ファイルの端末間共有や写真の検索が目的なら、それに合う道具を選びます。すべての保存をGitへ置き換える必要はありません。
まとめ
Gitは、変更する、差分を見る、内容を選ぶ、コミットする、という流れで使います。三つの場所を分けて考えると、add後の再編集や、二種類のdiffの違いを追いやすくなります。記録には変更が分かる短い説明を残してください。
別案にはブランチを使い、採用時は取り込み先でマージします。競合では変更の意図を確認し、取り消し前には失う内容を読みます。秘密情報の除外とバックアップも最初から用意します。
まずは空の練習用フォルダーにmemo.mdを作り、最初のコミットを残してみてください。一行追記してgit diffとgit diff --stagedを順に見れば、記録までの違いを確かめられます。
よくある質問
Gitを使うにはGitHubのアカウントが必要ですか？
Gitは手元のパソコンだけで履歴を記録できるため、アカウントは必要ありません。GitHubなどのホスティングサービスは、履歴を別の場所に置いたり、ほかの人と共有したりするときに利用します。
ファイルを保存すれば自動でコミットされますか？
エディターで保存しただけでは、Gitの履歴には記録されません。記録する内容をgit addで選び、git commitで区切りと説明を残します。
.gitignoreに書けば、すでに入れた秘密情報も消えますか？
すでに追跡しているファイルや過去のコミットには効きません。秘密情報を外部へ送ってしまった場合は、ファイルの削除だけで済ませず、その鍵やトークンの無効化・再発行を優先してください。
一人で使う場合もブランチは必要ですか？
小さな修正だけなら、最初は一本のブランチでもかまいません。文章の構成変更や設定の試行など、採用するか決める前に別案を試したいときに役立ちます。
Gitがあればバックアップは不要ですか？
同じパソコンにしか履歴がなければ、故障や紛失でファイルと履歴を同時に失う可能性があります。未コミットの内容や管理対象外のファイルもあるため、別の保存先へのバックアップを用意します。
コメント
まだコメントはありません。最初の感想をどうぞ。