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