Git勉強会

Transcript

1. © DMM.com ソース管理入門 あまてく×PeachTech Git勉強会
2. © DMM.com 講師紹介 富山 雄太(マヤミト) (Tomiyama Yuta) • 22新卒 • 戦略開発本部 DMMTV開発部 ◦ Android版DMM TVを開発してます • Kotlinと車とゲームが好き ◦ 最近ランエボXを買って金欠です • 学生時代はZliという学生団体をやってました ◦ 代表経験あり
3. © DMM.com 本講義の目的 • ハッカソンなどのチーム開発において、GitおよびGitHubを円滑に活用できるように なること
4. © DMM.com ソース管理の必要性について
5. © DMM.com Webサービスに求められるもの • 安定稼働 • 継続的な開発・運用 開発チーム サービス ユーザ 機能追加・ 不具合修正 したい 24時間365日 使いたい
6. © DMM.com 開発体制に対する要求 1. 複数人での同時開発 2. 変更内容・意図の追跡 3. 状態の復元 4. リリース版保守と新機能開発の同時進行 5. レビュー・承認フローの可視化 Git, GitHubを用いたソース管理によって解決
7. © DMM.com Git, GitHubを用いた ソース管理
8. © DMM.com ここからはハンズオンです 用語の説明が多いですが、手を動かしながら少しずつ理解していきましょう！
9. © DMM.com Gitの概要 • Git • 分散型バージョン管理システム（Distributed Version Control System: DVCS） の一種 • ファイルの変更履歴を記録して管理するソフトウェア • https://git-scm.com/
10. © DMM.com Gitについて 1. 管理対象 2. 変更の記録 3. 作業ツリーの復元 4. 複数の開発ラインの管理 5. 複数のマシンによる開発
11. © DMM.com 1. 管理対象 • リポジトリ • Gitの管理単位 • 構成 • 管理対象のファイル群 （作業ツリー） • 変更履歴 • 範囲 • 特定のディレクトリ以下の ファイル・ディレクトリ
12. © DMM.com git initでローカルにリポジトリを作成する • git initとは ◦ 新しいローカルリポジトリを作成 ◦ 個人や新規プロジェクト作成時は必要になってきます • ハンズオン用のディレクトリを作成し、git initしてみましょう
13. © DMM.com • Gitはファイルを4つの状態で管理 2. 変更の記録：ファイルの状態 追跡されていない Untracked 変更されていない Unmodified 変更された Modified ステージされた Staged git管理されており、かつ変更され ていないファイル 変更されたファイル 記録につける予定のファイル git管理されていないファイル 例：新規作成したファイル ファイルへ変更を加える どの変更を記録するのか 選択する（ステージング） 変更を記録する（コミットする） git管理対象に加える
14. © DMM.com 2. 変更の記録：記録の形式 • コミット • 変更の記録 • ハッシュ値によって識別 • 親子関係を作り 親コミットへのポインタを 持つ形で蓄積 commit ecdfebc746fdf197d4ec8c704a55477373de75a1 Author: hoge-taro <hoge-taro@dmm.com> Date: Mon Mar 10 10:16:19 〇〇画面の××バグの修正 commit 389e395adbe1df1f0a9ca9ba3f0049cacce69f5d Author: hoge-taro <hoge-taro@dmm.com> Date: Tue Mar 11 13:47:13 △△機能の追加 commit 7b697ea2f8298b44f97aa4ebdb47dc0b30a5f531 Author: hoge-taro <hoge-taro@dmm.com> Date: Wed Mar 12 19:26:16 ⬜⬜表記の修正 親 子 親 子
15. © DMM.com ファイルの状態の変化を体験する Gitの状態はgit statusコマンドで確認することができます まずはecho 'Hello, Git!' > sample.txtとgit statusを実行してみましょう 新しく作ったファイルなのでGit管理下になく、Untracked filesに表示されて いると思います
16. © DMM.com git add について • git addとは ◦ ファイルの変更内容を「Staged(次のコミットに含める状態)にする」操作のこと • コマンド例
17. © DMM.com ファイルの状態の変化を体験する git add sample.txt を実行し、git statusを実行します sample.txtがgitに認識され、このファイルの状態がStagedになります
18. © DMM.com git commit について • git commitとは ◦ コミットは、Stagedなファイルの変更内容を保存する操作のこと。 ◦ 履歴を追跡できるようになります。 • コマンド例
19. © DMM.com ファイルの状態の変化を体験する git commit -m "add sample.txt" を実行し、 git status を実行します Stagedなファイル(sample.txt)の変更が記録され(コミット)、状態が Unmodifiedになります この状態だとUntracked, Modifiedなファイルが存在しないため、 git status の実行結果にsample.txtは表示されません。
20. © DMM.com ファイルの状態の変化を体験する echo 'Goodbye Git!' > sample.txt を実行してsample.txtに変更を加え、 git status を実行します。 Git管理されたsample.txtに変更が加えられているため、状態がModifiedに なります。
21. © DMM.com ファイルの状態の変化を体験する この状態で git add sample.txt, git commit -m "change sample.txt" する と、再びsample.txtがStagedになったのち変更が保存されUnmodifiedにな ります。
22. © DMM.com 3. 作業ツリーの復元 • コミットはスナップショット • いつでも過去のコミットの状態を 復元できる HogeApplication file1 file2 file3 HogeApplication file1 file2 file3 HogeApplication file1 file2 file3 commit 7b697ea2f8298b44f97aa4ebdb47dc0b30a5f531 commit 389e395adbe1df1f0a9ca9ba3f0049cacce69f5d commit ecdfebc746fdf197d4ec8c704a55477373de75a1
23. © DMM.com git resetについて • git resetとは ◦ 今の環境を特定のコミットの状態まで巻き戻すことができる ◦ --softと--hardのオプションに気をつけてコマンドを叩く ▪ オプションなしだと--softのほうになる • コマンド例 ◦ - soft - 作業ツリーの変更を残す - hard - 作業ツリーの変更を削除
24. © DMM.com 過去のコミットを復元する git log を実行すると、リポジトリのコミット履歴を確認することができます。
25. © DMM.com 過去のコミットを復元する git reset <コミットハッシュ> でGitの状態を指定したコミットまで戻すことがで きます。 git reset <add sample.txt のコミットハッシュ>を実行し、Gitの状態を最初 のコミットに戻してみましょう(コミットハッシュは皆さんの手元で確認したもの をコピペしてください)。
26. © DMM.com 4. 複数の開発ラインの管理 • ブランチ • 開発ラインを表す • コミットの蓄積によって 表現される 安定版 ライン 新規機能開発ラ イン
27. © DMM.com git branch について • git branchとは ◦ 現状含めて全てのブランチを見ることができる ◦ 存在しないブランチ名を入力することでブランチ作成も可能 • コマンド例
28. © DMM.com 現在のブランチを確認する デフォルトではmainブランチでGitリポジトリが作成される(はず)。 git branch を実行すると、現在存在するブランチが表示され、今いるブラン チにはブランチ名の隣に*が表示されます。
29. © DMM.com 4. 複数の開発ラインの管理 • ブランチを切る • 新規開発ラインを作成 • 1つのコミットを親として 2つのコミットがある状態 安定版 ライン 新規機能開発ラ イン
30. © DMM.com ブランチを作成する git branch another を実行し、anotherブランチを作成してみましょう。 git branch を実行すると、anotherブランチが作成されていることを確認でき ると思います。
31. © DMM.com git switch について • git switchとは ◦ 現在のブランチから他のブランチに移動すること ◦ -c オプションを使えばブランチ作成も一緒にできる • コマンド例
32. © DMM.com ブランチを移動する git switch another を実行し、anotherブランチに移動してみましょう。 git branch を実行すると、anotherブランチに移動できていることを確認でき ると思います。
33. © DMM.com 4. 複数の開発ラインの管理 • ブランチのマージ • 開発ラインの統合 • 2つのコミットを親にもつ コミット（マージコミット）を作成 安定版 ライン 新規機能開発ラ イン
34. © DMM.com • コンフリクト • ブランチをマージする際に、同じファイルの同じ箇所に異なる変更があり、競合 してしまう状態 4. 複数の開発ラインの管理：変更の衝突と解消
35. © DMM.com コンフリクトとマージの体験 スライドの説明通りにやっていれば、今はanotherブランチにいる状態で sample.txtファイルがModifiedになっているはずです この状態で git add sample.txt git commit -m "another change sample.txt" を実行し、anotherブランチにコミットを追加します
36. © DMM.com コンフリクトとマージの体験
37. © DMM.com コンフリクトとマージの体験 git switch main でmainブランチに戻り、 echo 'main branch change' > sample.txt でsample.txtを変更し、 git add sample.txt , git commit -m "main change sample.txt" で変更を 保存します。
38. © DMM.com コンフリクトとマージの体験 マージは git merge <取り込みたいブランチ名> で行います。 今はmainブランチにいるので、 git merge another を実行するとanotherブ ランチをmainブランチに取り込む操作になります。 今いるブランチと取り込みたいブランチで変更箇所が被っていなければその ままマージが完了しますが、今回は同じファイルで変更箇所が被っているた め、コンフリクトが発生します。
39. © DMM.com コンフリクトとマージの体験 VSCodeなどの好きなエディタでsample.txtを開いてsample.txtを確認して みましょう。 <<<<<<< HEAD ~ ======= ~ >>>>>>> main のようになるはずです
40. © DMM.com コンフリクトとマージの体験 HEADのセクションが自分が手元で加えた変更、その下のセクションが取り 込みたい変更です。 <<<<<< ===== >>>>> を消してコンフリクトを解消 します。 今回は1,3,5行目を丸ごと消して 保存しましょう。
41. © DMM.com コンフリクトとマージの体験 コンフリクトを解消したら、git add sample.txt で再度sample.txtをaddし、git commit を実行します。(今回は-mオプションなし) vimが起動し、デフォルトのマージコミットのメッセージが入力された状態に なっているので、このまま :wq を入力、エンターを押すとコミットが完了しま す。これでマージが完了しました。
42. © DMM.com • 複数マシンでリポジトリを共有 5. 複数のマシンによる開発：リポジトリの共有 Gitサーバー ローカルマシン ローカルリポジトリ リモートリポジトリ （ベアレポジトリ） ローカルマシン ローカルマシン 作業ツリー 変更履歴 （.gitディレクトリ） 変更履歴 （.gitディレクトリ）
43. © DMM.com • Gitサーバー • 仲介用のマシン 5. 複数のマシンによる開発：リポジトリの共有 Gitサーバー ローカルマシン ローカルリポジトリ リモートリポジトリ （ベアレポジトリ） ローカルマシン ローカルマシン 作業ツリー 変更履歴 （.gitディレクトリ） 変更履歴 （.gitディレクトリ）
44. © DMM.com • リモートリポジトリ • Gitサーバー上のリポジトリ • 変更履歴のみを持つ 5. 複数のマシンによる開発：リポジトリの共有 Gitサーバー ローカルマシン ローカルリポジトリ リモートリポジトリ （ベアレポジトリ） ローカルマシン ローカルマシン 作業ツリー 変更履歴 （.gitディレクトリ） 変更履歴 （.gitディレクトリ）
45. © DMM.com • ローカルリポジトリ • 手元のマシン上のリポジトリ • 変更履歴と作業ディレクトリを持つ 5. 複数のマシンによる開発：リポジトリの共有 Gitサーバー ローカルマシン ローカルリポジトリ リモートリポジトリ （ベアレポジトリ） ローカルマシン ローカルマシン 作業ツリー 変更履歴 （.gitディレクトリ） 変更履歴 （.gitディレクトリ）
46. © DMM.com • プッシュ • ローカルの変更履歴をリモートリポジトリへ反映 5. 複数のマシンによる開発：リポジトリの共有 Gitサーバー ローカルマシン ローカルマシン ローカルマシン 作業ツリー 変更履歴 （.gitディレクトリ） 変更履歴 （.gitディレクトリ） プッシュ プル リモートリポジトリ （ベアレポジトリ） ローカルリポジトリ
47. © DMM.com • プル • Gitサーバー上の変更履歴をローカルリポジトリへ反映 5. 複数のマシンによる開発：リポジトリの共有 Gitサーバー ローカルマシン ローカルマシン ローカルマシン 作業ツリー 変更履歴 （.gitディレクトリ） 変更履歴 （.gitディレクトリ） プッシュ プル リモートリポジトリ （ベアレポジトリ） ローカルリポジトリ
48. © DMM.com GitHubの概要 • GitHub • “The complete developer platform to build, scale, and deliver secure software.” • チーム開発で有用な機能を提供 • リポジトリの管理 • レビュー・承認体制の可視化 • タスクの管理...etc • https://github.com/
49. © DMM.com GitHubができること 1. Gitサーバの提供 2. レビュー・承認フローの可視化 3. その他チームコラボレーションに便利な機能
50. © DMM.com 1. Gitサーバの提供 • （復習）GitはGitサーバーを介してリポジトリを共有する Gitサーバー ローカルマシン ローカルリポジトリ リモートリポジトリ （ベアレポジトリ） ローカルマシン ローカルマシン 作業ツリー 変更履歴 （.gitディレクトリ） 変更履歴 （.gitディレクトリ）
51. © DMM.com 1. Gitサーバの提供 • GitHubはGitサーバーを提供 ローカルマシン ローカルリポジトリ ローカルマシン ローカルマシン 作業ツリー 変更履歴 （.gitディレクトリ） GitHub
52. © DMM.com GitHubにリポジトリを作成する GitHubを開き、右上の+をクリックして表示されるメニューに「New repository」があるため、それをクリックします
53. © DMM.com GitHubにリポジトリを作成する 「Owner」に自分を選択し、「Repository name」にリポジトリ名(今回 「git-learn」)を入力します 「Create repository」ボタンをクリック すると、リポジトリが作成されます
54. © DMM.com GitHubにリポジトリを作成する 次のような初期画面になると思うので、下の 「…or push an existing repository from the command line」の指示通りに コマンドを実行すると、ローカルで今まで作業していた内容がGitHubにPush されると思います
55. © DMM.com GitHubにリポジトリを作成する ここでエラーになった人はgitに認証情報を登録する作業を一緒にやりましょ う エラーにならなかった人は休憩です
56. © DMM.com チーム開発時のソース管理
57. © DMM.com (おさらい)git init について • git initとは ◦ 新しいローカルリポジトリを作成 ◦ 個人や新規プロジェクト作成時は必要になってきます • コマンド例
58. © DMM.com git clone について • git cloneとは ◦ 既存のリモートリポジトリをローカルに複製すること ◦ チーム開発などで新しいプロジェクトに参加するときに行う • コマンド例
59. © DMM.com 新しいプロジェクトをgit cloneしてみる 先ほどまでのディレクトリとは違うディレクトリに移動し、以下を実行してくだ さい git clone https://github.com/yt8492/git-study.git git-studyリポジトリがローカルにcloneされるので、git-studyディレクトリに 移動してください。
60. © DMM.com 新しいプロジェクトをgit cloneしてみる README.mdというファイルが存在すると思います
61. © DMM.com 演習1 • このリポジトリにはもともと exam-base というブランチが作成してあるの で、そのブランチに移動してください • exam-baseブランチに移動したら、そこから自分のブランチを作成して そこに移動してみてください ◦ 例えばtomiyama-yutaブランチを作成してそこにブランチを移動 • README.mdに書いてある自己紹介を自分のものに修正し、add, commitしてGitHubにpushしましょう
62. © DMM.com • プルリクエストとは ◦ ブランチで行った変更内容を他のメンバーにレビューしてもらい、対象のブラン チ（例: mainやdevelop）にマージするための仕組み ◦ 差分が視覚的に確認できる ◦ コードレビューを円滑に進めるために用いる Pull Requestの説明 画像：https://www-creators.com/archives/4996
63. © DMM.com • Draft PullRequestとは ◦ 開発中の変更内容を下書きとして共有するPRの形式 ◦ 進捗状況を共有したい場面で役に立つ • 特徴 ◦ ドラフトの状態ではマージができない ◦ レビュー依頼の前に、コメントやフィードバックを頂くことが可能 Draft PullRequestの説明
64. © DMM.com • commentとは ◦ PullRequestの変更点のフィードバックを行うためのもの • 使用するタイミング ◦ 軽微な改善点やリファクタリングの提案をする場合。 ◦ コードの意図を確認したい場合。 ◦ コードの意図をレビュアーに伝えたい場合 PullRequestのcommentの説明
65. © DMM.com • Approveとは ◦ PullRequestをマージしても問題ないと判断した場合に行う操作 • 使用するタイミング ◦ コードレビューを行い、仕様や実装に問題がないと判断した場合。 ◦ テストが正常に通過し、CIの要件を満たしている場合。 PullRequestのApproveの説明
66. © DMM.com • GitHub上でPullRequestを作成 ◦ タイトルと説明を伝わるように記述する • レビュアーを追加 PullRequestの出し方
67. © DMM.com • タイトル: 簡潔かつ具体的に変更内容を記載 • 説明（下記一例） ◦ 何をしたか（概要） ◦ なぜ必要か（背景） ◦ テストした内容 ◦ 必要なレビュー観点（例: UIの変更、パフォーマンス） • テンプレートを活用する PRのタイトルと説明
68. © DMM.com • レビューではあくまでコードにコメントするが、読むのは人間 ◦ 表現の柔らかさに気を遣う ◦ 絵文字やLGTM画像などでフランクさを伝えるのも◎ • コメントをした人と受け取る人で感じ方が異なる ▪ 「この部分の実装でAを使っているのはなぜ？」 ▪ 「あ、すみません！Bを使って実装し直します！」 ▪ 「ただの質問だったんだけど……」 ◦ レビューコメントにラベルを付けどのようなコメントか明確にしたり レビュー時の会話の心得
69. © DMM.com Pull Requestの作成 GitHubの「Pull requests」タブを開き、「New pull request」ボタンをクリック します
70. © DMM.com Pull Requestの作成 baseがmain、compareが自分の作成したブランチになっていることを確認し たら、Pull Requestのタイトルを説明文を入力し、「Create pull request」ボタ ンをクリックします
71. © DMM.com Pull Requestの作成 指示通りにできていれば、コンフリクトするはずです
72. © DMM.com git pullについて • git pullとは ◦ リモートリポジトリの最新変更をローカルリポジトリに取り込む操作 ◦ 他のメンバーの作業内容を反映できます。 • コマンド例
73. © DMM.com git pullで最新のmainを取り込む mainブランチに変更を今加えたので、それを皆さんの手元に反映させましょ う。 git switch main でmainブランチに移動し、 git pull origin main を実行して ください。 ファイルの中身を確認すると、最新のmainの状態に更新されたのがわかる と思います。
74. © DMM.com 演習2 • Pull Requestのコンフリクトを解消しましょう ◦ Pull Requestのコンフリクトの解消の仕方は、マージしたいブランチ(皆さんが 作ったブランチ, 例だとtomiyama-yuta)に対してマージ先のブランチ(今回は main)をローカルでmergeし、ローカルでもコンフリクトを発生させたうえでそれ を解消し、コンフリクトが解消された状態で再度pushすることでPull Requestの コンフリクトも解消されます
75. © DMM.com コミットの粒度 • コミット = 作業ログ • コミットの大きさ ◦ コミットが大きい ▪ ロールバックポイントが少ない ◦ コミットが小さい ▪ コミットログが多い ▪ 変更点がわかりづらい
76. © DMM.com コミットの粒度 • コミットをするタイミング ◦ issue等のチケット単位 ▪ 機能要件に沿ったコミット ◦ セーブポイントとして ▪ 作ったところまで、失いたくないポイントでコミット ◦ 動作が保証されている状態 ▪ ロールバックする場合を意識したコミット
77. © DMM.com コミットメッセージ • 後から見て何をしたコミットなのかがわかるメッセージ ◦ prefixでコミットの種類を判別できるようにしたり(gitmoji) ◦ 「wip〇〇」のような内容がわかりにくいのは△ • コミットメッセージの1行目は簡潔に ◦ Gitクライアントにサマリとして使われる ◦ 説明が必要な場合は改行を挟んで3行目以降が多い印象
78. © DMM.com その他のコマンド status - 現在のリポジトリ状態を表示する fetch - リモートリポジトリの最新の変更を取得する diff - ファイルの変更内容や差分を表示する tag - 特定のコミットにタグ（バージョンや目印）を付ける log - リポジトリのコミット履歴を表示する remote - リモートリポジトリを管理する switch - 作業ブランチを切り替える restore - ファイルの変更を元に戻す cherry-pick - 特定のコミットを現在のブランチに適用する blame - ファイルの各行が「いつ」「誰によって」変更されたかを表示する rev-parse - SHA-1ハッシュやブランチ名など、Git内部で使われる情報を取得する filter-branch - 過去の履歴から特定のファイルを完全に削除する(破壊的変更のため、注意！)
79. © DMM.com ブランチの命名 • 英単語2〜4単語くらいで概要を書いておく ◦ 変更内容がわかりやすくなる • チームの運用によって柔軟に変える ◦ 例： ▪ ▪ イシュートラッカーのチケット番号をプレフィックス
80. © DMM.com Git Flowの説明 • 複数のブランチを使い分けて、複雑な開発プロセスを整理するための運用モデル • 主なブランチ ◦ main - 本番環境 ◦ develop - 開発環境 ◦ feature - 新規機能開発 ◦ release - リリース準備 ◦ hotfix - 緊急のバグ修正
81. © DMM.com Git Flowの利点と欠点 • 利点 ◦ 複雑なプロジェクト管理に強い ▪ 複数のブランチが役割ごとに分かれているため、並行開発がしやすい。 ▪ リリース準備や緊急対応がしやすい。 ◦ 安定性 ▪ 本番環境に影響を与えずに開発が進行可能。 • 欠点 ◦ 小規模プロジェクトでは冗長 ▪ ブランチが多すぎると管理が煩雑になる。
82. © DMM.com GitHub Flowの説明 • mainブランチを中心としたシンプルなブランチ運用モデル • 小〜中規模プロジェクトに適している • 主なブランチ ◦ main - 常時デプロイ可能 ◦ feature - 新規機能・修正
83. © DMM.com GitHub Flowの利点と欠点 • 利点 ◦ シンプル ▪ mainとfeatureブランチのみで運用可能 ◦ 履歴が見やすい ▪ マージコミットが簡潔で、履歴が見やすい • 欠点 ◦ 大規模プロジェクトには不向き ▪ リリースの調整が必要なプロジェクトでは管理が難しい ◦ 複数環境の対応が困難 ▪ 開発環境、ステージング環境、本番環境などがある場合は工夫が必要
84. © DMM.com ハッカソン参加の心構え
85. © DMM.com 一番重要なこと • 開発を楽しむ 優勝することに囚われすぎないでほしい 優勝することに囚われすぎて、技術をおろそかにして発表だけ凝るのはハッ カソンに参加する意義が薄くなる
86. © DMM.com ハッカソンを円滑に進めるコツ • 開発に取り組む前に方針をちゃんと立ててそれに従う • Gitのブランチの運用 • レビュー、マージをどうするか • タスクを細かく分解する • 細かく分解すると分担もしやすくなる • 暇な人がなるべく出ないように • タスクごとに難易度も設定するとやりやすくなる • 進捗確認を定期的にする • 今やっていることを定期的に話し合うことにより、仕様などの認識のズレなどに も気づくことができる