Git in Team

PBL用最低限説明資料チームで使うと @kawaguti

川口恭伸かわぐちやすのぶ Twitter: @kawaguti YesNoBut株式会社代表取締役社長アギレルゴコンサルティング株式会社シニアアジャイルコーチ
一般社団法人スクラムギャザリング東京実行委員会代表理事

GitHub.com は gitを使ってプロジェクトをホストするウェブサービス gitはバージョン管理を実現するソフトウェア

世界中の開発者が、GitHubを通じて世界にソフトウェアを共有している。開発者は、gitを使ってそれらをローカルに持ってくることができる。

git • 2005年、Linus Torvaldsが Linuxカーネル開発のために作成 • 現在の事実上の標準特徴 • 完全な分散型アーキテクチャ
• 軽量で高速なブランチ・マージ • データ整合性（SHA-1ハッシュ） • 非線形開発に最適化

Linux カーネル開発の課題 • 2002年まで、Linuxカーネル開発ではパッチとtarballでソースコードを管理 • 世界中の数千人の開発者が協力する大規模プロジェクト • 既存のバージョン管理システムでは対応困難 BitKeeperの時代（2002-2005年）
• 2002年、Linus TorvaldsはBitKeeperという商用の分散バージョン管理システムを採用 • 無償ライセンスでLinuxコミュニティに提供されていた • しかし、2005年にライセンス問題が発生し、無償提供が終了 Gitの誕生（2005年4月） • BitKeeperが使えなくなり、代替ツールが急務に • 既存のオープンソースVCS（CVS、Subversionなど）では要件を満たせない • Linus Torvalds自身が新しいシステムの開発を決断

システム登場年アーキテクチャライセンス現在の状況主な用途 VSS 1994年集中型商用
Microsoft 廃止レガシーのみ CVS 1986年集中型 OSS レガシー保守のみ Subversion 2000年集中型 OSS 一部で利用特定用途 Perforce 1995年集中型商用現役ゲーム・大規模 Mercurial 2005年分散型 OSS 縮小中一部で利用 Git 2005年分散型 OSS 業界標準ほぼ全般よく使われてきたバージョン管理ソフトウェアあれこれ

分散型を支える技術的基盤 • コミットIDはコンテンツのハッシュ値でグローバルに一意: 各オブジェクト（コミット、ツリー、ブロブ）をSHA-1 ハッシュで識別。ハッシュ値により、異なるリポジトリ間でも衝突せずにコミットを識別可能 • 中央サーバー不要: リビジョン番号ではなくハッシュを使うため、各リポジ
トリが独立して動作 • データ整合性: コンテンツが変更されるとハッシュも変わるため、改ざん検出が容易 • 参照の仕組み: ブランチやタグは単なるハッシュへのポインタ（軽量）

GitHub (サービス名であり企業名) • 2008年4月にサービス開始 • Gitリポジトリのホスティングサービス • 2018年にMicrosoftが75億ドルで買収主な機能 •
リモートリポジトリのホスティング • Pull Request（プルリクエスト）によるコードレビュー • Issue（課題管理） • GitHub Actions（CI/CD） • GitHub Pages（静的サイトホスティング） • プロジェクト管理ツール • ソーシャル機能（Star、Fork、Follow）

1. Git普及の立役者 • GitをWebブラウザで簡単に利用可能に • 個人開発者が無料で利用できる • 視覚的なインターフェースで学習コストを低減 2. オープンソース文化の変革
• Forkとプルリクエストによる貢献の民主化 • 誰でも簡単にプロジェクトに貢献可能 • オープンソースプロジェクトの爆発的増加 3. 開発ワークフローの標準化 • 「GitHubフロー」の確立 • プルリクエストベースの開発が標準に • コードレビュー文化の浸透 4. 開発者のポートフォリオ • GitHubプロフィールが開発者の履歴書に • Contribution Graphによる活動の可視化 • 採用活動での重要指標

ここから進む前に GitHub と git を準備します。サインアップしてアカウント作ってください。 https://github.com/git-guides/install-git パソコンに git をインストールしてください。

git のインストール方法 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 Windows

git のインストール方法ターミナルで確認： > git version （多くの Mac には既にインストール済み） macOS
Git Installer を使用 →最新版のインストーラーをダウンロードして実行 Homebrew を使用 →ターミナルで brew install git を実行git version で確認 https://github.com/git-guides/install-git Mac

