個人で開発をしていても、git clone
でローカルにリポジトリを移植したり、ブログを書いてgit push
でリモートに上げたりするので、gitに触れる機会はある。
でも、自分はgitがどういうところに効くかはちゃんと分かっていないと思う。
というのも、自分の個人開発の範疇ではgitでバージョン管理をする必要性をほとんど感じなかったからだ。
(このことからして個人開発のレベルの低さがうかがえる)
確かにgit add
とかgit commit
を叩いて、結果的にバージョン管理みたいなことをしていることにはなっている。
でも、バージョン管理をする必要があったからしていたわけではなく、いつのまにかやっていたという感じである。
なので、あとでコミット時の変更点を見直して、コードを細かく吟味して…などということもほとんどしていない。
結局は、これまで書いたコードは自分しか使わないものだったから、コードの履歴を記録する必要もそれほどなかったし、コードの品質を保つ責任もそれほどなかったということに尽きるのだろう。 (あとであのときのコードに戻したかった…と後悔したことはある)
しかし、仕事でコードを書くとなると、そういうわけにはいかない。 自分のコードをきっちりと管理していかなければならないし、さらにチーム全体としてコードを管理していかなければならない。 そこでバージョン管理が必要になってくるわけである。
最近は、ほとんどの開発チームでgitでコードの管理を行っていると思う(多分)。 なので、どこで開発するにしても、最低でもgitの基本的なコマンドの意味は理解しておかなければならないだろう。
Gitを使ったワークフローは各チームによって違うと思うが、Github-Flowというものが広く受け入れられているらしい。 ということで、今回はGithub-Flowを理解しながら、各コマンドの意味を復習していきたい。
Github-Flowは以下の6つのルールに基づいている。
上のルールに基づいた開発手順は具体的にどのようなものになるだろうか。
さあ開発を始めよう!
まずはmasterブランチから作業用ブランチを作成する(ルール2)。
このとき、ブランチにはどのような作業をしているかがすぐに分かるような名前をつける。
git checkout -b category-list-in-sidebar
現在のブランチを確認すると、category-list-in-sidebarブランチに変更されている。
git status
// On branch category-list-in-sidebar
// no changes added to commit (use "git add" and/or "git commit -a")
次に作業内容は定期的に作成したローカルのブランチにコミットする(ルール3)。
git add index.js
git commit -m "first commit"
リモートサーバー上の同じ名前のブランチへのpush
も定期的に行う(ルール3)。
git push origin category-list-in-sidebar
ワチャワチャと作業し、masterブランチにマージしてもよい状態だと思ったら、プルリクエストを行う(ルール4)。プルリクエストとは、コメントと合わせて先ほどのコミットをコード管理者やチームに周知し、それを吟味した後にmasterブランチにマージできる機能のこと。 Github上でコメントを入力し、プルリクエストを出す。
コード管理者は内容を確認した後、オーケーなら別ブランチで行ったコミットをmasterブランチへマージすることを承認する。(ルール5)
また、category-list-in-sidebarは不要なので、削除しておく。
コード管理者がリモートでマージしたmasterブランチの履歴は、ローカルのmasterブランチにまだ反映されていない。
ということで、pull
でローカルに持ってくる。
git pull origin master
各々所定の方法でデプロイする(ルール6)。 また以上の流れの中で、masterブランチはすぐにデプロイできる状態のトピックブランチしかマージしていないので、常にデプロイ可能な状態が保たれている(ルール1)。
このようにGithub-Flowは割とシンプルだ。 復習したコマンドも基本的なものばかりだった。 これからもう少しGitについて掘り下げていきたいと思う。