unityでのチーム開発におけるgitの使い方を学びます。

1. Git演習(2)

2. アジェンダ
前回の復習
チームでリポジトリを管理しよう
関連リンクの紹介

3. 用語の復習
リポジトリ:
コミット:
ブランチ:
プッシュ:

4. 用語の復習
リポジトリ: Git管理するフォルダ
コミット: ファイルをリポジトリに登録すること
ブランチ: バージョンの枝分かれ
プッシュ: オンライン(リモート)のリポジトリに
ローカルのバージョンをアップロード

5. 本日の目標
githubを使い、チームで作るゲームの
バージョン管理をできるようになろう

6. 本日の演習の流れ
1ページずつ、課題に取り組んでもらいます
全員が課題を完了するまで待ってから先に進めます！
わからないことがあった人は、すぐに誰かに聞きましょう！
(もちろん、僕に聞いてもokです)
早く終わった人は、まだ終わっていない人を
積極的にサポートしましょう！
積極的にコミュニケーションしましょう

7. 演習1. 新しいUnityリポジトリを作ろう
Sourcetreeのメニューから
「リポジトリを作成」
前回と同じ流れです
Unityプロジェクトを作り、そこにリポジトリを作る
.gitignoreを追加する
https://github.com/github/gitignore/blob/master/Unity.gitignore

8. 演習2. githubにプッシュしよう
複数人で管理するために、オンラインにプッシュ
githubでリポジトリを作り、urlを控えておく
Sourcetreeに戻り、設定→リモート→追加で
リポジトリのurlを登録(デフォルトリモートとして)
登録したら、上部メニューのプッシュで
リポジトリのデータをアップロードする
Githubに戻り、アップロードされていることを確認

9. 覚えていたかな？

10. チームでリポジトリを管理しよう