git のインストール方法 Debian/Ubuntu > sudo apt-get update > sudo apt-get
install git-all > git version # 確認 Fedora > sudo dnf install git-all > git version # 確認 https://github.com/git-guides/install-git Linux

https://code.visualstudio.com/download VSCode 現在の標準的な開発環境なので、使ったことがない人はぜひこの機会に入れてください。 (あえて他のを使ってる人はそのままで大丈夫！)

https://docs.github.com/ja/repositories 公式ドキュメントがおすすめ

リポジトリをクローンする GitHub にあるリポジトリをローカルに持ってくるのがクローンです。手元のコンピューター上にローカルコピーを作成し、ローカルとリモートとの間で同期することができます。

リポジトリリポジトリ > git clone xxxxxxxx(URL) 認証の設定がちょっと面倒なので次のページで紹介します。

1. GitHub Desktopを起動初回起動時にサインインが求められます 2. GitHubアカウントでサインイン • File → Options
(Windows) / Preferences (macOS) • Accounts → Sign in をクリック • ブラウザでGitHubにサインイン • 認証を許可これでSSH鍵やPATの設定は不要です！クローン方法 GitHubのウェブサイトから 1.GitHubでリポジトリのページを開く 2.緑色の Code ボタンをクリック 3.Open with GitHub Desktop をクリック 4.GitHub Desktopが自動的に起動してクローン開始 GitHub Desktop をつかったクローン

SSH鍵ペアの生成 > ssh-keygen -t ed25519 -C "[email protected]" 実行すると以下の質問が表示されます: Enter file
in which to save the key (/Users/you/.ssh/id_ed25519): [Enterキーを押す] Enter passphrase (empty for no passphrase): [任意のパスフレーズまたは空Enter] Enter same passphrase again: [同じパスフレーズを再入力] これで以下のファイルが作成されます: ~/.ssh/id_ed25519 (秘密鍵) - 絶対に公開しない ~/.ssh/id_ed25519.pub (公開鍵) - GitHubに登録する SSH agentに秘密鍵を追加 > eval "$(ssh-agent -s)" ➢ ssh-add ~/.ssh/id_ed25519 SSH をつかったクローン 1.鍵の生成

公開鍵の内容を表示 cat ~/.ssh/id_ed25519.pub 表示された内容をコピーして、GitHubに登録 GitHub → Settings → SSH and
GPG keys New SSH key をクリック Title: 任意の名前（例: “MacBook Pro”） Key: コピーした公開鍵を貼り付け Add SSH key をクリック接続テスト > ssh -T [email protected] 成功すると以下のメッセージが表示されます Hi username! You've successfully authenticated, but GitHub does not provide shell access. クローン方法 (リポジトリURLは書き換えてください) > git clone [email protected]:username/repository.git SSH をつかったクローン 2.GitHubへの登録

Personal Access Token (PAT) の作成 1. GitHubでトークンを生成 GitHub → Settings
→ Developer settings Personal access tokens → Tokens (classic) Generate new token → Generate new token(classic) 2. トークンの設定 Note: トークンの説明（例: "Development MacBook"） Expiration: 有効期限を設定（推奨: 90 days） Select scopes: 必要な権限を選択 repo - リポジトリへのフルアクセス（必須） workflow - GitHub Actionsを使う場合 write:packages - パッケージを公開する場合 3. トークンをコピー重要: トークンは一度しか表示されません！必ず安全な場所に保存してください (パスワードマネージャーの利用を推奨) クローン方法 > git clone https://github.com/username/repository.git 認証情報を求められたら Username: your_username Password: [生成したPATを貼り付け] HTTPS + Personal Access Token (PAT) をつかったクローン

リポジトリリポジトリ > Git clone xxxxxxxx(URL) リポジトリをクローンすると、その時点で GitHub.com にあるすべてのリポジトリ
データの完全なコピーがプルダウンされます。これには、プロジェクトのすべてのファイルとフォルダーのすべてのバージョンも含まれます。 https://docs.github.com/ja/repositories/creating -and-managing-repositories/cloning-a- repository

Remote リポジトリリポジトリ Local 全てローカルにコピーされてる連携している

リポジトリ Local 一致！実体は .git フォルダの中に格納されてます作業フォルダに展開されている実ファイル
※この時点で実は２か所にファイルが格納されています。なので、作業フォルダのファイルを消しても復旧できます。安心！作業フォルダ

