Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Git in Team

Git in Team

チームで使うgitとGitHub - PBL用最低限説明資料
この資料は、チーム開発でgitとGitHubを使い始める方のための入門スライドです。

gitとGitHubの基礎
- gitの歴史と特徴(Linus Torvaldsによる開発、SHA-1ハッシュによる分散型アーキテクチャ)
- GitHubの役割と主要機能(リポジトリホスティング、Pull Request、Issue管理など)

基本的なワークフロー
- Clone: リモートリポジトリをローカルに複製
- Commit: ローカルでの変更を記録
- Push/Pull: リモートとローカルの同期
- Merge: 変更の統合とコンフリクト解決

ブランチ
- mainブランチ(本線)の概念
- 作業ブランチでの開発
- Pull Requestを使ったコードレビューフロー

実践的なトピック
- コンフリクト(衝突)の解決方法
- CI/CD(継続的インテグレーション/デリバリー)の基礎
- データベースマイグレーションが必要になるとき

対象者
- チーム開発を始める学生・初学者
- PBL(Project-Based Learning)でgit/GitHubを使う方
- バージョン管理の基本を学びたい方

セットアップ
資料内で以下のツールのインストール方法を紹介しています:
- Git(Windows/Mac/Linux)
- GitHub Desktop
- Visual Studio Code

Avatar for Yasunobu Kawaguchi

Yasunobu Kawaguchi PRO

October 09, 2025
Tweet

More Decks by Yasunobu Kawaguchi

Other Decks in Technology

