Git Training GitHub

Transcript

1. Git & GitHub 研修 GitHub Workshop
2. 服部 佑樹 Senior Customer Success Architect – GitHub Japan エンタープライズ向けの技術的な支援を提供、 GitHub Copilotの日本国内での普及を牽引。 President - The InnerSource Commons Foundation オープンソース手法を企業内に導入する「インナーソース」の普及に尽力。 InnerSource Commons財団の Presidentをつとめ、インナーソースの世界的な 発展に貢献。 情報処理推進機構（IPA）オープンソース推進の2025年度専門委員 著書に「コード×AIーソフトウェア開発者のための生成AI実践入門（技術評論社）」、 「DevOps Unleashed with Git and GitHub（英Packt Publishing社）」がある。 「LLMのプロンプトエンジニアリング」翻訳。論文: 「InnerSource Circumplex Model」
3. Git 研修 アジェンダ Git の紹介 Git / GitHub ハンズオンエッセンシャル版 (GitHub アカウントが必要) Git ハンズオン Deep Dive (VS Code / Git が必要) • Git の使い方 • リポジトリを作成する • Stage と Commit • Branch • Merge • Git の仕組み • リモートリポジトリ • Git の branch 戦略
4. https://bit.ly/git-github-training
5. Git の特徴 The feature of Git なぜ Git が登場したのか
6. 従来のSCM ( Source Control Management ) ファイル単位での作業・管理 (ex. CVS, Subversion) 集中管理型リポジトリ ※リポジトリとは、ソースコード、ディレクトリ構造、履歴、メタデータなどを保持・管理する場所のこと メリット • シンプルなため操作が簡単 • 導入ハードルが低い デメリット • サーバーがSPOF • ロックを使用しないとConflictが多発 • ロックにはオンラインが必須 • ロックによる作業停滞が発生 • Branch が作れるものもあるがMergeが遅くか つMergeに失敗すると元に戻せない • 巨大ソース時のレスポンスが激しく劣化 サーバー用App クライアント用App 1. サーバーの最新を取得 2. ローカル作業 ① 複数ファイルを編集開始 （必要なら手動でファイルをロック、もしくは自動的にロック） ② ファイル保存 3. サーバーへ編集結果を送信（ロック解除） サーバーとクライアントで機 能が異なるため、アプリも 異なる
7. Git の特徴 コミット単位での作業・管理。すべてが高速、他人の作業に影響されない 分散型リポジトリ Git メリット • SPOFが完全に解消される • ロックの概念がなく、オフラインでも作業できる • Branch の作成, Merge が超高速 • ソースが巨大化してもレスポンスが劣化し ない デメリット • これまでのSCMと概念が異なるため、しっかり理 解して使わないと事故が起こる • ロックがなくなった代わりに手順が増えて 面倒 • ファイル単位ではなくコミット単位で管理 するため、ファイル単位で何かしたいとき は不便 リモートリポジトリ ローカルリポジトリ 1. サーバーのリポジトリから最新を取得 2. ローカル作業 ① メイン Branch から作業用（機能単位）の Branch を作成 ② 複数ファイル編集開始 ③ ファイル保存 ④ コミットする（コミット対象をステージしてから） 3. ロックの代わりに行う作業 ① 再度サーバーのリポジトリから最新を取得 （他メンバーの作業結果を取得） ② メイン Branch へ 作業用ブランチを Merge 4. サーバーへ編集結果を送信 ローカルリポジトリ • サーバーとクライアントで機能が同じなの でアプリは同じ • 自分が同期する先のリポジトリを「リ モートリポジトリ」と呼ぶ （呼び方だけの話） Git では複数ファイルの変更結果のことをコミットと呼びます（※正確な説明ではありません。後ほど正しい説明があります）
8. GitHub とは？ Git を独自拡張した SaaS Web 画面 コミット履歴参照 ソース修正＋コミッ ト機能 メンバー管理・権限 管理 Pull Request 特定 Branch から 特 定 Branch への Merge をリクエスト する機能 リクエスト内容をレ ビュー・承認・拒 否・Merge Issue 管理 バグや要望を受け付 ける コミットと issue の 紐づけ Fork 他アカウントのリポ ジトリを自分のリポ ジトリへコピー 自分のリポジトリで の編集結果（コミッ ト）を、元リポジト リへ Pull Request を 出せる GitHub Actions ソースをビルド＆テ スト ビルド結果をデプロ イ MarketPlace から 様々な拡張 ※ Pull Request は GitHub 以外の様々な Git ホスティングサービスで実装されています ex. Azure Repos, GitLab, Bitbucket ※ Git には古くから request-pull というコマンドもあります チームで作業するための機能を大幅に拡張し、Web画面による視認性を向上させたサービス
9. ハンズオンの準備 Preparation
10. 環境について この講習では Visual Studio Code を用いて Git の紹介します。また、Git は Visual Studio Code に付随しません。別途インストールし てください。 ⚫ Visual Studio Code のインストール https://code.visualstudio.com ⚫ Git のインストール https://git-scm.com/ また残念ながら Visual Studio Code （以下 VS Code）による Git の GUI 画面では Git の全ての操作を行うことができません。その ため様々な VS Code の拡張機能があります。この講習では Git Graph を用います。インストールして下さい。 ⚫ Git Graph のインストール https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph * GitHub だけでもハンズオン (Essential 版) は実践できます
11. Essential版 ハンズオン
12. リポジトリの作成をします https://github.com/new にアクセス
13. 新しいファイルを作成します
14. 新しいファイルを作成します README.md はリポジトリの顔となるファイルです。一般的にリポジトリの概要を書き込みます。
15. Main ブランチに直接中身を書き込んでみましょう 右上の ペンのボタンから編集を開始します。
16. Main ブランチに直接中身を書き込んでみましょう ファイルに内容を追加しましょう。 ファイルを追加したら “Commit changes” で変更を確定 (Commit) します。
17. 今度は新しいブランチを作って「マージ」を体験します 左上のドロップダウンメニューより 「new-branch」という名前の新しいブランチを作成します
18. 新しいブランチの内容を編集します 新しくファイルにコメントを書き込んで、編集をし、確定 (Commit) します。
19. プルリクエストを書いてみよう プルリクエストを作成します。先ほど作ったブランチを選び 「Compare & pull request」 をクリックします。
20. ”Merge pull request” でマージをします
21. マージのコミットメッセージを入力します
22. Deep Dive版 ハンズオン
23. Git の使い方 The usage of Git
24. リポジトリを作成する
25. リポジトリを作成する 次にフォルダを VS Code で開きます。方法はいくつかあるのですが、一番オーソドックスな方法は VS Code を一度立ち上げて「ファイル」から「フォルダーを開く」を選択する方法です。 Git はリポジトリをローカルに作るところから始めます。 まず C:\gitroot というフォルダを作り、この配下にリポジトリを格納することにします。Git はリポジトリをフォルダ単位で構成しま す。フォルダが違えば違うリポジトリにすることができます。 テスト用のローカルリポジトリとして C:\gitroot の下に gittest というフォルダを作りましょう。
26. リポジトリを作成する 画面一番左側にアイコンが縦に並んでいます。 デフォルトの並び順の場合は上から3つ目のアイコンが Git の（正確 にはソース管理の）アイコンです。アイコンをクリックします。 もし Git のアイコンが見当たらない場合は非表示になっています。 左側アイコンのどれでもいいので右クリックします。 「ソース管理に」チェックを入れると Git アイコンが表示されます。
27. リポジトリを作成する ではリポジトリを作成しましょう。 「リポジトリを初期化する」をクリックします。 クリックすれば リポジトリが作成されます。 エクスプローラで C:\gitroot\gittest を開き、隠しファイル を表示させると .git フォルダが作られていることがわかりま す。 この .git フォルダ内にファイルが圧縮されて履歴とともに 格納されていきます。
28. Git の初期設定
29. Git の初期設定 Git は 誰が Commit したのか、情報を保管しています。複数人で作業する場合に大事なことです。 Git は 設定情報を .gitconfig というファイルに持っています。 直接ファイルをテキストエディタで編集しても良いのですが、通常はコマンドで行います。 コマンドプロンプト, PowerShell, Git Bash など Git に Path が通っているターミナルからであればどれを使用しても構いません。 （コマンド実行時のカレント：現在の場所はどこでも構いません） $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com 自分の名 前に変更 自分のメルア ドに変更
30. Stage と Commit
31. Stage と Commit Git は裏側に Key-Value 方式のデータベース（ Repository ）を持っています。そのデータベースに編集したソースコード等のファイル を登録していきます。 データベースへの登録はファイル単位ではありません。複数ファイルへの変更をまとめて登録します。 この登録のことをCommit と呼びます。 実際の操作は ローカルリポジトリ内で git commit コマンドを叩くのですが、この講習では VS Code を使用して GUI で操作して Commit します。 データベースへ登録するのはファイルです。従って Commit する内容は以下になります。 ⚫ 新規ファイル ⚫ Commit 済みファイルへの編集結果 ⚫ Commit 済みファイルの削除 Commit
32. Stage と Commit Git では複数のファイルをまとめて登録する、という性質があるため 作業したファイルのうちどれを Commit するのかを事前に決めな ければなりません。これを Stage する、Staging へ上げる、と表現します。 （ Staging は Index と呼ばれることもあります） Stage 操作も VS Code で簡単に行うことができます。 Commit 操作は Staging に上がっているファイルをすべてデータベースに登録します。 したがって、実際の操作は次のような手順になります。 Commit Stage Stage （選択） （登録）
33. Stage と Commit Staging へ上げる前の状態、ファイルを編集している状態を Workspace と呼びます。 （ Worktree と呼ばれることもあります） Commit Stage （選択） （登録） Workspace Commit を行うと Commit Id が発行されます。これは Key-Value の Key のことです。 Commit Id は SHA-1 ハッシュ値（40桁）です。ファイルのバイト数と中身から計算され、重複する可能性がとても低い値 です。 d0444cbb34c9c6f903050034571f1544df20e9 Commit Id 発行 Key に使う
34. Stage と Commit それでは Stage のやり方をご紹介します。 C:\gitroot\gittest フォルダを VS Code で開きます。Git のリポジトリとして初期化 していない場合は「ローカルリポジトリ」を参照して初期化してください。 新規ファイル作成アイコンをクリックします。 ファイル名として今回は file1.txt と入力します。
35. Stage と Commit file1.txt の編集画面が右側に開きます。 1行目に file1 と入力してファイルを保存します。 （ファイル保存のショートカットキーは Ctrl + s ） Stage するために Git の画面に切り替えます。画面一番左側の縦の アイコンから Git のアイコンをクリックします。
36. Stage と Commit Git のアイコンをクリックして表示されるエクスプローラのような画面で Git の操作 は行います。 Stage してみましょう。 file1.txt の上にマウスポイントを持っていくと、 左図のよう にファイルの横にアイコンが表示されます。 file1.txt を Stage するには ＋をクリックします。 （複数ファイルを選択状態にしてから＋をクリックすれば同時に複数ファイルを Stage することができます） file1.txt の表示される場所が変わり、「ステージされている変更」に表示されてい ます。 Stage に上がったファイルはこの「ステージされている変更」に表示されます。
37. Stage と Commit Commit のやり方をご紹介します。 テキストボックスに Commit メッセージを書きます。 Commit メッセージは必須で す。 書き方に決まりはなくフリーフォーマットです。一般的に1行目には概要を50文字 以内、空行を追加して、リスト形式で詳細を記載する書き方が推奨されていま す。詳細リストの行頭はアスタリスクやハイフンがよく用いられます。 Commit メッセージを書いたら チェックアイコンをクリックすると Commit します。
38. Stage と Commit Commit した後の画面をみても Commit できたのか全くわかりません。 ここで、 Git Graph の出番です。 Git Graph アイコンをクリックします。 Commit した結果が表示されています。一番右に Commit Id の先頭数桁だけが表示されています。（40桁 は長いので） Commit メッセージの2行目以降を見たい場合やどのファイ ルが Commit されたのかを見る場合は、 Commit 行をク リックします。
39. Stage と Commit Commit 行をクリックすると Commit の詳細 を見ることができます。 Commit メッセージと、この Commit によって Repository へ格納されたファイルが何かがわ かります。 もう1度 Commit 行をクリックするか、右側の ×アイコンをクリックすれば詳細を閉じることが できます。
40. Stage と Commit Git は少し作業して区切りがついたら Stage して Commit 。これを繰り返すことになります。 ここでは続けて file2.txt を作成して Commit しました。 このように Commit を続けていくと Commit 履歴が連なっていきます。 ここで、file2.txt を Commit した最新の Commit の詳細を見てみます。
41. Stage と Commit Parents という箇所に注目してください。 ここに表示されているのは Commit Id なのですが、こ れは1つ前の Commit の Id なのです。 このように Commit は自分がどの Commit の続きな のかがわかるように 親 Commit の Id を持っています。
42. Commit の参照関係 前ページの説明の通り Commit は親 Commit の Id を持つことで参照関係を築いています。そのため Commit のイメージ 図では参照関係を表す矢印で表現されることが多いです。（Commit した順番と方向が逆になる） コミットid 0388ee7 コミットid 421df24 親コミットid 0388ee7 コミットした順番 コミットid 8941bcb 親コミットid 421df24 Commit Id の SHA-1 ハッシュ値40桁をそのまま使用するのは長すぎるため、よく7桁程度で省略して表記されます。（コマ ンドでも省略7桁で使用することができますが、その場合は衝突に注意が必要です）
43. Branch
44. Branch とは Branch は枝、支部を意味します。 Git は初期状態で main という名称の Branch があります。 （※以前は master という名称でした） main Branch は自由に増やすことができます。異なる Branch 間では作業結果（ファイルの編集結果）が完全に独立するため、他 Branch に影響を及ぼすことなく作業することができます。 main BranchA file2.txt file2.txt 同じファイルに対して異なる編集 結果を保存できる
45. Branch とは Branch は機能単位に作成したり、 BugFix 時に作成することが多いです。ブランチを作成することを一般的に「ブランチを切 る」と表現します。 分岐したブランチで作業した結果を、他のブランチが取り込むことを Merge と呼びます。 Merge には複数の方法がありますが、ここでは代表的な Merge コミットをご紹介しています。 main main BranchA 最初はブランチ１ つだけ ブランチ 切った main BranchA それぞれのブランチで Commit が進んだ main BranchA Merge した Commit
46. Branch とは Branch を切るようになると、自分が今どの Branch にいるのかを把握しておく必 要があります。 Git では現在位置を HEAD と表現します。 main BranchA HEAD main にいるこ とを表す もちろん自分の位置を変更して別の Branch へ移動することができます。 Checkout という操作です。 Branch を移動することを Branch を切り替える、と表現します。 main BranchA HEAD BranchA に Checkout した
47. Branch とは VS Code で現在位置を把握するには、画面一番下の左側を見てみ ましょう。Git アイコンの横に main と表示されているが現在位置の Branch です。 Git Graph では Branch アイコンの左横の〇で表現されています。
48. Branch を作る main 最初は main ブラ ンチ１つだけ VSCode の Git ア イコンをクリック Create Branch を クリック 三連ドット をクリッ ク それでは Branch を作ってみましょう。 最初は main ブランチしかありません。
49. Branch を作る main FeatureA Branch 名を入力 して Enter ブランチ が作られた 影響なし Branch 名に決まりはありません。 機能単位に Branch を 作る場合は feature/～～ のように スラッシュで区切る命名規約が多いようです。
50. Branch を切り替える Branch の切り替えには checkout という操作を行います。 VS Code を使う場合でも checkout という名前は覚えましょう。 今は main ブランチにい る。クリックする VSCode の Git ア イコンをクリック 切り替わった
51. Branch を切り替える git graph 拡張機能を install していると Branch の切り替えはもっと簡単です。 今は main ブラン チにいる VSCode の Git ア イコンをクリック git graph アイコン をクリック 切り替え先の Branch 名をダブル クリック 切り替わった 切り替えた後にリフ レッシュが必要場合が ある
52. Branch を削除する Branch の削除はとても簡単です。 Git Graph の画面で削除したい Branch を右クリックし、 Delete Branch をクリックします。
53. Merge
54. Merge 他の Branch を取り込むことを Merge と呼びます。次の図は FeatureA を main に取り込んでいます。 main FeatureA main FeatureA Merge した Commit Merge は大別すると次の2種類です。 1. Commit が必要な通常の Merge 2. Commit が不要な Fast Forward Merge 推奨されているのは 2. Fast Forward Merge ですが、 1. Commit が必要な通常の Merge を使うことで Fast Forward Merge が可能な状態に持っていく必要があります。詳細は後述します。 main FeatureA FeatureA main Fast Forward Merge
55. Merge Commit が必要な通常の Merge ができるようになることが Merge の第一歩です。 複数人で作業していると、同じファイルに対する編集をした結果 Conflict が発生して Merge に失敗することがよくあります。 この場合、 Merge コミットは失敗します。Git が Conflict したから Merge できない、というエラーメッセージを返します。 この場合はどうしたら良いでしょか。 誰かが同じファイル対し て編集した Commit
56. Merge Conflict が発生すると、 Git は Conflict が発生したファイル全てについて、 Conflict が発生した箇所をファイルに編集してど のように Conflict したのかがわかるようにします。 Git によって勝手にファイルが編集されている状態です。余計なマーキング（<<<<<<など）は全て削除して、全てのソースの Conflict を解消するように編集し、コミットします。 この時、他人が編集した内容と自分が編集した内容とどちらを採用するのかを自分一人で判断できることはほとんどありません。そのた め Conflict したファイルを編集した両者が集まって Conflict を解消しなければなりません。 ・・・ <<<<<<< HEAD Some Implements ・・・ ======= Fixed Bug ・・・ >>>>>>> FeatureA ・・・ file1 Conflict した箇所は、 <<<<<<< ブランチ名 と >>>>>>> ブランチ名 の間で示しています。 ======= より上が Merge 先 下が Merge 元です main ブランチのファ イルの内容 FeatureA ブランチの ファイルの内容
57. Merge Conflict を解消してコミットすると、このようなコミット履歴になります。Conflict がなかった場合とコミット履歴は同じ結果とな ります。 Git ではこのように ロックをする代わりに Merge 時に Conflict を解消する方法を採用しています。 ※ Fast Forward Merge については、「Git の仕組み」で解説します。 誰かが同じファイルの同 じ行に対して編集したコ ミット main FeatureA
58. Merge する それでは Merge してみましょう。 まず最初に Merge する必要がある状態を作ります。今回は Conflict する状態をわ ざと作ってそれを解決しましょう。 最初の状態は、file1, 2, 3 を追加して Commit した直後だとします。 （※ first commit には何もファイルが追加されない空 Commit です） main
59. Merge する main branchA branchA を作成します。 （作成後に branchA に移動していることを確認しましょう）
60. Merge する branchA で file1 を変更して Commit します。 続けて 同じ branchA で file2 を変更して Commit します。 main branchA
61. Merge する main に移動します。移動は Checkout 操作で移動します。 次に main で file2 を変更して Commit します。 branchA でも file2 をの2行目を変更しましたので、ここが Conflict す るはずです。 main branchA Conflict する はずの行
62. Merge する では branchA を main に Merge します。 方向が大事です。 main から branch A を merge したい場合は現在位置が main にいる必要があります。他の Branch の結 果を 自分の Branch に引っ張るイメージです。 自分が main にいることを確認したら、 メニューから ブランチのマージを選択します。 branchA を選択すれば merge を開始します。
63. Merge する main branchA 想定通り file2 が Conflict して merge に失敗します。 Conflict したファイルに競合箇所がマーキングされます。
64. Merge する main branchA Conflict を解消します。下図のように手で修正します。 Conflict の解消は手動で行うしかありません。
65. Merge する main branchA Conflict を解消した ファイルを Stage します。
66. Merge する main branchA Git は デフォルトで Commit メッセージを入れてくれています （ Merge branch ‘branchA’ ）が、必要なら変更して Commit します。
67. Merge する 今回は わざと Conflict させて Merge しました。実業務においても Conflict を解消する時はほぼ間違いなく Conflict する ことがわかっている場合だけです。 想定外に Conflict が発生してびっくりした時には不用意に Merge 操作したことを後悔してしまいます。 でも大丈夫、 Merge は取り消すことができます。現在位置の Commit を右クリックして Reset current branch to this Commit…をクリックします。 ダイアログの右側の▽をク リックして Hard を選択しま す。 Yes, reset をクリックすれば merge 操作は取り消され ます。
68. Conflict が発生しなかったら？ Git の merge は大変良くできていて、基本的には自動的に merge してくれます。そのため、 Conflict せずに merge が完了することもよくあります。 VS Code を使って merge する時に注意したいのは、Commit メッセージが自動的に デフォルトのものが使用される、ということ です。 残念ながらこのデフォルト Commit メッセージを事前に変更して Commit する手段が VS Code にはありません。 もし Commit メッセージを変更したい場合は、コマンドを使って merge する か、もしくは Commit した後に Commit メッセージを変更します。 Commit 後の Commit メッセージの変更方法は「よくあるトラブルへの対 応」の「 Commit し忘れたファイルがあった」を参照してください。 事前に変更できない！
69. Git の仕組み The structure of Git
70. Git の Key-Value ストア Git を使いこなせるようになるためには、裏側の仕組みを知るのが一番早いです。仕組みを見てみましょう。 まずはリポジトリを覗いてみましょう。Git のリポジトリは .git フォルダです。ここに Commit や Branch など、リポジトリの全てのデータが存 在しています。そして知っておくべきことは、Commit に関するデータは全てこのフォルダに存在している Key-Value ストアに格納されてい ることです。
71. Commit の正体 objects フォルダを覗いてみましょう。ここが Key-Value ストアです。 Commit Id を ファイル名、つまりKey にした Key-Valueストアであることがわ かります。 では、このファイルの中身は どうなっているのでしょうか。 フォルダ名である2桁の英数字は、 Commit Id の先頭2桁です。 この Commit Log は下図の通りだったとします。0f フォルダを開いてみます。 先頭に0fを付けると Commit Id になる
72. Commit の正体 Key-Value ストアの Value の中身を参照するには、cat-file コマンドを叩きます。Commit Id に対してコマンドを使用するとこのような結 果でした。 PS C:¥gitroot¥gittest> git cat-file -p 0fa4b16 tree 2cb74afbdb58bd2586598ac3ba4a442e226d5f55 parent 795fba818d53c0d306f9e11bf255b83969fb3824 author takashi uesaka <takashi.uesaka@microsoft.com> 1614420544 +0900 committer takashi uesaka <takashi.uesaka@microsoft.com> 1614420544 +0900 change file1, 2 parent というのは 親 Commit の Id のことです。Commit 間の参照はこのように Value の中に 親の Commit の Id を持つことで構成 されています。しかし、肝心の Commit したファイルはどこにいったのでしょうか。tree という謎の Id があります。 この tree にも Id があるようです。同様に cat-file コマンドを使用して Value も見てみましょう。 余談：SHA-1は40桁ですが、コマンド等 で使用する場合は最低4桁だけの指定で OK です。 Commit メッセージ
73. Commit の正体 tree という名前の付いた Id の Value 値を cat-file コマンドで参照すると、次の結果でした。 PS C:¥gitroot¥gittest> git cat-file -p 2cb74af 100644 blob 64f86f4330440f5cdc4f80342a8df3a2245908e9 file1.txt 100644 blob 7b9030e42c4a0d8f938756ec8b79b7e3c7ef95fd file2.txt 100644 blob 7613b1e354781671331bd43f4850e86898f86d65 file3.txt PS C:¥gitroot¥gittest> git cat-file -p 7b9030e hogehoge add new line in main 今度は blob という種類で file名が出てきました。 file2.txt の blob Id を cat-file コマンドで参照してみましょう。 ファイルの中身を参照することができました。このことから、blob という種類として Key-Value ストアに格納されているデータが、格納され ているファイルの実体であることがわかりました。 これらのことから、Git の構造が見えてきます。 ファイルの中身
74. Commit の正体 Commit の構造は下図のような tree 構造であることがわかります。このことから重要なことがわかります。 Commit という操作は Stage したファイルと、それ以外の変更されていないファイルへの参照もすべて保持したメタデータを作成すること なのです。つまり Commit は親 Commit との差分データではないのです。 さらにここから Stage の本当の意味がわかります。Staging という操作は新規・変更・削除されたファイルを blob として Key-Value へ 格納し、 tree object でまとめる作業なのです。（ Key-Value への格納は Commit 時ではない） Git のファイル構造 blob object commit object .git\objects b74afbdb58bd2586598ac3ba4a442e226d5f55 2c 0f a4b16b16af02d9516d13f67a18cab92e24f4e4 9030e42c4a0d8f938756ec8b79b7e3c7ef95fd 7b f86f4330440f5cdc4f80342a8df3a2245908e9 64 file1 file2 file3 tree object 13b1e354781671331bd43f4850e86898f86d65 76 commit object
75. 初回の特別な Commit Commit は必ず parent commit id を参照するようになっていることがわかりました。 ということは1番最初の Commit はどこも参照していない特別な Commit ということになります。 一般的な作法として、この1番最初の Commit は何もファイルを持たない空の Commit を作ります。 プロジェクトでは必ずこの空の Commit から始めるようにしましょう。 git commit --allow-empty -m “first commit” コマンドの場合（ stage するものがないのでいきなり Commit する） VS Code の場合
76. Branch の正体 次は Branch の正体を暴きます。 Branch は Key-Value ストアではなく、別のところにいます。refs\heads フォルダを覗いてみましょう。 branch 名のファイルが存在しています。ファイルをメモ帳で開いてみると・・・ メモ帳で開く ファイルの中には Id が書かれています。 この Id は Branch が指し示している Commit Id です。 これは何を意味しているのでしょうか。
77. Branch の正体 Branch とは Commit Id の別名、というのが Branch の正体なのです。そして Branch には１つだけルールがあります。それは 分岐した 枝の一番最後の Commit Id を持つ、というルールです。そのため Commit が増えると Branch はファイルの中身を最新の Commit Id に書き換えます。まとめると Branch とは 枝の一番最後の Commit Id の別名である、と説明できます。 Git で Branch の作成・削除が高速である理由もわかりました。1つの軽いファイルを扱うだけなので高速です。 Branch の正体がただのファイルだとわかると、Branch を気軽に作成・削除できますね。 main branchA branchAを切った直後の状態 （main ブランチと同じ Commit Id を参照している） それぞれのブラ ンチで Commit main branchA Commit が進んだ状態 （枝の最後の Commit を参照している） 書き換え 書き換え
78. Fast Forward Merge とは merge は Fast Forward Merge が推奨されています。これは実質的に merge していないので Conflict が発生しないからです。例え ば次のような Commit 履歴だったとします。 FeatureA を main に merge するとどうなるでしょうか。 main FeatureA 答えは main が FeatureA と同じ Commit を指し示すようになる、です。 Confilict していないので新しい Commit を作る必要があ りません。このような merge を Fast Forward Merge と呼びます。 main FeatureA ※ Fast Forward Merge の時にわざと Commit を作ることもできます。どこ で merge したのかを履歴として確実に残したい場合です。チーム開発の場 合は Commit を残すか残さないかをあらかじめ決めておくのがいいでしょう。
79. Checkout と HEAD Git では Checkout という操作を頻繁に使います。 ブランチを切り替える時に Checkout という操作を行います。 そのため Checkout とは ブランチを切り替えるためのもの、という説明をよく見かけますし、Branch の章では同じように説明しました。 説明として間違っているわけではありませんが、実は正しい理解ではありません。 Checkout は 本当はブランチの切り替え用のコマンドではないのです。 VS Code による main から branchA への Checkout Git コマンドによる main から branch A へのCheckout
80. Checkout と HEAD Checkout を正しく理解するためには HEAD について理解が必要です。 HEAD とは現在位置のことである、と Branch の章で説明しました。 Git のログを見ると、確かに HEAD と表現されています。VS Code の Extension である Git Graph では〇で示されています。
81. Checkout と HEAD HEAD の正体は実に簡単です。リポジトリ直下（ .git フォルダ）にその名もずばり HEAD というファイルがあります。メモ帳で開くと、な んと branch ファイルを指し示していました。 これを見ると、Git コマンドのログで表示されている HEAD -> main がそのままの意味であったことがわかります。 メモ帳で開く
82. Checkout と HEAD Branch と HEAD の関係性を下記のように図示するのが一般的です。 この表現は Git 公式ページと同じで、Git の本質をとらえている図であることがわかります。 main BranchA HEAD
83. Checkout と HEAD Checkout の話に戻ります。Checkout が Branch を切り替える操作ではないなら、一体なんでしょう。 Branch を切り替える時には Checkout とともにブランチ名を指定します。ところで Branch とは Commit Id の別名でしかなかったことを 思い出してください。 実際に Checkout する時にはブランチ名ではなく Commit Id を指定してもブランチを切り替えることができます。 では Checkout 時に古い Commit Id を指定するどうなると思いますか？ main FeatureA HEAD checkout FeatureA main FeatureA HEAD 通常の checkout main FeatureA HEAD checkout 5jdb2a6 Commit Id を指定した checkout 5jdb2a6
84. Checkout と HEAD 答えは「その Commit が行われた直後の状態に Commit を元に Workspace と Staging を復元する」です。 この時 HEAD は古い Commit Id を指し示すように書き換えられます。現在位置が古い Commit に変わったからです。 main FeatureA HEAD checkout 5jdb2a6 Commit Id を指定した checkout 5jdb2a6 main FeatureA HEAD 5jdb2a6 Checkout は、ブランチを切り替えるのではなく指定された Commit を元に Workspace と Staging を復元する操作なのです。ブランチ を切り替えることもできる、が正しい理解です。 古い Commit Id を Checkout する、というのは以前の実装を参照したり、全体を復元して何かをしたい場合です。頻繁にある操作で はありませんが、覚えておいて損はありません。
85. リモートリポジトリ
86. ローカルリポジトリとリモートリポジトリ リモートリポジトリにある他人のコミットをローカルリポジトリに取り込んだり、自分のコミット結果をリモートリポジトリに反映するには、ロー カルリポジトリにどこがリモート先なのかを教えるだけです。 リモート先のリポジトリは GitHub や Azure DevOps などの SaaS 製品である必要はありません。イントラ内に作成することもできますし、 なんなら自分のマシンの別フォルダをリモート先にすることも可能です。 ローカル リポジトリ リモート リポジトリ ローカル リポジトリ ローカル リポジトリ GitHub Azure DevOps 自分のマシン イントラ内サーバー リモート リポジトリ ローカル リポジトリ push pull push push push pull pull pull
87. リモートリポジトリを作る リモートリポジトリは自分の PC 内部に作ることができます。リモートリポジトリとのやり取りが不安な時は、 PC 内部にリモートリポジトリ を作ってテストするできます。 通常、リモートリポジトリは bare リポジトリという種類として初期化します。 bare リポジトリとは、ワークツリーを持たないリポジトリです。 ローカルリポジトリのように直接 Commit することはできず、他リポジトリからの反映リクエストのみを受け付けます。それ以外の機能は ローカルリポジトリと同じです。 bare リポジトリの作成は コマンドのみで可能です。オプション --bare をつけるだけです。 git init --bare bare リポジトリの名前は一般的に ～～.git とします。つまりここではフォルダ名を～～.git とします。
88. リモートリポジトリと紐づける ローカルリポジトリをリモートリポジトリと紐づけることで、リポジトリ間で同期できるようになります。 ローカルリポジトリとして localRepo1 というフォルダを C:\gitroot 配下に作成し、リポジトリとして初期化した、とします。VS Code でリ モートと紐づけができます。 パスを指定 一般的にリモート先 の名前には origin とつける リモートリポジトリの確認はコマンドでしかできません。 git remote -v
89. 作業結果をリモートリポジトリへ反映する ローカルで作業した結果をリモートリポジトリへ反映するには、 Push という操作をします。 file1.txt を作って Commit したとします。 file1.txt を commit した直後
90. 作業結果をリモートリポジトリへ反映する このダイアログのメッセージが意味するのは、ローカルの main ブランチ と リ モートの main ブランチが紐づいていないことを意味しています。一度紐づ けると、2回目の Push からはこの確認ダイアログは表示されなくなります。 OKをクリックして紐 づける リモートのmainがこ の Commit を指し ている 反映実行
91. リモートリポジトリから最新を取得する リモートリポジトリから最新の状態を取得するには fetch 操作を行います。 新しくローカルリポジトリを作成して、 fetch してみましょう。C:\gitroot 配下に localRepo2 フォルダを作って Git リポジトリとして初期化 し、リモート先として ../remoteRepo.git を名称 origin として登録します。 Git リポジトリとして 初期化し、Remote 登録済み
92. リモートリポジトリから最新を取得する 全くログが無い状態で fetch した場合、その結果は残念ながら VS Code では見ることができません。 git branch コマンドに --all オプション（省略形は -a）をつけて 全 Branch を見てみます。 remotes/origin/main という Branch が存在していることがわかります。 この Branch はリモートブランチと呼ばれます。名前が示す通り、リモート先の Branch の内容を保持しています。隠し Branch と言っても いいでしょう。このリモートブランチは Commit ができないだけで基本的に通常の Branch と同じように扱うことできます。 fetch を行うとこのようにリモート先の内容をリモートブランチに取得することができます。 git branch --all
93. リモートリポジトリから最新を取得する fetch のイメージを図示しました。fetch 操作はリモートリポジトリの最新の状態を隠れ Branch （リモートブランチ）に反映することで す。 main main remotes/origin/main リモートリポジトリ ローカルリポジトリ リモートブラ ンチ main remotes/origin/main ローカルリポジトリ リモートから取得 した最新の Commit fetch 影響なし main remotes/origin/main ローカルに履歴が ない場合 ローカルに履歴が ある場合 （fetchしたことが ある） ローカルブラン チは作成され ない リモートリポジトリ ローカルリポジトリ ローカルリポジトリ
94. リモートリポジトリから最新を取得する リモートリポジトリの Branch を ローカルの Branch として扱うには、Branch の切り替えコマンドである checkout を使います。 checkout は Branch を切り替える操作ですが、リモートの Branch に対して行った時は特別な動きをします。 checkout は リモートブランチ をもとにローカルの Branch を作成するのです。 Commit 履歴を見ることがで きるようになり、最新の Commit が行われた直後の 状態に復元された （file1.txt が存在する） ローカルの main Branch と、リモートの main Branch の両方が 存在するようになった VS Code の場合 コマンドの場合
95. リモートリポジトリと紐づけと反映を同時に ローカルリポジトリとリモートリポジトリの紐づけからローカルでの作業開始までは次の手順になります。 1. ローカルリポジトリを作成する 2. リモートを登録する 3. fetch する 4. checkout する C:\ gitroot フォルダに 新しく localRepo3 フォルダを作ります。VS Code でフォルダを開いたらコマンドパレットで git clone と入力して、 選択します。 手順が多くて面倒です。これを1発で行う操作が clone です。
96. リモートリポジトリと紐づけと反映を同時に プロンプトにリモートリポジトリの Path を入力します。すると エクスプローラが自動的に立ち上がり、フォルダを指定することを求められま す。このフォルダにリポジトリ（フォルダ）を作成することになります。 リモートリポジトリの Path を指定 ローカルリポジトリを作成 するフォルダを指定
97. リモートリポジトリと紐づけと反映を同時に 指定したフォルダの配下に、リモートリポジトリ名でフォルダ（リポジトリ）が作成されます。 もちろん、入れ子になってしまっても問題なく動作します。 Clone の場合、このようにリモートリポジトリ名でフォルダを自動的に作成してしまうため、必要であればフォルダをリネームしたり、.中身を git フォルダ（隠しファイル）ごと移動することになります。 そこだけ注意すれば、clone は大変便利なコマンドです。GitHub や Azure Repos などの SaaS 製品のリモートリポジトリを使用する時 は clone してからスタートすることが多いです。 入れ子になってし まった
98. Pull を使う clone はローカルリポジトリを作成しますので、作業開始の初回にしか使えません。 リモートの最新の状態を取得するには、fetch ではなく pull という操作を使うことも多いです。 fetch 操作ではリモートの最新の状態をリモートブランチにコピーするだけでした。リモートブランチの最新の状態をローカルブランチへ反映す るには自分で merge しなければなりません。 main main remotes/origin /main リモートブラ ンチ main remotes/origin/ main リモートから取得 した最新の Commit fetch リモートリポジトリ ローカルリポジトリ ローカルリポジトリ merge
99. Pull を使う fetch 操作を行う時は ローカルブランチへ merge することがほとんどです。それなのに毎回 fetch, merge を行うのは面倒なので、fetch + merge を連続で行ってくれるコマンドが pull です。 pull 操作の結果は当然 fetch + merge と同じになります。 注意しなければいけないのは自動的に merge 操作が行われるため、ローカ ルブランチとリモートブランチで conflict を起こす可能性があることです。conflict を起こしそうな場合は fetch を行って様子をみてください。 main main remotes/origin /main リモートブラ ンチ main remotes/origin/ main リモートから取得 した最新の Commit pull リモートリポジトリ ローカルリポジトリ ローカルリポジトリ
100. Git の branch 戦略 The branch strategy of Git
101. 複数の Git の Branch 戦略 Git はその Branch の手軽さから Branch が乱立するという弊害も産み出します。2021年現在、様々な Git Branch 戦略が存在して います。どの戦略を採用するのかはプロジェクト次第です。 また、戦略はそのまま使用するのではなく、必要に応じてカスタマイズしていくのが良いでしょう。残念ながら銀の弾丸はありません。以下 に代表的な Git Branch 戦略をあげます。 ⚫ Git Flow 2010年に Vincent Driessen 氏によって提唱された Branch 戦略です。 ⚫ GitHub Flow GitHub の創業者 Scott Chacon が2011年にブログで発表した Branch 戦略です。 ⚫ GitLab Flow GitHub と双璧をなす Git の SaaS である GitLab が提唱する Branch 戦略です。 ⚫ Git Feature Flow カスタマイズの例です。GitHub Flow がベースのようです。
102. Git Flow 2010年に Vincent Driessen 氏によって提唱された Branch 戦略です。 • develop ブランチを中心に開発します。 • 機能単位に develop から feature branches を作ります。開発が終わったら develop へ merge します。（※ Fast Forward Merge 可能な場合でも空 Commit 作成） • リリースが決まったら develop を release branches へ merge し、リリースに必要なもの（リリー スノートなど）を追加します。 • release branches から master へ merge したものがリリース済を意味します。必ず tag をつけ ます。 • バグが発見された場合は master から hotfixes へ ブランチを作成し、修正したら master へ merge してリリースします。 最も有名な Branch 戦略です。複雑な運用を求められます。運用をサポート するために Git には git flow コマンドが用意されています。 提唱者である Vincent 氏は2020年3月にブログで Git Flow は10年以上も 前の戦略であり、継続的インテグレーションには不向きである、と言及していま す。 複数バージョンを保持・公開する必要性がある場合（ライブラリや 公開API） や、機能開発のスタートとリリースまでの時間が開く場合、リリースとデプロイを 切り離した運用の時に向いています。 https://nvie.com/posts/a-successful-git-branching-model/
103. GitHub Flow main GitHub の創業者 Scott Chacon が2011年にブログで発表した Branch 戦略です。 • main から わかりやすい名称の開発用ブランチを作成して開発します。 • 開発用ブランチの作業内容は積極的に push します。（他人から作業内容が見える） • main への merge は pull request で行います。 • pull request でレビューが承認された場合のみ、 main へ merge します。 • main に merge された Commit はすぐに、もしくは数時間以内にはデプロイします。 main へ merge した Commit はすぐにデプロイすることからもわかる通り、継続的インテグレーション を行う場合に最適な Branch 戦略です。そのため実行中の本番ソースと、開発中のソースとの差分 が少ないのが特徴です。（バグの混入に気付きやすい）バグが発生した場合もすぐに 修正の上デ プロイします。リリース＝デプロイです。 人手によるテストだけでは時間がかかるため、自動テストがしっかりと作り込まれている必要がありま す。（テストは開発用ブランチで行います） pull request によるコードレビューが鍵であるため、レビューアに負担がかかります。 Webシステムや SaaSなど、古いバージョンを保持・公開する必要がない場合に向いています。 http://scottchacon.com/2011/08/31/github-flow.html
104. GitLab Flow https://docs.gitlab.com/ee/topics/gitlab_flow.html GitHub と双璧をなす Git の SaaS である GitLab が（恐らく）2014年に提唱した Branch 戦略です。 Git Flow の複雑さと GitHub Flow の検証プロセスの曖昧さを解消すべく、GitHub Flow をベースに３つの Branch 戦略 があります。プロダクションブランチと環境ブランチはステージングやテスト、本番環境など複数環境に対応しています。リリース ブランチは Git Flow のように複数バージョンを保持して・公開するするための戦略です。プロダクション・環境ブランチと組み合 わせることもできます。３つとも開発時には master から feature ブランチを作成し、 mater への merge は pull request で行います。 プロダクションブランチ 環境ブランチ リリースブランチ 環境増加
105. Git Feature Flow Branch 戦略はカスタマイズすることも多いです。この Branch 戦略は日本人の方がブログで発表したものです。 GitHub Flow をベースにしていることがわかります。有名だからとそのまま Branch 戦略を採用してもうまくいかないことが多いのが現実である ため、このように実績のある Branch 戦略をベースに状況に合わせてカスタマイズすることを検討してみましょう。 https://developers.gnavi.co.jp/entry/GitFeatureFlow/koyama