ローカルで改変するローカルのプロジェクトのファイルを書き換えると、リモートと同期しているローカルのリポジトリとの間に差分が生じます。リポジトリ Local 一致！作業フォルダ

リポジトリ Local 変更済ズレた！変更を加える ↓ 作業フォルダ VSCode diff!

リポジトリ Local 変更済ズレた！変更を加える ↓ 作業フォルダ VSCode 差分 difference
変更したり、意図せず変わった部分のことを差分(diff)といいます。差分を追跡・管理するのがバージョン管理です。変更管理ともいわれる。 diff!

リポジトリ Local 変更済ローカルでコミットするローカルの作業フォルダにあるファイルをコミットすると、ローカルリポジトリに変更差分が記録されます。一致！変更済 >
git commit

リポジトリ Local 追加！新規にファイルをつくる新たなファイルをgit管理下に置く場合は、git add コマンドを利用してリポジトリに登録し、commitします。一致！
追加！ > git add ファイル名 > git commit

リポジトリには履歴が記録されるリポジトリは、最新のファイルのバックアップだけでなく、これまでの変更履歴がすべて残っています。リポジトリ Local 変更済差分の履歴 ※つまり、コミットしてあれば、どの状態にも戻せます。 commit
commit commit commit

リポジトリ Local 変更済一致！変更済 > git commit コミットメッセージ変更をコミットするときには、コミットメッセージ
を入力します。なにを書き換えたのか、その意図を未来の自分や他者に明示します。差分と一緒にgitリポジトリに格納されるので真面目に書きましょう。

リポジトリ Local 変更済リモートにプッシュするローカルのリポジトリの変更履歴をリモートに反映します。一致！変更済 > git
push Remote リポジトリ変更済

リポジトリの履歴差分が反映されるプッシュすると、リモートからクローンした履歴に対して、ローカルで加えた変更差分(の履歴)が、リモートに反映されます。差分の履歴 commit commit commit commit 差分の履歴
clone push commit commit commit commit 変更済

リポジトリ Local リモートからプルする最新のリモートリポジトリの変更履歴をローカルに反映します。(作業フォルダも更新) > git pull Remote
リポジトリ

リポジトリの履歴差分が反映されるプルすると、以前リモートからクローン/プルした履歴に対して、追加の差分履歴が、ローカルに反映されます。差分の履歴 commit commit commit commit 差分の履歴
pull commit commit commit commit 変更済以前の clone/pull

履歴が異なっていると反映できない差分の履歴なので、差分の元が一致していないと、反映できないようになってます。差分の履歴 commit commit commit commit 差分の履歴 push
commit commit commit

プルして、履歴を一致させてからプッシュ履歴が不一致になったときは、他の誰かや別のパソコンからpushされて、リモートが更新されている可能性が高いので、それをpullしてからpushします。差分の履歴 commit commit commit commit 差分の履歴
push commit commit commit pull commit

履歴とローカルの作業ファイルが衝突！リモートで別の変更が入ってしまっているときに、同じファイルをローカルで変更していると、コンフリクト(衝突)として検知されます。差分の履歴 commit commit commit commit 差分の履歴
push commit commit commit pull commit 変更済別の変更ズレた！ diff!

コンフリクトしたら、マージするコンフリクト(衝突)が起きたら、ファイルごとにマージ(結合)を行います。変更済別の変更ズレた！ diff! VSCode 別の変更変更済
作業ファイルどの変更を最新版とするかを行ごとに決めていくマージ作業コンフリクト

マージしたら、それをコミットしてプッシュマージ(結合)を行って、最新版を確定させたら、それをローカルにコミットすると、リモートにプッシュできるようになります。差分の履歴 commit commit commit commit 差分の履歴
push commit commit commit pull commit マージして最新版を確定！

複数人で作業するとコンフリクトする同じファイルを複数人で同時に編集すると、コンフリクトが起こりやすくなります。 commit commit pull commit commit commit commit
変更済変更済いずれコンフリクトする

いろんな人がコミットして変更履歴を積み上げていきます。 commit commit commit commit

ちなみに、この変更履歴には番号をつけてます。git以前に主流だったSubversion では、リビジョン番号といって、数字を加算していました。 commit commit commit commit r:100 r:101
r:102 r:103 リビジョン番号→