Transcript

  1. git • 2005年、Linus Torvaldsが Linuxカーネル開発のために作成 • 現在の事実上の標準 特徴 • 完全な分散型アーキテクチャ

    • 軽量で高速なブランチ・マージ • データ整合性(SHA-1ハッシュ) • 非線形開発に最適化
  2. Linux カーネル開発の課題 • 2002年まで、Linuxカーネル開発ではパッチとtarballでソー スコードを管理 • 世界中の数千人の開発者が協力する大規模プロジェクト • 既存のバージョン管理システムでは対応困難 BitKeeperの時代(2002-2005年)

    • 2002年、Linus TorvaldsはBitKeeperという商用の分散 バージョン管理システムを採用 • 無償ライセンスでLinuxコミュニティに提供されていた • しかし、2005年にライセンス問題が発生し、無償提供が終了 Gitの誕生(2005年4月) • BitKeeperが使えなくなり、代替ツールが急務に • 既存のオープンソースVCS(CVS、Subversionなど)では要件 を満たせない • Linus Torvalds自身が新しいシステムの開発を決断
  3. システム 登場年 アーキテクチャ ライセンス 現在の状況 主な用途 VSS 1994年 集中型 商用

    Microsoft 廃止 レガシーのみ CVS 1986年 集中型 OSS レガシー 保守のみ Subversion 2000年 集中型 OSS 一部で利用 特定用途 Perforce 1995年 集中型 商用 現役 ゲーム・大規模 Mercurial 2005年 分散型 OSS 縮小中 一部で利用 Git 2005年 分散型 OSS 業界標準 ほぼ全般 よく使われてきたバージョン管理ソフトウェアあれこれ
  4. GitHub (サービス名であり企業名) • 2008年4月にサービス開始 • Gitリポジトリのホスティングサービス • 2018年にMicrosoftが75億ドルで買収 主な機能 •

    リモートリポジトリのホスティング • Pull Request(プルリクエスト)によるコードレビュー • Issue(課題管理) • GitHub Actions(CI/CD) • GitHub Pages(静的サイトホスティング) • プロジェクト管理ツール • ソーシャル機能(Star、Fork、Follow)
  5. 1. Git普及の立役者 • GitをWebブラウザで簡単に利用可能に • 個人開発者が無料で利用できる • 視覚的なインターフェースで学習コストを低減 2. オープンソース文化の変革

    • Forkとプルリクエストによる貢献の民主化 • 誰でも簡単にプロジェクトに貢献可能 • オープンソースプロジェクトの爆発的増加 3. 開発ワークフローの標準化 • 「GitHubフロー」の確立 • プルリクエストベースの開発が標準に • コードレビュー文化の浸透 4. 開発者のポートフォリオ • GitHubプロフィールが開発者の履歴書に • Contribution Graphによる活動の可視化 • 採用活動での重要指標
  6. 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
  7. git のインストール方法 ターミナルで確認: > git version (多くの Mac には既にインストール済み) macOS

    Git Installer を使用 →最新版のインストーラーをダウンロードして実行 Homebrew を使用 →ターミナルで brew install git を実行git version で確認 https://github.com/git-guides/install-git Mac
  8. 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
  9. 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 をつかった クローン
  10. 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.鍵の生成
  11. 公開鍵の内容を表示 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へ の登録
  12. 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) をつかった クローン
  13. リポジトリ リポジトリ > Git clone xxxxxxxx(URL) リポジトリをクローンすると、 その時点で GitHub.com にあるすべてのリポジトリ

    データの完全なコピーがプ ルダウンされます。これには、 プロジェクトのすべてのファ イルとフォルダーのすべての バージョンも含まれます。 https://docs.github.com/ja/repositories/creating -and-managing-repositories/cloning-a- repository
  14. リポジトリ Local 一致! 実体は .git フォルダの中に 格納されてます 作業フォルダに 展開されている 実ファイル

    ※この時点で実は2か所にファイルが格納さ れています。なので、作業フォルダのファイル を消しても復旧できます。安心! 作業フォルダ
  15. リポジトリ Local 変更済 ズレた! 変更を加える ↓ 作業フォルダ VSCode 差分 difference

    変更したり、意図せず変 わった部分のことを 差分(diff)といいます。 差分を追跡・管理するの がバージョン管理です。 変更管理ともいわれる。 diff!
  16. リポジトリ Local 変更済 一致! 変更済 > git commit コミットメッセージ 変更をコミットするときには、コミットメッセージ

    を入力します。なにを書き換えたのか、 その意図を未来の自分や他者に明示します。 差分と一緒にgitリポジトリに格納されるので 真面目に書きましょう。
  17. なので、リビジョン「番号」ではなく、 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
  18. 履歴が異なっていると反映できない つまり、親が一致していないとプッシュできない、 というわけです。 差分の履歴 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.. じゃないので
  19. SHA-1ハッシュ値の詳細 SHA-1(Secure Hash Algorithm 1)は、任意のデータ から160ビット(40桁の16進数)の固定長ハッシュ値を 生成する暗号学的ハッシュ関数。 • 完全なハッシュ: a3c5f8e9d2b7c1d4f6e8d9b2c7a1f4e6d8b9c2a7(40文字)

    • 短縮表示: a3c5f8e(通常7文字、GitHubなどで使用) SHA-1の特性 • 一方向性: ハッシュ値から元データを復元できない • 決定性: 同じ入力は必ず同じハッシュ値になる • 雪崩効果: わずかな変更で全く異なるハッシュ値になる • 衝突耐性: 異なる入力が同じハッシュになる確率は極め て低い(理論上は2^80の計算で衝突可能) 米国標準技術研究所 で策定された標準規格 です
  20. git と GitHub の関係 git(バージョン管理システム) • 2005年にLinus Torvaldsが開発 • 分散型バージョン管理システム

    • ローカルで完結する履歴管理 • SHA-1ハッシュによる識別 GitHub(ホスティングサービス) • 2008年にサービス開始 • gitリポジトリをクラウドで管理 • Pull Request、Issue、CI/CDなどの機能 • 開発者のソーシャルプラットフォーム 関係性: gitはツールそのもの、GitHubはgitを使いや すくするサービス ここまでのまとめ
  21. Push(プッシュ) ローカルのコミットをリモートに送信。 他のメンバーと変更を共有。 > git push origin main Pull(プル) リモートの最新変更をローカルに取り込む。

    作業開始前に必ず実行。 > git pull origin main ※Pull = Fetch + Merge Fetch: リモートの変更を取得(まだマージしない) Merge: 取得した変更を現在のブランチに統合 ここまでのまとめ
  22. 変更済 別の変更 ズレた! diff! 別の変更 変更済 Merge(マージ) 同じファイルをいじっていない限りは、 Pullの際に、自動的に最新版が採用され てマージされる。

    同じファイルをいじっている場合は、 コンフリクト(衝突)が起きるので、 ファイルごとに個別にマージを行い、 最新版を確定する。 マージが終わったらプッシュする。 ここまでのまとめ