Cookpad Summer Internship 2021 Git/GitHub

https://internship.cookpad.jp/summer2022-detail-01-1 の 1 日目の講義で使用した資料です。

Transcript

1. © 2022 Cookpad Inc. Day 1 Git/GitHub ボイスサービス部 山田 良明
2. 講師 • 山田 良明 (@y_am_a_da) ◦ ボイスサービス部で部長兼エンジニア ◦ 16 新卒入社 ◦ 今年 新卒採用 色々もやってます
3. TA • 緑川たか り (@pearbook_jp) ◦ CTO室 技術広報とかイベント 企画とかしてます ◦ 本を作る が趣味で出版社で編集者をやってました ◦ 得意な言語 Pythonだったりします笑
4. こ 講義でやること • Git と GitHub 使い方を理解する • 特にチーム開発をする際 主な流れや、良いプルリクエストを 書き方 などについて理解をする ◦ 後半 OJT で非常に重要となる でぜひとも覚えてください
5. Git と ？
6. Git と ？ • 分散型 バージョン管理システム (VCS) • 一つ ファイルやそ 集合に対して時間とともに加えられていく変更を記録するも • 過去 変更履歴を比較したり、問題が発生した日時にど ような変更が加えられていた か調査ができる。また、ファイルやそ 集合を特定 時点 状態に簡単に戻すことなどもで きる
7. バージョン管理システム 歴史
8. バージョン管理？
9. • 初版.txt • 初版_2.txt • 初版_フィードバック通過済.txt • 最終版_3.txt • 最新 最終版.txt • 最終版_レビュー通過済み2.txt • 最終版_タイポ修正.txt • 完成版.txt • 完成版_最新.txt
10. • 2019_06_30_初版.txt • 2019_07_06_差し戻し対応.txt • 2020_03_01_画像データ 差し替え.txt • 2020_08_04_序章 修正.txt • 2021_01_07_第五章 追加.txt • 2021_11_12_グラフ 追加.txt • 2022_04_05_誤字脱字 修正.txt • 2022_06_03_完成版.txt
11. • 2019_06_30_初版/ • 2019_07_06_差し戻し対応/ • 2020_03_01_画像データ 差し替え/ • 2020_08_04_序章 修正/ • 2021_01_07_第五章 追加/ • 2021_11_12_グラフ 追加/ • 2022_04_05_誤字脱字 修正/ • 2022_06_03_完成版/
12. ローカル・バージョン管理システム • バージョン管理下 ファイルに対する 全て 変更を保持するシンプルなデータベース • ファイル間 差分 集合を特殊な フォーマットでディスク上に保持するという仕組み で動いている • RSC (Revision Control System) が有名 Local Computer Version Database Version 3 File Checkout Version 2 Version 1
13. 集中バージョン管理システム • ローカルで なく、ネットワーク上にあるサー バーに変更をコミットしていく形式 • プロジェクト 他 開発者が何をしている か、全員がある程度わかる • しかしながら、クライアントがオフラインであっ たり、サーバーがなんらか 理由で障害を起 こすと開発を継続できなくなってしまう Central VCS Server Version Database Version 3 Version 2 Version 1 File Computer A File Computer B
14. 分散バージョン管理システム • 最近 主流。 Git もこれ • 特定 ファイルやディレクトリをコピーする で なく、リポジトリ全体をクライアントにミ ラーリングするため、ローカルでも履歴を持つ ことができる • ローカルで履歴を持つことができるため、ロー カルでコミットすることが可能 Server Computer Version Database Version 3 Version 2 Version 1 Computer A Version Database Version 3 Version 2 Version 1 File Computer B Version Database Version 3 Version 2 Version 1 File
15. Git を使ってみよう
16. 初期設定 • コミットに記録される名前とメールアドレスを設定します • git config –global user.name “Your name” • git config –global user.email “Your email”
17. リポジトリ 作成とファイル 追加 • リポジトリ 作成 ◦ mkdir -p ~/works/git-handson ◦ cd ~/works/git-handson ◦ git init • ファイルを追加 ◦ echo “#README” > README.md ◦ git add README.md ◦ git commit -m “Add README.md”
18. 3つ エリア • Working Directory ◦ ディスク上に配置されているファイル郡がある場所 • Staging Area(.git/index) ◦ 次 コミットに含まれる情報が蓄えられている場所 • Repository(.git/objects) ◦ リポジトリ データベース ◦ メタデータやオブジェクトなどが格納されている Working Directory Staging Area Repository git add git commit
19. ブランチ • 本流(main)から分岐して履歴を記録することができる機能 • 複数 ブランチを作ることができる で、並行して複数機能 開発も可能 • git branch new-feature • git checkout new-feature • echo “## New Heading” >> README.md • git add README.md • git commit -m “Update README.md”
20. 変更 マージ • ブランチで 開発が完了したら、変更を mainに取り込む • git checkout main • git merge –no-ff new-feature
21. fast forward • マージ先 ブランチが指すポインタをマージ元に合わせるだけ • 利用者 観点から マージ 際にマージコミットを作るか作らないか 違いが大きい • –no-ff 場合「必ず」マージコミットを作る ◦ git log で作られることが確認できると思います • –no-ff をつけない場合、 Git が fast forward できるか判断する ◦ git reset –hard HEAD^ ◦ git merge new-feature ◦ git log をしてもマージコミットが見つからないと思います main main
22. ff or no-ff • GitHub プルリクエスト マージ no-ffです ◦ という もあり、GitHubを開発に利用している人 基本的に no-ffを利用している印象 があります • マージコミットが存在していると、そ 機能 差し戻し (revert)が楽にできます • 逆にff 手元で複数 ブランチを操作して開発している時に使うかもしれません ◦ あるブランチAから更に派生させたブランチBがあり、ブランチBを手元でブランチAに マージさせたい時など
23. rebase • git checkout feature-branch • git rebase main • ブランチ 派生元を変更するイメージ ◦ main 変更をブランチに反映させるときなどに使う • 親コミットが変わるため、コミット リビジョンが変わることに注意
24. チーム開発について
25. GitHub • 開発に多数 人間が関わる場合、リポジトリ 管理や変更 取り込み 管理などが大変 • GitHub を使うことで管理 手間を減らす • GitHub = ソースコードホスティングと表現されることもあるが、どちらかというと開発 やり 取りをする場 • クックパッドで GitHub Enterprise を使用 ◦ 名前 通り Enterprise 向け GitHub で、 SSO など組織で 開発に必要な機能が 盛り込まれている
26. GitHub を利用したチーム開発 ワークフロー tech/cookpad_all yoshiaki-yamada/cookpad_all Local push clone fork Pull Request pull git remote -v origin ssh://ghe.ckpd.co/yoshiaki-yamada/cookpad_all upstream git@ghe.ckpd.co:tech/cookpad_all
27. GitHub を利用したチーム開発 ワークフロー 1. 対象プロジェクトをGitHub上でforkする a. gitにforkという機能 実 ないが、慣習的な理由もあり人 リポジトリ コピーを作る ことをforkという 2. forkしたリモートリポジトリをローカルに clone 3. ローカルでbranchを作成し、何らか 変更作業をしてからコミット 4. ブランチをリモートリポジトリにpush 5. GitHub上でPull Requestを作成する 6. CI 確認、コードレビューなどをし、問題がなけれ マージする (orしてもらう)
28. ローカルリポジトリとリモートリポジトリ • ネットワーク上にあるリポジトリをリモートリポジトリという • GitHubにあるリポジトリとローカルにあるリポジトリ 別 も な で区別するために使う • 1つ ローカルリポジトリに複数 リモートリポジトリを設定することが可能 • 慣習的に以下 名前をつけることが多い ◦ upstream: fork 元となったオリジナル リモートリポジトリ ◦ origin: clone 元となったリモートリポジトリ
29. プルリクエストを送ってみよう • https://ghe.ckpd.co/yoshiaki-yamada/2022-summer-intern-git.git をfork • cd ~/works • git clone https://ghe.ckpd.co/[your-name]/2022-summer-intern-git.git • cd 2022-summer-intern-git • git branch add-my-readme • git checkout add-my-readme • vim [your-name].md • 今回 インターン 意気込みを書こう • git add [your-name].md • git commit -m “Add [your-name].md” • git push origin add-my-readme • GHEからPull Requestを送ろう
30. Upstream 更新をローカルに反映させよう • git remote add upstream git@ghe.ckpd.co:yoshiaki-yamada/2022-summer-intern-git.git • git remote -v • git fetch upstream • git checkout main • git merge upstream/main
31. チーム開発に臨む上で意識して欲しいこと
32. プルリクエスト • チーム開発で 、開発者 変更を main ブランチに取り込む前にレビューを通す が一般 的 ◦ 開発者が気付いていていないバグ 混入などを事前に防ぐため • レビューを依頼するために開発者 プルリクエストを作成する ◦ レビュアー 、修正 内容について色々と指摘をしたり質問したりします
33. プルリクエスト コミュニケーションツール • 修正や機能追加 、必ずしもチームで管理しているリポジトリだけを対象にすると 限らな い • プルリクエストが作成された場合、それをレビューする そ リポジトリ オーナーである ことが多い • すなわち、必ずしもあなた チームメンバーと 限らない ◦ こ プルリクエストを作るに至った背景を知っていると 限らない ◦ こ プルリクエストで達成したいことを理解できていると 限らない • そんな人達が見ても修正内容に問題が無いかどうか判断できるような情報を予め提供して おくことが重要
34. プルリクエスト 粒度 • 適切な粒度を説明する 難しいが、少なくとも「大きすぎる」より 「小さすぎる」方が良い ◦ 迷ったら小さくする ◦ レビュアー 負担が減る • どうしても大きい変更になる場合 、作業を別途切り出せないか検討する ◦ リファクタリングやフォーマット 変更、ライブラリ 導入やバージョンアップデートなど
35. プルリクエスト 説明文に書くも • What ◦ こ プルリクエストでやろうとしていることを簡潔に書く • Why ◦ なぜこ プルリクエストを取り込む必要がある か (= こ 実装が必要な か ) を書く ◦ コンテキストや、関連するイシューやプルリクエストがあれ リンクを貼る • How ◦ どういう実装をした かを説明する ◦ コミットログごとにどういう実装をした かを説明すると丁寧 ◦ 画面に影響 ある変更だったらスクリーンショットなどを貼っても良い • Anything else ◦ いわゆる「そ 他」 ◦ 上記に含まれないが共有しておきたいことがあれ ここに書く ◦ 特に注目してレビューして欲しい箇所や心配事、実機テスト 方法など
36. プルリクエスト 歴史を掘り返す資料 • 実装 コンテキストやチーム内で 議論が機能や修正単位で残っているドキュメントとなる • 例え自分しか実装に関わってないようなアプリケーションでも書いておくと後でめちゃくちゃ 助かる
37. わかりやすいコミットを作る • 一定以上 大きさ プルリクエストで 、コードによる変更点だけをざっと眺めてもレビュー しづらいことも多い • そ 際に理解しやすいコミットに分かれていると非常にレビューがしやすくなる ◦ ざっとコミット メッセージに目を通すことで、修正点 全体像を把握しやすくなる ◦ それぞれ コミットで着目すべき点がわかりやすくなる • 後で GitHub で 検索や、 git blame などをした時に見つけやすい & 意図を理解しやすい • コミット メッセージと粒度に 特に気を使う
38. コミットメッセージ • 「fix」や「update」というメッセージ コミット レビューする側からすると何も情報が無い • コミットメッセージ タイトルに 概要を簡潔に書く ◦ 「Use foo method instead of bar method that deprecated」 • コミットメッセージ 本文に 「なぜ」を書くことを意識する ◦ 実際にど ように実現をしているか コードを読め わかる ◦ 「なぜ」 コードを読んでもわからない ◦ タイトルで説明が済んでいれ 本文 無くても良い ▪ 個人的に プルリクエスト 説明文 中にコミット 説明を含めてしまうことも多 い
39. コミット 粒度 • 「大きすぎる」より 「小さすぎる」方が良い ◦ 迷ったら小さくする ◦ コミットメッセージが長くなりすぎたり、色々な内容を含んでいたらそれ 「大きすぎる」 コミットである可能性が高い • 意図が伝わるコミットを目指す ◦ やりたいことに対して本質的な変更 みにする ◦ たまたま見つけたからと言って、関係 ない typo などを一緒にまとめたりしない ▪ 別 プルリクエストに分けるか、少なくとも別 コミットにする
40. 履歴を整える • 多く 場合で 、最初から一発で綺麗なコミットにまとめられること ない ◦ コミットを作った後にもっと良い方法を思いついた。とか単純な修正漏れやタイポなど • そ ため、適宜それらしいコミット 作りつつ、後で整えることも多い ◦ git rebase -i ◦ git commit –amend ◦ git add -p
41. まとめ • プルリクエスト 修正 レビューを円滑に進めるため コミュニケーションツール ◦ な で、レビュアーが読んでコンテキストから修正 内容まで把握しやすいように意識 しよう ◦ プルリクエストもコミットも大きすぎるより 小さい粒度で作ろう ▪ あれもこれもやっているようなも に しない • プルリクエスト 歴史を発掘するため 資料 ◦ 当時 背景や、こ 実装にした意図を掘り起こすことができる • テクニックであって制約で ない であまり囚われないようにしよう ◦ チーム サイズやプロジェクト フェーズによってベストプラクティス 多少異なるかも しれない ◦ 開発 コミュニケーションに課題を感じたら意識してみて欲しい