しかし、gitでは多くの人が同時並行で作業することを念頭に置いています。 commit commit commit commit r:102 私も r:102 だと思ってる
r:100 r:101

なので、リビジョン「番号」ではなく、 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

各コミットは自分のSHA-1ハッシュ値と、変更元(親)のSHA-1ハッシュ値を記録しています。 commit commit commit commit r:2b8.. r:d9c.. r:a3c..
r:f7e.. 親は r:a3c.. 親は r:f7e.. 親は r:f7e..

履歴が異なっていると反映できないつまり、親が一致していないとプッシュできない、というわけです。差分の履歴 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.. じゃないので

親は 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..

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..

SHA-1ハッシュ値の詳細 SHA-1（Secure Hash Algorithm 1）は、任意のデータから160ビット（40桁の16進数）の固定長ハッシュ値を生成する暗号学的ハッシュ関数。 • 完全なハッシュ: a3c5f8e9d2b7c1d4f6e8d9b2c7a1f4e6d8b9c2a7（40文字）
• 短縮表示: a3c5f8e（通常7文字、GitHubなどで使用） SHA-1の特性 • 一方向性: ハッシュ値から元データを復元できない • 決定性: 同じ入力は必ず同じハッシュ値になる • 雪崩効果: わずかな変更で全く異なるハッシュ値になる • 衝突耐性: 異なる入力が同じハッシュになる確率は極めて低い（理論上は2^80の計算で衝突可能）米国標準技術研究所で策定された標準規格です

GitHubにプッシュしてみよう GitHubリポジトリのREADME.md を編集して、自分のチームの名前を書き加えてみましょう。 Clone/Pullして、編集して、Commitして、Pushします。 README.md README.md Clone/Pull Push
修正 Commit

複数チームで同時に編集するとコンフリクト他チームが同時に編集することでコンフリクトしたら、 Pullして、マージして、Pushしましょう。相手チームとコミュニケーションすることも忘れずに。変更済別の変更ズレた！ diff! VSCode 別の変更
変更済作業ファイルどの変更を最新版とするかを行ごとに決めていくマージ作業コンフリクト

git と GitHub の関係 git（バージョン管理システム） • 2005年にLinus Torvaldsが開発 • 分散型バージョン管理システム
• ローカルで完結する履歴管理 • SHA-1ハッシュによる識別 GitHub（ホスティングサービス） • 2008年にサービス開始 • gitリポジトリをクラウドで管理 • Pull Request、Issue、CI/CDなどの機能 • 開発者のソーシャルプラットフォーム関係性: gitはツールそのもの、GitHubはgitを使いやすくするサービスここまでのまとめ

Clone（クローン）リモートリポジトリをローカルに複製。全履歴を含む完全なコピーを作成。 git clone https://github.com/username/repo.git 差分（Diff）変更内容を確認。コミット前に必ず確認する習慣が重要。 git
diff (作業ディレクトリの変更) git diff –staged (ステージングエリアの変更) ここまでのまとめ

Push（プッシュ）ローカルのコミットをリモートに送信。他のメンバーと変更を共有。 > git push origin main Pull（プル）リモートの最新変更をローカルに取り込む。
作業開始前に必ず実行。 > git pull origin main ※Pull = Fetch + Merge Fetch: リモートの変更を取得（まだマージしない） Merge: 取得した変更を現在のブランチに統合ここまでのまとめ

変更済別の変更ズレた！ diff! 別の変更変更済 Merge（マージ）同じファイルをいじっていない限りは、 Pullの際に、自動的に最新版が採用されてマージされる。
同じファイルをいじっている場合は、コンフリクト(衝突)が起きるので、ファイルごとに個別にマージを行い、最新版を確定する。マージが終わったらプッシュする。ここまでのまとめ

ブランチ(分岐) 実は、gitリポジトリは、並行して作業できる複数の界面を持つことができる。ブランチといい、簡単に切り替えることができる。 commit commit commit commit commit r:2b8..
r:a3c.. r:f7e.. r:a3c.. r:f7e.. commit r:d9c.. main ブランチ development ブランチ

GitHubのブランチ(分岐) 同様に、GitHub も gitリポジトリであるので、複数のブランチを持つことができる。 commit commit commit commit commit
r:2b8.. r:a3c.. r:f7e.. r:a3c.. r:f7e.. commit r:d9c.. main ブランチ development ブランチ