11. チーム開発の基本的な流れ
ブランチをフル活用してgithubで管理する
1.機能追加の前にブランチを切る
2.コミットを重ねて機能を追加する
3.追加した機能を確認し合う
4.masterブランチに統合(マージ)する
5.1-4を繰り返し、masterブランチを
常にバグ無く動く状態で更新し続ける
出典: サルでもわかるGit入門(https://backlog.com/ja/git-tutorial/)

12. はーい、二人組作ってー

13. 演習3. リポジトリにCollaboratorを招待しよう
一緒に開発を進める人を招待しよう
githubリポジトリでSettings→Collaboratorsに進む
ユーザー名を入力してAdd Collaboratorをクリック
相手にCollaboratorの申請メールが届くので、リンクをク
リックして承認してもらう
お互いのリポジトリで行おう

14. 演習4. 自分のリポジトリでブランチを切ろう
必ず最初にブランチを切ること！
SourceTree上でブランチ→新規ブランチを作成
ブランチ名のフォーマットは「user名/やること」
今回は計算のプログラムを書くので、
「user名/calculation」とする

15. 演習5. C#で計算するプログラムを書こう
自分のリポジトリに剰余計算を行うプログラムを用意
Unityでプログラムを生成し、その中に
「2つの値を受け取って剰余計算の結果を返すpublicなメソッド」を書
こう
メソッドを呼び出す処理は不要
Unityでオブジェクトにアタッチし、
エラーが起きないか確認しましょう
自力で書いてください(周りに聞かない、自分で調べる)

16. 演習6. プログラムをリモートにプッシュしよう
書いたプログラムをコミットし、プッシュする
Sourcetreeでコミット
Sourcetreeでプッシュ
githubでブランチを「user名/calculation」に変更し、
ファイルがプッシュされているか確認

17. 疲れてきた...?

18. 演習7. プルリクエストを作ろう
自分のブランチをマージしてよいかCollaboratorに
チェックしてもらうために、プルリクエストを作る
githubリポジトリでCodeタブのNew pull requestをクリック
base: masterのまま、compareに自分のブランチを設定
プルリクエストの名前は「何をやったか」わかりやすく書く
本文はより具体的に「何をどう変えたか」書く
書き終えたらCreate pull requestをクリック

19. 演習8. プルリクエストをレビューしてもらおう
Collaboratorにコードレビューしてもらおう
プルリクエスト画面、右側のタブからReviewerを
Collaboratorに設定
相手のリポジトリのPull requestを確認する
Files changedタブで相手のコードを確認する
Review changesでレビューを送る
OKであればApprove
おかしな点があればRequest Changes
その他質問等があればComment

20. 演習9. レビュアーにApproveされるまで直す
Approveをもらうまで
コミットとプッシュを繰り返そう
計算のプログラムを直そう
プルリクエストにコミット履歴が書き込まれていくはず
変更が一目でわかるようになる
Approveされても改善点があれば直してコミットしよう

21. 演習10. Approveされたらブランチをマージ
計算のプログラムが正常に動くと判断されたので、
masterにマージする
プルリクエストのConversationタブに移動
Merge pull requestをクリックしてマージ
マージしたらClose branchをクリックして
ブランチを削除する
リモートのmasterが最新のものに更新されたか確認する

22. ちょっと休憩

23. 演習11. masterを最新の状態にしよう
リモートのmasterをプルして、
ローカルのmasterをリモートのmasterと同期する
Sourcetreeに戻り、フェッチでリモートの変更を取得
すべてのリモートからフェッチ
masterをダブルクリックしてチェックアウトする
プルでローカルのmasterをリモートと同期

24. 演習12. 相手のリポジトリをクローンしよう
Collaboratorになっているリポジトリを
ローカルにコピー(クローン)する
Sourcetreeでファイル→新規/クローンを作成する
URLに相手のリポジトリのURLを入力
保存先のパスに空のフォルダを指定
クローンする

25. 演習13. 相手のリポジトリを編集しよう
相手のリポジトリに
計算を実行するコードを追加しよう
相手のリポジトリでmasterから新たなブランチを切る
ブランチ名は「user名/run_calculation」
相手のリポジトリをUnityで開き、
剰余計算のメソッドを実行するプログラムを書く
別のファイルに書いてください
テストを忘れないこと！
書いたらファイルをコミット&プッシュ

26. 演習14. 相手のリポジトリにプルリクエストを送ろう
相手にコードをレビューしてもらおう
githubの相手のリポジトリでプルリクエストを作る
お互いにコードをレビューしあう
Approveされたらmasterにマージし、ブランチを削除

27. 演習15. ローカルのmasterを最新の状態にする
masterの同期を忘れない(相手のリポジトリ)
Sourcetreeでフェッチ
masterをチェックアウト
プル

28. お疲れさまでした

29. まとめ

30. 用語のまとめ
クローン:
プルリクエスト:
マージ:
フェッチ:
プル:

31. 用語のまとめ
クローン: リモートリポジトリをローカルにコピー
プルリクエスト: ブランチをマージできるかチェック
マージ: ブランチを統合
フェッチ: リモートのバージョン変更を取得
プル: リモートのバージョンをローカルにコピー

32. チーム開発の基本的な流れ
ブランチをフル活用してgithubで管理する
1.機能追加の前にブランチを切る
2.コミットを重ねて機能を追加する
3.プルリクエストを送ってレビューを待つ
4.masterブランチにマージする
5. masterをフェッチ&プル
6.1-5を繰り返してmasterを更新し続ける
出典: サルでもわかるGit入門(https://backlog.com/ja/git-tutorial/)

33. コミットとプルリクエストの単位について
コミットはできるだけ細かくする
コミットメッセージ(～140文字)で端的に表せる単位
1ファイルの変更ごとにコミットするくらいの勢いで
例) 「○○ファイルのXの値をYに変更」など
1プルリクエストにつき1コミットは滅多にない
複数のコミットがまとまって1つのプルリクエストになる
例) 「HPゲージを追加」
「シングルトンパターンでデータ構造を再実装」など
どんな変更も必ずプルリクエストを送る
masterブランチに直接コミットすることは絶対に避ける

34. レビューで何をするか
コードに問題がないかを確認する
やりたいことが端的に実現されているプログラムか？
変数名やメソッド名は適切か？
不要な処理はないか？
etc...
コードを読み書きする量が増えるほど、視点や指標は増えてゆく
リーダブルコードを読んでみる
動作確認は基本的にしない
正常に動作するかは作業者が確認する(作業者が責任を持つ)
複雑な処理でプログラムを追いきれない場合はこの限りではない
批判にならないよう注意しよう
コードの拡張性を高めるための、改善案を伝えることが目的

35. チーム開発って面倒くさい...
一見手間が増えているだけだが、効率的に進むようになる
使い慣れていない技術は導入コストが高く見えてしまうだけ
全体の進捗と作業内容が可視化される
コードの質が上がり、拡張性が高まる
数多くのゲームを作りながら、使い慣れていくことが重要
エンジニアであれば確実に身につけるべきスキル

36. 参考リンク
サルでもわかるGit入門
https://backlog.com/ja/git-tutorial/
Work in ProgressパターンによるPull Requestを利用した開発フロー
https://qiita.com/numa08/items/b676e38e3dbabfd39d18
初心者向けGithubへのPullRequest方法
https://qiita.com/samurairunner/items/7442521bce2d6ac9330b
Github for Unity
https://unity.github.com