GitHubを使ったチーム開発

2020年10月19日

1つのプロジェクトでunityの共同開発を進める方法について基本の手順を考えます

目次

決め事

コーディングに入る前に、メンバー内で十分な意識合わせをしましょう

意識づけ

スケッチを含め、アイデア、企画、設計の途中の情報は記録するようにします。

プロジェクトの管理スタイル

管理の方法をメンバーで統一しておく事は大切です
メンバーみんなが扱えるように基本的な要素は、各自学習しておくようにしましょう。
ここでは、比較的わかりやすく、手順が簡略化されているものを参考で紹介しています

GitHubFlow

開発スタイルは様々考案されていますが、GitHub考案のGitHubFlowという開発フローを採用するのがわかりやすいアプローチになるでしょう。

Unityプロジェクト特有のコツ

  • メインとなるSceneを更新するメンバーは1人にしましょう。(Sceneを更新する作業を同時に複数人で行うとどのSceneを採用するのか?難しい調整が必要になるため)
  • Prefabは、各自で作成し、他のメンバーとの依存性がないようにしましょう。(他のメンバーの更新によって動作しない、競合が発生するので)
  • 未使用のアセット、プラグイン、重複したライブラリをプロジェクトに残さないでください
  • 各自、担当(役割)を決めて、同時に同じファイルを更新しないようにしましょう
  • これらは、1つの作文用紙で2人交互に書いたり消したりする様子を思い浮かべると、あとでどうにかするにしても大変であることから、避ける方が賢明です。
  • ファイルの追加、削除、移動は、UnityのProjectビューで実行しましょう。エクスプローラで行うと、メタファイル(ファイルの情報についてUnity独自て記載されたファイル)との整合性が取れなくなります。(.metaファイルという隠し属性のファイル)
  • デフォルトのmasterブランチは、常に動作可能なものにしておきましょう。ボーン(骨)となるところです。最悪、この状態まで戻すと稼働できるようにしておくようにしましょう。
  • Gitの仕様として、フォルダだけ作成しファイルをその中に作成していないとこのフォルダは管理対象になりません。つまり、Github(クラウド)にも保存されませんただし、メタファイル(ファイル情報を記載したファイル)は対象になります。次のキャプチャを参照してください。

ローカルフォルダ(Testフォルダを作成しただけでファイルは空)

GitHub(クラウド)リモートリポジトリ 。Testフォルダが見当たりませんが、meteファイルだけ存在します)

Testフォルダ内にCheck.csファイルを追加した

GitHub(クラウド)リモートリポジトリ 。Testフォルダがちゃんと作成されています。

準備作業

運用に入るために準備をしましょう
この準備は、一度だけ行えばいいです。また、インストール作業はプロジェクトごとには必要ないため、新しいプロジェクトの作成時はもっと簡単になります。

バージョンの統一(各自)

Unityのバージョンを統一しておきます。

GitHub(クラウド)のユーザー登録(各自)

GitHubにサインアップしておきます。

UnityHubのIDを確認します。以降、このIDは必要になります。

GitHub Desktopのインストール(各自)

ローカル(PC)でバージョン管理を進めていくためのツールになります。GitHubが提供しているので、親和性が非常に高いです。また、活発に開発を進められているため、おすすめです。Gitは、高機能な仕組み(様々な修正、調整ができる)があるのですが、あえてリスクの高い作業(処理)は封印されています。このため、作業ミスによるコードのクラッシュを防ぐことができるようになっています。本来、プログラマが短時間で効率良くコーディングができるためのツールのはずなので、クラッシュを修正する時間が必要になる事はチーム全体としても非効率です。また、学習コストが高くなり習得に時間がかかることや慣れている人でもミスをすることもあることから、コンソールベースのコマンド作業は排除してもいいと思います。このツールがメジャーになるのはもう少しかかるかもしれませんが、ビジュアルツールを使う人口が多くなるとこちらがメジャーになっていくことでしょう。

新規プロジェクトの作成(リーダー)

