複数メンバーでの開発は、コードの更新タイミングなどで様々なトラブルが発生しますし、完全な自動化はできません。慣れるまでは失敗はつきものですし、面倒に感じる部分もありますが、避けて通ることはできません。基本的な流れを覚えて、失敗しながら使い始めてみましょう。
利用するもの
基本的には、GitHubのリポジトリーを操作する公式アプリのGitHub Desktop(
)を利用します。
最初のプロジェクトをクローンする段階で、インターネット上の GitHub ページを利用します。
Gitはどうしてややこしいのか
「状態の異なるバージョンのファイルががあちこちにあるから」
図1は、GitHubで開発する時のリポジトリーの様子です。
図1 GitHubのリポジトリー
(パソコンのイラスト：かわいいフリー素材集 いらすとやより)
②フォークされたリポジトリー
オリジナルリポジトリーをコピーしたリポジトリーです。あるリポジトリーを、自分のアカウントのGitHubにコピーすることをフォーク(Fork)といいます。フォークしたリポジトリーは、各ユーザーのアカウントのGitHubに複製されたものなので、自由に内容を変更することができます。
プルリクエスト(Pull Request)をすることで、このリポジトリーで行った開発内容を、オリジナルリポジトリーに反映する提案が行えます。
③ローカルのリポジトリー
開発をGitHub上で行うのは不便なので、手元のPCにリポジトリーをダウンロードして操作します。GitHubから手元のPCにリポジトリーをダウンロードすることをクローン(Clone)といいます。
ローカルで変更を加えたら、コミット(Commit)をして、ローカルPCのリポジトリーを更新します。その上で、プッシュ(Push)、GitHub Desktopではシンクロ(Sync)操作をすることで、フォークされたリポジトリーにその変更内容がアップロードされます。
リポジトリーのまとめ
リポジトリーは、オリジナルのもの、各ユーザーのGitHubアカウントにフォークされたもの、ローカルPCにクローンされたものがあります。それぞれが個別に存在するので、混乱のもとになりやすいです。自分が今操作しているリポジトリーがどれなのかを考えながら操作しましょう。
リポジトリーが密接に同期されないことは混乱の元なのですが、そのメリットは絶大です。管理者でなければ、オリジナルのリポジトリーを変更することはできません。フォークしたものは失敗を恐れずに自由に変更してよいということです。失敗したら、自分のリポジトリーを削除して、オリジナルからフォークをし直せばやり直せるのです。この気軽さが Git の素晴らしさです。
リポジトリーのフォーク
みんなで開発する手始めに、オリジナルのリポジトリーを自分のアカウントにフォークしましょう。
- http://github.com を新しいタブで開いて、自分のアカウントでログインする
- ログインが完了したWebブラウザーで新しいタブを開いて、開発に参加したいアカウントのリポジトリーを開く
- 右上の方にある [Fork] ボタンを押す
フォークが完了したら、リポジトリーページの左上を確認してください。[自分のアカウント / リポジトリー名]となっています。その下に小さい文字で[forked from]とあり、続けてオリジナルのリポジトリーへのリンクが記載されています。
自分のアカウントにフォークしたリポジトリーができました。これをローカルPCにクローンして開発をしていきます。
フォークしたリポジトリーをクローンする
手元のPCで開発できるように、フォークしたリポジトリーをクローンします。
- GitHub Desktop()を起動
- ログインしていなければ、ログインする(右上の歯車アイコンをクリックして、[Options...]を選択。Accounts にアカウントが表示されていなければ、アカウント名とパスワードを入力してログインする)
- 左上の[+]をクリック > [Clone]をクリック > [Filter repositories]欄に、クローンしたいリポジトリー名を入力 > 表示されるリポジトリーを選択 > [Clone <プロジェクト名>をクリック
- 作業したい場所を指定する。特別なことがなければ、そのままの場所で[OK]でよい
以上で、手元のPCにリポジトリーがダウンロードされました。これで開発を行います。
開発作業
開発の流れを体験してみます。README.md ファイルに、自分の学籍番号と名前を追加する作業をしてみます。
ブランチ(Branch)とは
Gitなどのバージョン管理システムは、様々な状態のリポジトリーを扱うためのブランチ(Branch)という機能を持っています。詳しくは専門書やインターネット上の記事に譲りまして、ここでは基本的な方針を述べます。
- master ブランチは、常に動作する状態を維持する
- 開発は、一言で書き表せる程度の目標に分割して、そのためのブランチを作成して、そこで行う
- 開発が完了したら、オリジナルリポジトリーの master ブランチ(dev ブランチなどの他のブランチにプルリクエストするようなルールがあればそれに従う)に、プルリクエストを発行する
- プルリクエストは、完成しない状態で送ってもよい。開発者とディスカッションをしながら機能の完成をしていくことができる
- 機能の実装が完了して、プルリクエストがオリジナルに組み込まれた開発用のブランチは、そのまま放置でよい
master ブランチは、いつでもそこから別の開発が始められるように、バグが無い状態を保ちます。そのためには、 master ブランチ上で開発することは得策ではありません。開発用のブランチを作成して、そこで開発をすることで、 master ブランチは常に動作する状態を保てます。
ブランチを作成する
ブランチは、 GitHub Desktop で簡単に作成できます。それでは名前を追加するためのブランチということで[add-name]というブランチを作成します。
- GitHub Desktopの[Create new branch]ボタンを押す
- Name欄に[add-name]と入力して、[Create new branch]を押す
- ブランチ名が[add-name]に切り替わっていればOK
これで作業用フォルダーの中身が add-name ブランチに切り替わりました。
プロジェクトを変更する
開発用のブランチ[add-name]に切り替わりましたので、作業を行います。
- GitHub Desktop で、作業したいリポジトリーをクリックして選択
- 右上の[Atom]ボタンを押す(Atom以外のエディターを利用する場合は、クローンしたフォルダーの README.md をファイルから開く)
- 適当な場所に、学籍番号と氏名を入力
# yoketoru-unity-2016 2016年度版よけとるUnity for Unity5.5 # メンバーリスト - 00 たなかゆう
- 書き込みが終わったら、上書き保存する
以上でこの作業は完了です。次の手順に進みます。
コミット(Commit)とプッシュ(Push/Publish/Sync)
ファイルなどを変更したら、コミットをしてリポジトリーに変更内容を記録します。
- GitHub Desktop に切り替える
- (1)[Changes]を押す > (2)[Summary]欄に変更内容を書く(「学籍番号と名前を追加」など) > (3)[Commit to add-name]を押す > (4)[Publish]を押す(2回目以降は[Sync])
以上で、ローカルPCのリポジトリーに変更が記録され、その内容がフォークしたリポジトリーに反映されます。ここまでをワンセットで操作するとよいでしょう。
コミットをすると、その後、いつでもその状態に戻すことができます。コミットは小まめに行うようにしましょう。
ブランチの動作を確認する
コミットが完了したら、ブランチを切り替えることができます。 master ブランチに切り替えて、 README.md がどうなるか確認してみましょう。
- GitHub Desktop の [add-name]の部分をクリックして、[Default branch]の[master]に切り替える
- Atom エディターなどで、 README.md を確認する
以下のように、先ほどの変更が消えています。
# yoketoru-unity-2016 2016年度版よけとるUnity for Unity5.5 # メンバーリスト
同様の操作で add-name ブランチに戻してから README.md を確認してください。学籍番号と名前が復活します。ブランチごとに、違う状態が保持されているのです。
ブランチの下に表示される[Other branches]欄には、オリジナルのリポジトリーが表示されています。これを選べば、オリジナルの状態を参照することもできます。
コミットしていない変更があるとブランチは切り替えられません。ブランチを切り替える前にはコミットするようにしてください。
プルリクエスト(Pull Request)
変更が完了したら、オリジナルのリポジトリーに反映してもらうためにプルリクエストをします。
- GitHub Desktop の右上の[Pull request]を押す
- 必要であればタイトルを変更。Descriptionに簡単な修正内容を記載。テストや確認点があれば追記して、[Send pull request]を押す
完了したら、[Pull request created]と表示されます。その下の[View it on GitHub]をクリックすると、Webブラウザーが開いて、オリジナルリポジトリーに送られたプルリクエストを見ることができます。
このページで管理者と相談をしたり、駄目な場所があれば指摘されるので、それを持ち帰って改変します。
変更した内容をコミットしてSyncすると、プルリクエストにも自動的に反映します。一度プルリクエストを発行したら、それ以降は、普通に開発をして、コミットしてSyncして開発を進めればよいのです。
完了
管理者がプルリクエストをオリジナルのリポジトリーにマージ(Merge)して組み込まれれば作業完了です。これを繰り返していくことで、複数人数で、一つのプロジェクトを開発していくことができます。
次の開発をする
作業者が自分だけであればよいのですが、複数いる場合は、オリジナルのリポジトリーには他の人の変更も加わっていきます。その変更をローカルのリポジトリーに反映させる方法です。
- ローカルブランチを[Default branch]の[master]に切り替える
- [Compere]をクリックして、[Other branches]のオリジナルリポジトリーを選択
- [Update from <オリジナルのアカウント>/master]をクリック
以上で、オリジナルのリポジトリーの master ブランチの状態を、ローカルリポジトリーの master に反映させました。 README.md を見れば、自分が行っていない変更があれば、それが加わっていることが確認できます。
あとは、また開発用のブランチを新しく作成して、そこで開発→コミット→Sync→プルリクエスト のサイクルで開発してください。
まとめ
以上で、開発者として開発に参加する流れは最低限押さえました。簡単なプロジェクトで作成をしてみましょう。
管理者を引き受ける場合は、ここでやったものの他に、プルリクエストの受け入れと、別々の人たちが同じ場所を変更した時に発生する衝突＝コンフリクト(Conflict)の解決が必要になりますが、それはまた別の機会に。
以下、開発時のTipsをおさらいしておきます。
- オリジナルのリポジトリーから、自分のアカウントにリポジトリーをフォークして開発を開始
- 自分のアカウントから、開発するPC上にリポジトリをクローンする
- master ブランチ上では直接開発しない
- 開発時には、一言で表せる程度の規模の目標を立てて、ブランチを作成
- コミットとSyncは小まめに
- プルリクエストは早めに行ってよい
- 完了したら、オリジナルリポジトリーの管理者によって、プルリクエストがオリジナルリポジトリーにマージされる
- 最新状態は、 Compare からオリジナルのリポジトリーを選んで、 Update する
困った時は
手元のリポジトリーを削除して、フォークやクローンし直そう。
