##想定する読者層
- プログラミング初学者の方
- 業務でGitを使い始めた方
- Gitについてまだ理解が曖昧、上手く使えていないという方
かく言う自分も自己学習なり業務なりである程度Gitを触ってきて、ようやく『こういうことか』みたいなのが掴めてきたので、備忘録も兼ねて初学者の方の助けになるような記事を投稿してみたいと思います。
ただ入門って言うよりは、ある程度触った方向けのものになるかも。
全4回予定です。
##Gitを理解するには？
個人的にGitを触り始めた頃に分かりにくい、とっつにくいと感じていた点や理由を列挙してみると、
- Gitって何の為にあるのか分かりにくい
- やれること(コマンドとか)が多すぎて覚えられない
- 競合ってなんだよ(怒)
などなど……
実際、色々調べたりしていく内になんとか上記の疑問を解決出来たのですが、Gitは本来バージョン管理という重要ではありながら単純な作業を行う為のものなのに、その多機能性から全容が把握しにくいといった印象は確かに今でも感じます。
そこで至った結論が、Gitを理解するには**『環境を段階的に変化させること』**が肝要なのではないかと。
→ これはつまり、「使うコマンドを限定して覚えていく」というイメージです。
今回自分が考えた環境の遷移は以下の通り。
- まずはローカルリポジトリかつmasterブランチのみの作業(add, commit, status)
- masterのみで作業しつつ、リモートリポジトリに公開する作業(push, revert, reset)
- masterのみで作業しつつ、リモートリポジトリで共有しながらの作業(pull, stash, diff, log)
- ブランチを切りながら、リモートリポジトリで共有しながらの作業(checkout, branch, fetch, merge)
4番の環境が所謂チーム開発の環境だと思うので、『業務で使える』という観点でのゴールは此処になると思われます。
今回は1番の簡単な個人開発的環境を想定して3つのコマンドについてみていきます。
##Gitの基本
まずは一応概要から。
Gitとはバージョン管理システムである。
プログラム(というかソースコード)がRPGだとしたら、Gitは内容をセーブするためのシステム(と自分は捉えています)。
そんでもって分散型管理システムでもあるので、自分トコのセーブデータと、他の人のセーブデータを別々で管理した後、その結果を合体させることが出来ちゃったりする(此処らへんが最初はイメージしづらいかも)
##add, commit, status
個人的にGitの基本サイクルだと考えているのが、add→commit→pushの流れ。
pushは取り敢えず置いといて、addとcommitについて。
####commit - 変更をコミットする。
Gitの要となる機能であり、上述の『内容をセーブする』に近い動作。
これを繰り返すことでコミットグラフなるものが蓄積されていき、ディレクトリ内の変更が記録されていく。
各コミットにはコミットメッセージというものが存在しており、そのコミット内で"どういう作業を行った"とかを人に読める形で記録する。
個人開発は勿論、プロジェクトによってはフォーマットなども決められてたりする。
短いコミットメッセージの場合は、-mオプションを用いて
commit -m "(コミットメッセージ)"
という形でコミットメッセージを書くと楽。
####add - コミットするための変更をステージ(追加)する。
ぶっちゃけ最初はそこまで意識せず、セーブしたいなと思ったら
git add -A
commit -m "更新"
としてしまえば良いが、(個人開発はともかく)業務ではそうもいかないのでcommitとの違いを正しく把握しておく。
コミットというのはセーブデータを作る作業ですが、常にディレクトリ全体が記録される訳ではなくステージングという作業を行ったファイルの変更のみが変更を記録される。それを行うのがaddコマンド。
addの働きを理解するには以下のような状況を想定するのが丁度良いのかなと思います。
#####例
まずファイルA,B,Cがディレクトリ内に三つ存在し、それぞれに何かしらの変更を行ったとする。
でもファイルAの内容としては何かしらの機能追加、Bは不具合修正、Cは単なるリファクタリング、とかだった場合に3つのファイル全てをまとめてコミットするのはあまりよろしくない。
→これは前述の通りコミットにはコミットメッセージが存在していて、コミット毎に「何を行ったか」を明確にする必要があるから。
なのでこういったケースの時は
git add ファイルA
git commit -m "●●機能追加"
git add ファイルB
git commit -m "不具合修正"
.
.
みたいに、内容ごとにステージングとコミットを切り分けて記録していくのがベター。
こうすることで後からコミットグラフを見返したりチェックアウトした時に、Aのみに変更を行った状態・A,Bに変更を行った状態・A,B,C全てに変更を行った状態というのを別々に再現出来る。
バージョン管理という観点でも『特定の箇所に』『特定の変更を』行ったという情報でコミットが切り分けられている方が見やすく不具合調査の際などにも役立つので、一度に多くの変更を行ってしまったという場合でも、addコマンドを上手く使ってコミットを細かく切り分けていくことは重要になってきます。
→ こういうのが『コミットの粒度』って言葉で表現されることが多いので、意識しておくとより良いかもしれません。
####status - 現在のワーキングツリーの状態を確認する。
最後に、個人的に基本サイクルに加えて良いと思ってるし実際一番よく叩く気がするコマンド。
変更を加えたけれどまだステージング(add)してないファイルや、ステージングしたけどコミットしてないファイルなどを一覧で確認出来るコマンドです。
その他にもstatus(状態)の名の通り色々な情報が書いてあるので
心配性な人はgit statusを叩きまくる癖をつければ良いと思います。
##まとめ
これだけ？って思うかもしれませんが、まずはこの3つを覚えて、ローカルでかつmasterのみでの作業が問題なく出来るようになるのが大切な1ステップ目だと思います！
特にコミットを細かく分割することやメッセージをしっかり書くこと、というのは業務でも大切なことなので個人開発でも意識して行うのが重要です。
次回は2番の環境に移行して、リモートリポジトリを活用する段階に入っていく予定。