2020年10月1日から、GitHubでのデフォルトのブランチが[main]に変更されました。
これまで通りmasterを使うのかmainにするのかは決め事です

 GitHubの最高経営責任者(CEO)は、奴隷制度に関係する用語を不必要に使用するのを避けるために、「マスター」という用語を「メイン」などの中立的な用語に変更する取り組みを進めていることを明らかにした。

GitHubDesktopでリポジトリ の作成(リーダー)

Github(クラウド)の登録で、masterブランチをプロテクトに設定する(リーダー)

(有料機能)安全のためmasterブランチに直接コミットできないように保護します。
マージする場合は、プルリクエストで承認を必要とします

GitHub(クラウド)でチームメンバーをCollaboratorに登録(リーダー)

Slack連携をする場合(リーダー)

  • github連携(アプリ)のインストール
  • チーム開発チャネルを作成
  • /github subscribe owner/repo で、購読追加

コーディング作業中

自分の環境でコーディングするため、ブランチを作成(各自)

コード作成作業(各自)

各自、コード作成、コミットを繰り返し、作業を進めていきます。

コミットの書き方

次のようなプレフィックスをコミットの最初につけるとわかりやすくなります。

プレフィックス 機能新規機能追加詳細
add新規ファイルの追加
update修正仕様変更、バグ修正以外の機能追加、修正
fix修正バグの修正
remove削除削除、取り消し

コードの更新箇所はGitを見ればわかるため、Score変数を宣言したなど、コードの説明を書く必要はありません。何をしたのか?なぜそうしたのかを書きます

サンプル)

[update] スコアの表示機能を追加した
詳細欄には、プレイヤーのスコアを反映させた等

[fix] スコアが増えない不具合を修正した
詳細欄には、当たり判定が検出されていなかったため等

