ホームへ

Github-Flowを理解しながら、Gitの基本コマンドを復習する

1. なんとなくGit

個人で開発をしていても、git cloneでローカルにリポジトリを移植したり、ブログを書いてgit pushでリモートに上げたりするので、gitに触れる機会はある。 でも、自分はgitがどういうところに効くかはちゃんと分かっていないと思う。 というのも、自分の個人開発の範疇ではgitでバージョン管理をする必要性をほとんど感じなかったからだ。 (このことからして個人開発のレベルの低さがうかがえる)

確かにgit addとかgit commitを叩いて、結果的にバージョン管理みたいなことをしていることにはなっている。 でも、バージョン管理をする必要があったからしていたわけではなく、いつのまにかやっていたという感じである。 なので、あとでコミット時の変更点を見直して、コードを細かく吟味して…などということもほとんどしていない。

結局は、これまで書いたコードは自分しか使わないものだったから、コードの履歴を記録する必要もそれほどなかったし、コードの品質を保つ責任もそれほどなかったということに尽きるのだろう。 (あとであのときのコードに戻したかった…と後悔したことはある)

しかし、仕事でコードを書くとなると、そういうわけにはいかない。 自分のコードをきっちりと管理していかなければならないし、さらにチーム全体としてコードを管理していかなければならない。 そこでバージョン管理が必要になってくるわけである。

最近は、ほとんどの開発チームでgitでコードの管理を行っていると思う(多分)。 なので、どこで開発するにしても、最低でもgitの基本的なコマンドの意味は理解しておかなければならないだろう。

Gitを使ったワークフローは各チームによって違うと思うが、Github-Flowというものが広く受け入れられているらしい。 ということで、今回はGithub-Flowを理解しながら、各コマンドの意味を復習していきたい。

2. Github-Flowに沿った開発フローの例

Github-Flowは以下の6つのルールに基づいている。

  1. masterブランチは常にデプロイ可能である
  2. 作業用ブランチをmasterから作成する(例:new-oauth2-scopes)
  3. 作業用ブランチを定期的にプッシュする
  4. プルリクエストを活用する
  5. プルリクエストが承認されたらmasterへマージする
  6. masterへのマージが完了したら直ちにデプロイを行う

上のルールに基づいた開発手順は具体的にどのようなものになるだろうか。

1. 開発作業を行う

さあ開発を始めよう!
まずは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

2. プルリクエストを行う

ワチャワチャと作業し、masterブランチにマージしてもよい状態だと思ったら、プルリクエストを行う(ルール4)。プルリクエストとは、コメントと合わせて先ほどのコミットをコード管理者やチームに周知し、それを吟味した後にmasterブランチにマージできる機能のこと。 Github上でコメントを入力し、プルリクエストを出す。

Github上の画面

コード管理者は内容を確認した後、オーケーなら別ブランチで行ったコミットをmasterブランチへマージすることを承認する。(ルール5)

Github上の画面

また、category-list-in-sidebarは不要なので、削除しておく。

Github上の画面

コード管理者がリモートでマージしたmasterブランチの履歴は、ローカルのmasterブランチにまだ反映されていない。

ということで、pullでローカルに持ってくる。

git pull origin master

3. デプロイする

各々所定の方法でデプロイする(ルール6)。 また以上の流れの中で、masterブランチはすぐにデプロイできる状態のトピックブランチしかマージしていないので、常にデプロイ可能な状態が保たれている(ルール1)。

終わりに

このようにGithub-Flowは割とシンプルだ。 復習したコマンドも基本的なものばかりだった。 これからもう少しGitについて掘り下げていきたいと思う。

参考

2018/06/29 21:40:14に更新

カプセルで書く技術ログ
Capsule-Man on Github