プログラミングに触れる人はかなり増えたと思う。
自分もその一人。
コードを書いて、試して、壊して、直して、また試す。
ツールや環境の進化もあり開発や学習のスピードは、確実に加速していると感じる。
一方で、会社の開発環境や運用ルールは、必ずしもこのスピード感を前提に整備されていない
という側面もある。
たとえば、社外SaaSの利用が制限されていて GitHub が使えないケース。
これは情報セキュリティの観点では、ごく普通に起こりうる制約だと思う。
それでも、開発する側の欲求は変わらない。
- 履歴を残したい
- 何をしたか確認したい
- やらかしたら戻したい
「じゃあ、GitHubが使えないときに Git 管理ってどうする？」
GitHub前提で覚えてきた Git の使い方を、一度分解して考え直すことになった。
結論から言うと、
GitHubが使えなくても、Git管理はできる。
Gitはそもそも、ローカルで完結できるツール。
Gitでやりたかったことはこの3つ
GitHubが使えない環境でも、やりたかったことはシンプルだった。
- 履歴を保存したい
- 履歴を確認したい
- 前のバージョンに戻したい
この3つができていれば、
Git管理としては十分成立する。
① 履歴を保存したいとき（変更を残したい）
ここでいう「保存」は、
ファイルの上書き保存ではなく 作業の節目を履歴として残す という意味。
自分が実際にやっているのは、この流れ。
git status
git add .
git commit -m "message"
実際に使ってみて感じたポイントは、
- commitは細かくていい
- 途中経過でも問題ない
- ローカル管理なので、誰にも迷惑がかからない
GitHub前提で覚えていると
「最初から綺麗なcommitを作らなきゃ」と思いがちだけど、
ローカル運用では あとで整えればいい と割り切れるのが楽だった。
② 履歴を確認したいとき（何をしたか知りたい）
まずはこれ。
git log --oneline
これで、
- いつ
- どんな変更を
- どんな単位で
やったかが一目で分かる。
作業中の差分確認には、
git diff
を使えば、「何が変わったか分からない」状態がかなり減る。
③ 前のバージョンに戻したいとき（やらかした時）
ローカルGit運用の一番の安心材料は、
自分しか触っていない範囲なら、比較的安全に巻き戻せること。
直前のcommitをなかったことにしたい（変更は残す）
git reset --soft HEAD~1
commitだけ消えて、変更内容は残るので、やり直しやすい。
commitも変更内容も全部戻したい（注意）
git reset --hard HEAD~1
※ これは commitだけでなく作業中の変更も消える。
※ ローカル運用前提でのみ使う操作。
自分は実行前に、必ず git status を見て
「本当に消していいか」を確認するようにしている。
過去の状態を一時的に見たいだけ
git checkout <commit-id>
これは「過去を見に行く」用途で使っている。
この操作をすると、いわゆる detached HEAD 状態になるらしいが、
見るだけであれば特に問題は感じなかった。
確認が終わったら、
git checkout main
で元に戻す。
迷子になったときの保険
git reflog
これは
「HEADがどこを辿ってきたか」を確認できるコマンド。
rebase や reset で不安になったときに、
「戻れる場所がある」と分かるだけで安心感がある。
補足①：コミットIDは「先頭の数桁」で指定できる
コミットIDは本来かなり長い文字列で、
一般的には40桁のSHA-1が多いらしい。
ただ、実際に使うときは、
git log --oneline
に表示されている 短いID をそのまま指定できた。
git checkout c1369a5
git reset --soft c1369a5
自分の環境では、これで問題なかった。
補足②：IDは何桁以上必要？
自分の環境では、
6桁くらいのIDで fatal エラーが出たことがあった。
調べた範囲では、
- コミットIDの省略は
「そのリポジトリ内で一意に特定できればOK」 - 固定の桁数ルールはない
- 被った場合にエラーになる
という挙動らしい。
実務的には、
まず短いIDを使う
エラーが出たら、先頭を1〜2文字足す
で困ることはなかった。
補足③：未pushの履歴をまとめたい（squash）
試行錯誤を重ねていると、
commit の数が増えてしまう場面がある。
ローカル運用では、
- 作業ログは細かく残したい
- でも、あとから見たときに分かりやすい単位にまとめたい
という気持ちになることが多かった。
そんなときに使ったのが squash。
git rebase -i HEAD~2
ここからは「ターミナルでテキスト編集」
このコマンドを実行すると、
ターミナル上でテキストエディタが開く。
追加のコマンドを打つわけではなく、
表示された内容を書き換える操作になる。
例：
pick AAAAAAA first
pick BBBBBBB second
これを、
pick AAAAAAA first
squash BBBBBBB second
に書き換える。
保存して閉じると、
次にコミットメッセージを1本にまとめる画面が出る。
エディタが出てきたとき（自分が一番詰まった）
自分の環境では、このとき
vim というエディタが起動していたようだった。
vim を使ったことがなかったため、
- どこに入力していいか分からない
- そもそも閉じ方が分からない
という状態になって、かなり戸惑った。
結果的に、最低限これだけ分かれば抜けられると分かった。
-
Esc：編集モードを抜ける -
:wq→ Enter：保存して終了
注意点（ローカル運用前提）
-
reset --hardは「ローカルで試して戻したいとき」に使う
（commit だけでなく作業中の変更も消えるので、実行前にgit statusを確認する） - rebase / squash は「自分の作業ログを整理するための操作」と割り切る
（履歴をきれいに“見せる”ためではなく、自分が分かりやすくするため） - checkoutで過去を見るのは「状態確認のための一時的な操作」に留める
まとめ
試行錯誤が増えても、制約の中で開発を回す方法はある。
GitHubが使えなくても、
- 履歴を保存する
- 履歴を確認する
- 戻せるようにする
この3つをローカルGitで押さえておくだけで、
「とりあえず詰まらない」状態にはできた。
squashも、
「ターミナルでテキストを書き換える操作」と分かれば、
意外と難しいものではなかった。
GitHubが使えないローカル環境でも、git があればちゃんと回せる。
gitって本当にすごい。