Git in Team

チームで使う git と GitHubのしくみ

Peoject Based Learning で使うことを念頭に作りました。
あまり詳しく使いこなす気がない(かもしれない)人向けです。

なぜ git なのか、差分の履歴を取るロジックの説明をしています。
GitHubがどのように使えるかとか。

翻訳プロジェクトでもこの資料を読んでもらうといいんじゃないかなと思っています。

Transcript

1. PBL用最低限説明資料 チームで使う と @kawaguti
2. git • 2005年、Linus Torvaldsが Linuxカーネル開発のために作成 • 現在の事実上の標準 特徴 • 完全な分散型アーキテクチャ • 軽量で高速なブランチ・マージ • データ整合性（SHA-1ハッシュ） • 非線形開発に最適化
3. Linux カーネル開発の課題 • 2002年まで、Linuxカーネル開発ではパッチとtarballでソー スコードを管理 • 世界中の数千人の開発者が協力する大規模プロジェクト • 既存のバージョン管理システムでは対応困難 BitKeeperの時代（2002-2005年） • 2002年、Linus TorvaldsはBitKeeperという商用の分散 バージョン管理システムを採用 • 無償ライセンスでLinuxコミュニティに提供されていた • しかし、2005年にライセンス問題が発生し、無償提供が終了 Gitの誕生（2005年4月） • BitKeeperが使えなくなり、代替ツールが急務に • 既存のオープンソースVCS（CVS、Subversionなど）では要件 を満たせない • Linus Torvalds自身が新しいシステムの開発を決断
4. システム 登場年 アーキテクチャ ライセンス 現在の状況 主な用途 VSS 1994年 集中型 商用 Microsoft 廃止 レガシーのみ CVS 1986年 集中型 OSS レガシー 保守のみ Subversion 2000年 集中型 OSS 一部で利用 特定用途 Perforce 1995年 集中型 商用 現役 ゲーム・大規模 Mercurial 2005年 分散型 OSS 縮小中 一部で利用 Git 2005年 分散型 OSS 業界標準 ほぼ全般 よく使われてきたバージョン管理ソフトウェアあれこれ
5. 分散型を支える技術的基盤 • コミットIDはコンテンツのハッシュ値で グローバルに一意: 各オブジェクト（コミット、ツリー、ブロブ）をSHA-1 ハッシュで識別。ハッシュ値により、異なるリポジトリ間 でも衝突せずにコミットを識別可能 • 中央サーバー不要: リビジョン番号ではなくハッシュを使うため、各リポジ トリが独立して動作 • データ整合性: コンテンツが変更されるとハッシュも変わるため、改ざ ん検出が容易 • 参照の仕組み: ブランチやタグは単なるハッシュへのポインタ（軽量）
6. GitHub (サービス名であり企業名) • 2008年4月にサービス開始 • Gitリポジトリのホスティングサービス • 2018年にMicrosoftが75億ドルで買収 主な機能 • リモートリポジトリのホスティング • Pull Request（プルリクエスト）によるコードレビュー • Issue（課題管理） • GitHub Actions（CI/CD） • GitHub Pages（静的サイトホスティング） • プロジェクト管理ツール • ソーシャル機能（Star、Fork、Follow）
7. 1. Git普及の立役者 • GitをWebブラウザで簡単に利用可能に • 個人開発者が無料で利用できる • 視覚的なインターフェースで学習コストを低減 2. オープンソース文化の変革 • Forkとプルリクエストによる貢献の民主化 • 誰でも簡単にプロジェクトに貢献可能 • オープンソースプロジェクトの爆発的増加 3. 開発ワークフローの標準化 • 「GitHubフロー」の確立 • プルリクエストベースの開発が標準に • コードレビュー文化の浸透 4. 開発者のポートフォリオ • GitHubプロフィールが開発者の履歴書に • Contribution Graphによる活動の可視化 • 採用活動での重要指標
8. GitHub.com は gitを使って プロジェクトをホストするウェブ サービス gitはバージョン管理を 実現するソフトウェア
9. 世界中の開発者が、GitHubを 通じて世界にソフトウェアを共有 している。 開発者は、gitを使って それらをローカルに持っ てくることができる。
10. ここから進む前に サインアップしてアカウント作ってください。 https://github.com/git-guides/install-git パソコンに git をインストールしてください。
11. git のインストール方法 Windows 1.Git for Windows インストーラーを使用 1.最新版のインストーラーをダウンロード 2.セットアップウィザードの指示に従ってインス トール 3.コマンドプロンプトまたは Git Bash で git version を実行して確認 2.GitHub Desktop をインストール（Git も同時にイ ンストールされる） 3.Visual Studio Code 経由でインストール 1.GitHub Pull Requests and Issues 拡張機能を インストール https://github.com/git-guides/install-git
12. git のインストール方法 Mac ターミナルで確認： > git version （多くの Mac には既にインストール済み） macOS Git Installer を使用 →最新版のインストーラーをダウンロードして実行 Homebrew を使用 →ターミナルで brew install git を実行git version で確認 https://github.com/git-guides/install-git
13. git のインストール方法 Linux Debian/Ubuntu bash > sudo apt-get update > sudo apt-get install git-all > git version # 確認 Fedora Bash > sudo dnf install git-all > git version # 確認 https://github.com/git-guides/install-git
14. https://code.visualstudio.com/download VSCode 現在の標準的な開発環境なので、使ったことが ない人はぜひこの機会に入れてください。 (あえて他のを使ってる人はそのままで大丈夫！)
15. https://docs.github.com/ja/repositories 公式 ドキュメント がおすすめ
16. リポジトリをクローンする GitHub にあるリポジトリをローカルに 持ってくるのがクローンです。手元のコ ンピューター上にローカルコピーを作成 し、ローカルとリモートとの間で同期す ることができます。
17. リポジトリ リポジトリ > git clone xxxxxxxx(URL)
18. リポジトリ リポジトリ > Git clone xxxxxxxx(URL) リポジトリをクローンすると、 その時点で GitHub.com にあるすべてのリポジトリ データの完全なコピーがプ ルダウンされます。これには、 プロジェクトのすべてのファ イルとフォルダーのすべての バージョンも含まれます。 https://docs.github.com/ja/repositories/creating -and-managing-repositories/cloning-a- repository
19. Remote リポジトリ リポジトリ Local 全てローカルにコピーされてる 連携している
20. リポジトリ Local 一致！ 実体は .git フォルダの中に 格納されてます 作業フォルダに 展開されている 実ファイル ※この時点で実は２か所にファイルが格納さ れています。なので、作業フォルダのファイル を消しても復旧できます。安心！ 作業フォルダ
21. ローカルで改変する ローカルのプロジェクトのファイルを書 き換えると、リモートと同期しているロー カルのリポジトリとの間に差分が生じま す。 リポジトリ Local 一致！ 作業フォルダ
22. リポジトリ Local 変更済 ズレた！ 変更を加える ↓ 作業フォルダ VSCode diff!
23. リポジトリ Local 変更済 ズレた！ 変更を加える ↓ 作業フォルダ VSCode 差分 difference 変更したり、意図せず変 わった部分のことを 差分(diff)といいます。 差分を追跡・管理するの がバージョン管理です。 変更管理ともいわれる。 diff!
24. リポジトリ Local 変更済 ローカルでコミットする ローカルの作業フォルダにあるファイル をコミットすると、ローカルリポジトリに 変更差分が記録されます。 一致！ 変更済 > git commit
25. リポジトリ Local 追加！ 新規にファイルをつくる 新たなファイルをgit管理下に置く場合 は、git add コマンドを利用して リポジトリに登録し、commitします。 一致！ 追加！ > git add ファイル名 > git commit
26. リポジトリには履歴が記録される リポジトリは、最新のファイルのバックアップだけでなく、 これまでの変更履歴がすべて残っています。 リポジトリ Local 変更済 差分の履歴 ※つまり、コミットしてあれば、 どの状態にも戻せます。 commit commit commit commit
27. リポジトリ Local 変更済 一致！ 変更済 > git commit コミットメッセージ 変更をコミットするときには、コミットメッセージ を入力します。なにを書き換えたのか、 その意図を未来の自分や他者に明示します。 差分と一緒にgitリポジトリに格納されるので 真面目に書きましょう。
28. リポジトリ Local 変更済 リモートにプッシュする ローカルのリポジトリの変更 履歴をリモートに反映します。 一致！ 変更済 > git push Remote リポジトリ 変更済
29. リポジトリの履歴差分が反映される プッシュすると、リモートからクローンした履歴に 対して、ローカルで加えた変更差分(の履歴)が、 リモートに反映されます。 差分の履歴 commit commit commit commit 差分の履歴 clone push commit commit commit commit 変更済
30. リポジトリ Local リモートからプルする 最新のリモートリポジトリの 変更履歴をローカルに反映し ます。(作業フォルダも更新) > git pull Remote リポジトリ
31. リポジトリの履歴差分が反映される プルすると、以前リモートからクローン/プルした 履歴に対して、追加の差分履歴が、 ローカルに反映されます。 差分の履歴 commit commit commit commit 差分の履歴 pull commit commit commit commit 変更済 以前の clone/pull
32. 履歴が異なっていると反映できない 差分の履歴なので、差分の元が一致していない と、反映できないようになってます。 差分の履歴 commit commit commit commit 差分の履歴 push commit commit commit
33. プルして、履歴を一致させてからプッシュ 履歴が不一致になったときは、他の誰かや別のパソ コンからpushされて、リモートが更新されている可 能性が高いので、それをpullしてからpushします。 差分の履歴 commit commit commit commit 差分の履歴 push commit commit commit pull commit
34. 履歴とローカルの作業ファイルが衝突！ リモートで別の変更が入ってしまっているときに、 同じファイルをローカルで変更していると、 コンフリクト(衝突)として検知されます。 差分の履歴 commit commit commit commit 差分の履歴 push commit commit commit pull commit 変更済 別の変更 ズレた！ diff!
35. コンフリクトしたら、マージする コンフリクト(衝突)が起きたら、 ファイルごとにマージ(結合)を行います。 変更済 別の変更 ズレた！ diff! VSCode 別の変更 変更済 作業ファイル どの変更を 最新版 とするかを 行ごとに 決めていく マージ作業 コンフリクト
36. マージしたら、それをコミットしてプッシュ マージ(結合)を行って、最新版を確定させたら、 それをローカルにコミットすると、リモートにプッシュ できるようになります。 差分の履歴 commit commit commit commit 差分の履歴 push commit commit commit pull commit マージして 最新版を 確定！
37. 複数人で作業するとコンフリクトする 同じファイルを複数人で同時に編集すると、 コンフリクトが起こりやすくなります。 commit commit pull commit commit commit commit 変更済 変更済 いずれコンフリクトする
38. いろんな人がコミットして変更履歴を 積み上げていきます。 commit commit commit commit
39. ちなみに、この変更履歴には番号をつけて ます。git以前に主流だったSubversion では、リビジョン番号といって、数字を加算 していました。 commit commit commit commit r:100 r:101 r:102 r:103 リビジョン番号→
40. しかし、gitでは多くの人が同時並行で 作業することを念頭に置いています。 commit commit commit commit r:102 私も r:102 だと思ってる r:100 r:101
41. なので、リビジョン「番号」ではなく、 SHA-1ハッシュ値を使うことにしました。 commit commit commit commit r:2b8.. r:d9c.. r:a3c.. r:f7e.. a3c5f8e9d2 b7c1a4f6e8 d9b2c7a1f4 e6d8b9c2a7 f7e3d9c5b8 a2f1e4d7c9 b5a8f2e1d6 c8b4a7f3e9 d9c6f3a8e2 b7f1d4c8a5 e9b3f7d2a6 c9e4b8f1d5 2b8f4e1a7d 3c9f6e2a5d 8b1f4c7e3a 9d6f2b5e8c
42. 各コミットは自分のSHA-1ハッシュ値と、 変更元(親)のSHA-1ハッシュ値を記録 しています。 commit commit commit commit r:2b8.. r:d9c.. r:a3c.. r:f7e.. 親は r:a3c.. 親は r:f7e.. 親は r:f7e..
43. 履歴が異なっていると反映できない つまり、親が一致していないとプッシュできない、 というわけです。 差分の履歴 commit commit commit 差分の履歴 push commit commit commit r:2b8.. r:a3c.. r:f7e.. 親は r:a3c.. r:a3c.. r:f7e.. 親は r:a3c.. 親は r:f7e.. 親は r:f7e.. 親が r:2b8.. じゃないので
44. 親は r:f7e.. マージしたら、それをコミットしてプッシュ まずプルを行い、その上でマージして、コミットする ことで、親のSHA-1ハッシュ値が一致するので、 プッシュできるようになります。 差分の履歴 commit commit commit commit 差分の履歴 push commit commit commit pull commit r:2b8.. r:a3c.. r:f7e.. 親は r:a3c.. r:a3c.. r:f7e.. 親は r:a3c.. 親は r:f7e.. 親は r:2b8.. r:2b8.. r:d9c..
45. GitHubでは先頭7文字で表記 となりのSHA-1ハッシュと全然違うものになるので、 一般的には先頭7文字で表記することも多いです。 commit commit commit commit 差分の履歴 r:2b8.. r:a3c.. r:f7e.. a3c5f8e9d2 b7c1a4f6e8 d9b2c7a1f4 e6d8b9c2a7 a3c5f8e 先頭7文字で表記 することが多い SHA-1ハッシュ値 r:d9c..
46. SHA-1ハッシュ値の詳細 SHA-1（Secure Hash Algorithm 1）は、任意のデータ から160ビット（40桁の16進数）の固定長ハッシュ値を 生成する暗号学的ハッシュ関数。 • 完全なハッシュ: a3c5f8e9d2b7c1d4f6e8d9b2c7a1f4e6d8b9c2a7（40文字） • 短縮表示: a3c5f8e（通常7文字、GitHubなどで使用） SHA-1の特性 • 一方向性: ハッシュ値から元データを復元できない • 決定性: 同じ入力は必ず同じハッシュ値になる • 雪崩効果: わずかな変更で全く異なるハッシュ値になる • 衝突耐性: 異なる入力が同じハッシュになる確率は極め て低い（理論上は2^80の計算で衝突可能） 米国標準技術研究所 で策定された標準規格 です
47. GitHubにプッシュしてみよう GitHubリポジトリのREADME.md を編集して、 自分のチームの名前を書き加えてみましょう。 Clone/Pullして、編集して、Commitして、Pushし ます。 README.md README.md Clone/Pull Push 修正 Commit
48. 複数チームで同時に編集するとコンフリクト 他チームが同時に編集することでコンフリクトしたら、 Pullして、マージして、Pushしましょう。 相手チームとコミュニケーションすることも忘れずに。 変更済 別の変更 ズレた！ diff! VSCode 別の変更 変更済 作業ファイル どの変更を 最新版 とするかを 行ごとに 決めていく マージ作業 コンフリクト
49. git と GitHub の関係 git（バージョン管理システム） • 2005年にLinus Torvaldsが開発 • 分散型バージョン管理システム • ローカルで完結する履歴管理 • SHA-1ハッシュによる識別 GitHub（ホスティングサービス） • 2008年にサービス開始 • gitリポジトリをクラウドで管理 • Pull Request、Issue、CI/CDなどの機能 • 開発者のソーシャルプラットフォーム 関係性: gitはツールそのもの、GitHubはgitを使いや すくするサービス ここまでのまとめ
50. Clone（クローン） リモートリポジトリをローカルに複製。 全履歴を含む完全なコピーを作成。 git clone https://github.com/username/repo.git 差分（Diff） 変更内容を確認。 コミット前に必ず確認する習慣が重要。 git diff (作業ディレクトリの変更) git diff –staged (ステージングエリアの変更) ここまでのまとめ
51. Push（プッシュ） ローカルのコミットをリモートに送信。 他のメンバーと変更を共有。 > git push origin main Pull（プル） リモートの最新変更をローカルに取り込む。 作業開始前に必ず実行。 > git pull origin main ※Pull = Fetch + Merge Fetch: リモートの変更を取得（まだマージしない） Merge: 取得した変更を現在のブランチに統合 ここまでのまとめ
52. 変更済 別の変更 ズレた！ diff! 別の変更 変更済 Merge（マージ） 同じファイルをいじっていない限りは、 Pullの際に、自動的に最新版が採用され てマージされる。 同じファイルをいじっている場合は、 コンフリクト(衝突)が起きるので、 ファイルごとに個別にマージを行い、 最新版を確定する。 マージが終わったらプッシュする。 ここまでのまとめ
53. ブランチ(分岐) 実は、gitリポジトリは、並行して作業できる複数 の界面を持つことができる。 ブランチといい、簡単に切り替えることができる。 commit commit commit commit commit r:2b8.. r:a3c.. r:f7e.. r:a3c.. r:f7e.. commit r:d9c.. main ブランチ development ブランチ
54. GitHubのブランチ(分岐) 同様に、GitHub も gitリポジトリであるので、 複数のブランチを持つことができる。 commit commit commit commit commit r:2b8.. r:a3c.. r:f7e.. r:a3c.. r:f7e.. commit r:d9c.. main ブランチ development ブランチ
55. mainブランチはプロダクトの本線 通例上、”main” という名前のブランチを、 そのリポジトリの本線と考えることになっています。 ※以前は master と呼ばれていた。subversion では trunk。 2020年にGitHubが既定値を変更し、main とした。 commit commit commit r:2b8.. r:a3c.. r:f7e.. main ブランチ
56. mainブランチをプルして作業開始 まずmainブランチをプルしてくる。 (他のブランチもコピーされる) commit commit r:a3c.. r:f7e.. main ブランチ commit commit r:a3c.. r:f7e.. main ブランチ pull
57. 作業ブランチにフォークする mainブランチを元に、引き継いで新しいブラン チを作って、そこで作業する。 commit commit r:a3c.. r:f7e.. main ブランチ commit commit r:a3c.. r:f7e.. main ブランチ pull commit commit r:a3c.. r:f7e.. 作業 ブランチ
58. 作業ブランチに変更を加える 作業ブランチ側で、編集を行っていきます。 できたらコミットします。(ローカルコミット) commit commit r:a3c.. r:f7e.. main ブランチ commit commit r:a3c.. r:f7e.. main ブランチ pull commit r:f7e.. 作業 ブランチ commit r:d9c..
59. mainブランチにマージする 作業ブランチで行った変更を、mainブランチに マージすることができます。コミット元のコミット が一致していれば、その先に継ぎ足されます。 commit commit r:a3c.. r:f7e.. main ブランチ commit r:f7e.. 作業 ブランチ commit r:d9c.. フォーク マージ commit r:d9c..
60. GitHubにpushする 作業ブランチからマージされた変更は、 親のコミットが一致していれば、GitHubに pushすることができます。(さっきのと同じ) commit commit r:a3c.. r:f7e.. main ブランチ commit r:d9c.. commit commit r:a3c.. r:f7e.. main ブランチ commit r:d9c.. push
61. 作業ブランチをpushすることもできる 作業ブランチをpushして、他の人に共有するこ ともできます。バックアップの意味もあります。 mainブランチは変更されません。安全！ commit commit r:a3c.. r:f7e.. main ブランチ commit commit r:a3c.. r:f7e.. main ブランチ pull commit r:f7e.. 作業 ブランチ commit r:d9c.. commit r:f7e.. commit r:d9c.. 作業 ブランチ push
62. GitHub上でマージする GitHub上にある作業ブランチから GitHub内でmainブランチにマージする こともできます。(コンフリクトがなければボタン一つ) commit commit r:a3c.. r:f7e.. 作業 ブランチ commit r:d9c.. commit commit r:a3c.. r:f7e.. main ブランチ commit r:d9c.. push
63. mainブランチ = プロダクトの本線 こうして少しずつmainブランチを 育てていきます。 commit commit commit r:2b8.. r:a3c.. r:f7e.. main ブランチ commit r:d9c..
64. 継続的インテグレーション/継続的デリバリー mainブランチが更新(push)されたら、 自動的に本番機にデプロイすることを、 継続的デリバリーと言います。 CI/CDとも呼ばれます。 commit r:2b8.. main ブランチ commit r:d9c.. デプロイ 本番機
65. コンティンジェンシー 継続的デリバリー(CI/CD)を実装していると、 最新版に不具合があった場合に、 すぐ一つ前の状態に戻すこともできます。 commit r:2b8.. main ブランチ commit r:d9c.. デプロイ 本番機
66. ＤＢマイグレーション 本番機にデータベースがあり、利用者が何か データを残す場合は、そのデータについても 移行を考える必要があります。 ※「100万円もらった！」というデータが消えたら悲しい。 commit r:2b8.. main ブランチ commit r:d9c.. デプロイ 本番機 データベース
67. GitHubにプルリクエストする mainブランチから、ローカルで行ったコミットを pullで結合することもできます。「pullしてね！」 という連絡のことをプルリクエスト、と言います。 commit commit r:a3c.. r:f7e.. main ブランチ commit r:d9c.. commit commit r:a3c.. r:f7e.. main ブランチ commit r:d9c.. pull
68. Pushするには権限がいる 直接 GitHubに push するには、GitHubのリ ポジトリ上に書き込む権限(コミット権)を持って いる必要があります。 commit commit r:a3c.. r:f7e.. main ブランチ commit r:d9c.. commit commit r:a3c.. r:f7e.. main ブランチ commit r:d9c.. push
69. プルリクエストは権限がなくてもできる プルリクエストの場合は、コミット権限がなくても 行うことができますが、そのプルリクエストを本線にマージ するかどうかは、権限を持ったコミッターが決めるのです。 commit commit r:a3c.. r:f7e.. main ブランチ commit r:d9c.. commit commit r:a3c.. r:f7e.. main ブランチ commit r:d9c.. pull 権限を持った コミッター ケン限 だけにね
70. プルリクエストは権限がなくてもできる プルリクエストの場合は、コミット権限がなくても 行うことができますが、そのプルリクエストを本線にマージ するかどうかは、権限を持ったコミッターが決めるのです。 commit commit r:a3c.. r:f7e.. main ブランチ commit r:d9c.. commit commit r:a3c.. r:f7e.. main ブランチ commit r:d9c.. pull 権限を持った コミッター ケン限 だけにね
71. GitHubにプルリクエストしてみよう GitHubリポジトリのindex.htmlを編集して、 自分のチームの名前を書き加えてみましょう。 Clone/Pullして、作業ブランチにForkします。 (ブランチ名は競合を避けるためにチーム名にしましょう。) 作業ブランチ上で編集して、Commitして、 作業ブランチをGitHubにPushします。 README.md README.md Clone/Pull Push 修正 Commit
72. GitHubにプルリクエストしてみよう GitHub上で作業ブランチを開いて、 プルリクエストを作成します。 プルリクエストは講師陣でマージするようにします。 README.md README.md Clone/Pull Push 修正 Commit
73. GitHub.com は gitを使って プロジェクトをホストするウェブ サービス gitはバージョン管理を 実現するソフトウェア
74. 世界中の開発者が、GitHubを 通じて世界にソフトウェアを共有 している。 開発者は、gitを使って それらをローカルに持っ てくることができる。
75. 世界中の開発者が、GitHubを 通じて世界にソフトウェアを共有 している。 開発者は、プルリクエストを 通じて、変更提案を行い、 手助けすることができる。 ケン限 だけにね