mainブランチはプロダクトの本線通例上、”main” という名前のブランチを、そのリポジトリの本線と考えることになっています。 ※以前は master と呼ばれていた。subversion では trunk。 2020年にGitHubが既定値を変更し、main
とした。 commit commit commit r:2b8.. r:a3c.. r:f7e.. main ブランチ

mainブランチをプルして作業開始まずmainブランチをプルしてくる。 (他のブランチもコピーされる) commit commit r:a3c.. r:f7e.. main ブランチ commit
commit r:a3c.. r:f7e.. main ブランチ pull

作業ブランチにフォークする mainブランチを元に、引き継いで新しいブランチを作って、そこで作業する。 commit commit r:a3c.. r:f7e.. main ブランチ commit
commit r:a3c.. r:f7e.. main ブランチ pull commit commit r:a3c.. r:f7e.. 作業ブランチ

作業ブランチに変更を加える作業ブランチ側で、編集を行っていきます。できたらコミットします。(ローカルコミット) commit commit r:a3c.. r:f7e.. main ブランチ commit
commit r:a3c.. r:f7e.. main ブランチ pull commit r:f7e.. 作業ブランチ commit r:d9c..

mainブランチにマージする作業ブランチで行った変更を、mainブランチにマージすることができます。コミット元のコミットが一致していれば、その先に継ぎ足されます。 commit commit r:a3c.. r:f7e.. main ブランチ
commit r:f7e.. 作業ブランチ commit r:d9c.. フォークマージ commit r:d9c..

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

作業ブランチを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

GitHub上でマージする GitHub上にある作業ブランチから GitHub内でmainブランチにマージすることもできます。(コンフリクトがなければボタン一つ) commit commit r:a3c.. r:f7e.. 作業ブランチ
commit r:d9c.. commit commit r:a3c.. r:f7e.. main ブランチ commit r:d9c.. push

mainブランチ = プロダクトの本線こうして少しずつmainブランチを育てていきます。 commit commit commit r:2b8.. r:a3c..
r:f7e.. main ブランチ commit r:d9c..

継続的インテグレーション/継続的デリバリー mainブランチが更新(push)されたら、自動的に本番機にデプロイすることを、継続的デリバリーと言います。 CI/CDとも呼ばれます。 commit r:2b8.. main ブランチ commit
r:d9c.. デプロイ本番機

コンティンジェンシー継続的デリバリー(CI/CD)を実装していると、最新版に不具合があった場合に、すぐ一つ前の状態に戻すこともできます。 commit r:2b8.. main ブランチ commit r:d9c..
デプロイ本番機

ＤＢマイグレーション本番機にデータベースがあり、利用者が何かデータを残す場合は、そのデータについても移行を考える必要があります。 ※「100万円もらった！」というデータが消えたら悲しい。 commit r:2b8.. main ブランチ commit
r:d9c.. デプロイ本番機データベース

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

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

プルリクエストは権限がなくてもできるプルリクエストの場合は、コミット権限がなくても行うことができますが、そのプルリクエストを本線にマージするかどうかは、権限を持ったコミッターが決めるのです。 commit commit r:a3c.. r:f7e.. main ブランチ
commit r:d9c.. commit commit r:a3c.. r:f7e.. main ブランチ commit r:d9c.. pull 権限を持ったコミッターケン限だけにね

GitHubにプルリクエストしてみよう GitHubリポジトリのindex.htmlを編集して、自分のチームの名前を書き加えてみましょう。 Clone/Pullして、作業ブランチにForkします。 (ブランチ名は競合を避けるためにチーム名にしましょう。) 作業ブランチ上で編集して、Commitして、作業ブランチをGitHubにPushします。 README.md README.md Clone/Pull
Push 修正 Commit

GitHubにプルリクエストしてみよう GitHub上で作業ブランチを開いて、プルリクエストを作成します。プルリクエストは講師陣でマージするようにします。 README.md README.md Clone/Pull Push 修正 Commit

世界中の開発者が、GitHubを通じて世界にソフトウェアを共有している。開発者は、プルリクエストを通じて、変更提案を行い、手助けすることができる。ケン限だけにね

Git in Team

Git in Team

More Decks by Yasunobu Kawaguchi

Other Decks in Technology

Featured

Transcript