issueに対して修正した場合(例えば、#1のチケット番号を修正した場合)
[fix] #1 スコアが増えない不具合を修正した
詳細欄には、当たり判定が検出されていなかったため等

GitHub(クラウド)のPushしても良いタイミングで、Push originを実行します。
これで、ローカルの環境からクラウドへアップロードされます。

自分の担当が一通り完成し、Github(クラウド)のマスターへ取り込んでもらいたいとき

プルリクエストという承認依頼を作成します(各自)

GitHubDesktopでプルリクエスト(PullRequest)を作成します

プルリクエスト内容の入力(各自)

ブラウザがオープンし、Github(クラウド)の画面が表示されるので、タイトル、詳細、レビューアー(プルリクエストを承認してもらうメンバー。複数でもOK)を追加して、作成ボタンをクリックします。

作成ボタンをクリックした後の画面(各自)

(参考)GithubDesktopでのプルリクエストの確認方法

提出されたプルリクエストを確認し、承認、非承認の処理をします。

プルリクエストは、Github(クラウド)のメニューで確認できます。問題なければマージします(リーダー、サブリーダー)

Pull requestsタブをクリックすると、確認、承認画面に切り替わります。問題がある場合、修正を依頼します

Pull requestタブのカウンタが表示されているのを確認します

承認依頼のあったブランチの最新をPullして動作をPCで確認します。

確認後、Add your reviewでレビューをします

レビューの結果を選択します

Comment(コメント)
明示的な承認をせずに、一般的なフィードバックを送信します。
Approve(承認する)
フィードバックを送信し、これらの変更をマージすることを承認します。
Request changes(変更のリクエスト)
マージする前に対処しなければならないフィードバックを提出してください。

Submit reviewをクリックすると、画面が戻りますので、Merge pull requestを選択します。

再度確認画面が表示されるので、問題がなければ、Confirm mergeをクリックします

ブランチを削除して、終わりにします

ローカルのブランチを削除します(制作者)

masterにマージされていないのに削除しないように最新の注意を払いましょう
また、GitHub(クラウド)も念のために確認し、削除されていない場合は削除しておきましょう

以降、この一連の作業を繰り返します。

このスキームでは、タスクが完了したら、プルリクエストを送って、masterにマージ、その後、ブランチは削除することを繰り返すことをチームとして徹底することが重要です。masterが破壊されるのは防いでいますが、手順を抜くと後の処理が面倒になります。

参考

GitHubマニュアル(ドキュメント)

プルリクエスト(Pull Request)について

コミットが複数ある場合、1つにまとめる方法

コミットの履歴を綺麗にできます。プルリクエストに至るまでの個人メモ的な開発中のコミットメッセージがある場合、隠すことができます

マージはして欲しくないが、これでいいのかな?と確認して欲しい時。(有料バージョン:Pro,Team〜)

マージをしないプルリクエストを作成してマージ時の状態で確認だけして欲しいとき。コメントを欲しいとき。

プルリクエスト画面

GitHubDesktopでデフォルトのブランチ名を変更する方法(Version 2.5.6)

プロテクトされたブランチ(master)に単にpushした場合のエラー画面

GitHubDesktopで変更されたmasterを自分のブランチに取り込む手順(各自)

Updateするコミットがない(masterとの差異がない)場合、このメニューはグレイアウトになり選択でできません。

競合が発生した場合

masterの取り込みをしばらく実行していない場合(masterのマージが進んでいる)、自分のブランチの変更箇所とmasterの変更箇所が競合(同じファイルを変更している)する場合があります。慌てず、このページ下部の対応事例を参考に処理しましょう。

GitHubDesktopの開発コミット(実際の開発public)リポジトリになります。

素晴らしいアイディアやコードが形になる準備ができたらすぐに、コラボレーターとの会話をスタートするPull Requestを開ける機能

gitにおけるコミットログの書き方

gitにおけるコミットログ/メッセージ例文集100

GitHubDesktopでmasterブランチを自分のブランチに取り込む方法

チーム開発のコツ

役割の割り振り

Q. どうやってタスクを分業しているのか
  • 誰がどう実装しても同じような実装になる部分
    • 構造が決まっている構造体やクラスの定義
    • 設計済みのインタフェース定義
  • どんな実装であれ要件を満たすなら問題ない部分
    • プレイヤーの移動処理
    • オブジェクトの生成処理

こういう部分からまず分業して実装をしていきます。
逆に次のような部分は分業せず、誰か1人に任せたほうがいいです。

  • 多くのクラスを用いて処理を行う部分
    • ゲーム終了時に点数計算して表示する部分
    • シーンの初期化と終了部分

開発のコツ

バグが少ない安定したゲームを構築するためのベストプラクティス
プロジェクトが大規模化してもコードを整然とした状態に保つコツ

Unity TechnologiesのGitHubリポジトリ

競合(コンフリクト)対応事例

masterを自分のブランチに取り込まずコーディングを進めていたが、そのままプルリクエストをしたことで、masterとの競合(相違)が発生した時の処理

GitHub側で処理が完結できる場合もありますが、競合箇所が多いとそのような自動的に競合を修復することができない時があります。
その場合、ローカル側でmasterを取り込み、競合を処理してから再度Push,プルリクエストします

(ローカル)GitHub Desktopで処理

BranchメニューのUpdate from mainで、masterブランチを自分のブランチに取り込んだ場合、masterブランチの更新によっては、そのまま取り込めない状況が出てきます。その場合、競合が検出されますが、これを解決する手段がGUIで用意されていますので、活用します。

どちらかのファイルを選択することで対応ができる場合

同じファイルが存在しています。このままでは運用できないので使用したい方のファイルを選択する必要があります。

同一ファイルの内容を変更している場合

デフォルトのエディタ(Visual Studio Code)で対応します。

エディターで競合を処理

エディターで競合処理機能が備わっています。
選択したい方を考え、次のいずれかをクリックします。

  • 現在の変更を取り込む
  • 入力側(この場合、main)の変更を取り込む
  • 両方の変更を取り込む
  • 変更の比較(下図参照)

以上処理より、競合が全て解決されれば、PushやPullRequestが可能になります

変更の比較画面

2020年10月19日C#,Unity,バージョン管理

Posted by hidepon