今回でGit関連の最終回です。

前回までで、よく使う操作について順に見てきました。
今回は実際にチームで使う場面を想定して、ワークフローについて紹介します。

よりシンプルで分かりやすいGithub Flowを例に進めていきます。

スポンサードサーチ

Github Flow

Github Flowにおいて、定義されているルールは以下の通りです。

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

なんですが、イメージしやすいようにもう少し簡素化すると、

１．masterブランチは常にデプロイ可能な状態を保つ　（これは不動）
２．ブランチ上で作業し、その生存期間はできる限り短くする
３．変更したら、すぐにプルリクエストを作り、フィードバックやサインオフを求める
４．マージしたらすぐにデプロイ

こういったイメージでOKだと思います。

ちなみに、デプロイはコードをサーバーに置くことです。

 

具体的なワークフローとして、タスクを分解して説明すると以下の形です。

1.何をすべきかを決める
2.masterブランチから説明的な名前のブランチを作成する
3.ブランチをgit pushして、コードをチームメンバーにシェア
4.Pull Requestを作成
5.コードを書くorコードの修正（議論はここでする）
6.テスト
7.マスターブランチを、デプロイするPull requestブランチにマージする
8.テスト環境にデプロイ
9.テスト
10.本番環境にデプロイ
11.様子を見る
12.Pull requestブランチを、マスターブランチにマージする

一連の流れを試してみる

Github Flowを擬似的に体験してみます。

まずは、新規にリモートリポジトリを作成し、Cloud9でクローンします。

new projectからリポジトリを作成する際に、「Initialize this repository with a README」のチェックボックスに今回はチェックを入れておきます。

こちらにチェックを入れておくことで、githubのリポジトリとReadmeファイルを自動で設置してくれるので、すぐにクローンできます。

$ git clone 「githubからコピーしたURL」を貼り付け

lsコマンド確認すると、 learn-githubflowリポジトリが作成されたことが確認できました。

 

learn-githubflowリポジトリに移動して、新しく機能を作るためのブランチを用意しましょう。

$ git checkout -b feature-hellow

feature-hellowブランチを用意して、このブランチに移動してファイルを作成します。
ド定番のhellowを出力するファイルを置いておきます。

$ touch hellow.php

例えばこんな感じで用意します。

このファイルを
ステージ領域に上げて　　$ git add hellow.php
↓
差分の確認をして　　　　$ git diff HEAD
↓
意図した変更内容であれば、コミットします。　　$ git commit -m “add hellow.php”

次に、このローカルリポジトリ内のfeature-hellowブランチの内容をリモートリポジトリに送信します。

$ git push origin feature-hellow

ここまでで、ひとまず開発が完了したと想定して、ここからレビュワーとのコミュニケーションが始まります。
今回は自作自演です。

Github上でプルリクエストをおこない、マスターブランチへの変更したコードの取り込みの依頼をします。

New pull requestからプルリクを作成しますが、feature-helloブランチからmasterブランチへの向きになっていることを確認してください。

コメントを付けてリクエストを送信します。
受け取ったレビュワーが、例えば「日本語対応してください」とコメントを返したとして、受け取った開発者はコードを編集して再度コミットして、リモートリポジトリへプッシュします。

最終的に問題なければマージします。
レビュワーもしくはレビュワーの指示を受けて開発者がおこないます。
下の画像の、「Merge pull request」ボタンを押して、マージします。

コメントを付けて「Confime merge」ボタンを押せば完了です。
これで、feature-hellowブランチの変更内容がマスターブランチに取り込まれています。

一方でローカルリポジトリのマスターブランチは、最新のリモートリポジトリのマスターブランチの更新からおいてかれているので、プルコマンドで最新化します。

$ git pull　コマンドで取得します。

$ ls
でリモートリポジトリの状態と同期が取れたことが確認できます。

そして、更に開発を進めていくときは、マスターブランチから新たなブランチを切り出してと言った具合で、この一連の作業を繰り返していきます。

ご想像の通り、ブランチは放っておくとどんどん増えていくので、不要なものを削除することもできます。

例えばリモートの「feature-hellowブランチ」を削除するとしましょう。

$ git push –delete origin feature-hellow

もう一度一覧で確認すると

消えましたね。

次にローカルのブランチの削除をおこないます。

$ git branch –delete feature-hellow

$ git branchで確認すると、マスターブランチのみになっているのが確認できると思います。

これで同期が取れた状態になりました。

 

慣れてしまえば非常に便利にそして安全に使えるので、ソースコード管理に限らず、チームで仕事を進める方にはおすすめです。

Sharepointなんかでもファイルのバージョン管理はできますが、例えば、編集する対象のファイルを間違っていたりして、以前のバージョンに戻すなんてことが起きがちです。
戻してまた正しい場所で作業し直しになります。

仕事で無駄に時間がかかってしまう場面の多くは手戻りのため、ファイルのバージョン管理ができて切り戻せるだけでは不十分で、Github Flowのような運用方法と機能を含めて考えると、一番効率よく運用できると思います。

非エンジニアでも、共同で編集作業が発生する業務に携わっている人は使ってみる価値がありますよ。
エンジニアかどうかに関わらず使うツールを共通化できるのも、メリットが大きいです。