Git and GitHub tutorial

@ 2024-06-12 / by Akio Taniguchi (project assistant professor)

  • 目的：
    • 世界標準のバージョン管理システムGitと開発プラットフォームGitHubを使ったソフトウェア開発の方法をざっくり学ぶ
  • 目標：
    • 実際にGitを使ってA研のGitHub organization上のリポジトリにコミット（コードを登録）することで開発の流れを理解する

Contents

  1. バージョン管理とは何か・なぜ必要か
  2. バージョン管理システムGit
  3. ソフトウェア開発プラットフォームGitHub
  4. GitとGitHubを使った開発の流れ
  5. a-lab-nagoya/playgroundを使ったチュートリアル

バージョン管理とは何か

  • バージョン管理（en: version control）
    • ファイルやディレクトリ内容のバージョン（変更履歴＝誰がいつどのような変更を加えたか）を保存して、変更内容を確認したり任意の時点に戻したりできるようにすること
  • バージョン管理システム（en: version control system or VCS）
    • バージョン管理を支援するコマンドラインツールやアプリ
  • 色々なバージョン管理システム
    • Git, Subversion, Mercurial: コマンドラインツール
    • macOS Time Machine: Mac全体のバックアップ

バージョン管理はなぜ必要か

  • 変更履歴の完全な追跡
    • バグが発生した場合も発見や対処が用意。また、任意の時点の状態に戻れるので、開発環境の再現性が高い。
  • 変更目的の明確化
    • ファイル名や時刻による管理では、変更をなぜ加えたかが明確でない。意味単位で管理することが複数人での開発では重要。
  • バージョン管理の一元化
    • 標準的なVCSを使うことで、共通の方法でバージョン管理でき、かつ変更履歴を一箇所に集約できる。

バージョン管理システムGit

  • Git
    • 2024年現在、ソフトウェア開発において最も使われているVCS
    • もともとはLinuxのソースコード管理のために作成された
  • 分散型のバージョン管理
    • リポジトリ（en: repository）と呼ばれる、変更履歴を保存するデータベースのような仕組みを使ってバージョン管理する
    • ユーザごとにローカルリポジトリを持ち、変更はここに保存
    • サーバ上のリモートリポジトリにローカルの内容を反映する

バージョン管理システムGit

  • Gitのリポジトリの仕組み
    • バージョン：ディレクトリに存在するファイルのある時点での完全な内容をスナップショットとして保存したもの（ディレクトリをzipしてバックアップする感覚に近い）
    • リポジトリ：複数のスナップショットとそれらの対応関係を保存したデータベースのようなもの
    • コミット（en: commit）：スナップショットを作成して変更を確定すること（またはバージョンそのものを指す場合もある）

バージョン管理システムGit

  • Gitのリポジトリの可視化
    • コミット履歴は有向グラフで表現されることが多い
      • ノード（頂点）：それぞれのコミット
      • エッジ（枝）：コミット間の対応関係（親子関係）
  • 重要な用語
    • ブランチ（en: branch）：分岐した枝の先頭のコミット
    • マージ（en: merge）：2つのブランチを統合して一つにすること
    • main（master）ブランチ：リポジトリのデフォルトのブランチ

バージョン管理システムGit

  • Gitのコミット
    • コミットはスナップショットの他に様々な情報を持つ
      • コミットメッセージ：作業内容の要約（必須）
      • コミット日時：コミット作成時の時刻情報
      • コミッター情報：コミットした人の名前とメールアドレス
      • コミットID：自動生成される40文字のハッシュ値
      • 親のコミットIDs：どのコミットから派生したのか
    • コミットは適当な粒度で行う（多くの作業を詰め込まない）

ソフトウェア開発プラットフォームGitHub

  • GitHub
  • 主な機能
    • Gitのリモートリポジトリのホスティング
    • イシュー（en: issue）によるプロジェクト管理
    • プルリクエスト（en: pull request）によるコラボレーション
    • GitHub Actionsによるテスト・ビルドなどの自動化

ソフトウェア開発プラットフォームGitHub

GitとGitHubを使った開発の流れ

  1. GitHub上にリモートリポジトリを作成
  2. GitHub issuesに機能追加等のissueを作成→issue番号取得
  3. ローカルにリポジトリをコピー（クローン）する
  4. ローカルでIssue番号付きのトピックブランチを作成
  5. ローカルで新機能をコミット→プッシュ
  6. Pull requestでトピックブランチをmainブランチにマージ
    • この際に他の人によるレビューや自動テストを受ける
    • ダメだったら修正をコミット→プッシュしてやり直し

GitとGitHubを使った開発の流れ

  • なんでこんな面倒なことをするのか？
    • Issueとトピックブランチ
      • 一連のコミットの目的を明確化させるとともに、開発者が一つの機能開発に集中できるようにするため
      • （逆に言うと複数の作業を一度に行わせないようにするため）
    • プルリクエスト
      • トピックブランチをmain（master）にマージする前にレビューやテストを強制することでバグを未然に防ぐ
      • 第三者からの提案を安全な形で受けられる（social coding）

Playgroundを使ったチュートリアル

  • 事前準備
    • Gitのインストール（各自）
    • Visual Studio Code（VS Code）のインストール（各自）
    • Git Graph（VS Code拡張機能）のインストール（各自）
    • GitHubアカウントの作成（各自）
    • GitHubアカウントのA-lab organizationへの登録（谷口）
$ brew install git
$ brew cask install visual-studio-code
$ code --install-extension mhutchie.git-graph

Playgroundを使ったチュートリアル

  • リモートリポジトリのクローン（en: clone）
    • playgroundをクローンし、ローカルリポジトリを作成する
    • ローカルリポジトリをVS Codeで開く
    $ git clone https://github.com/a-lab-nagoya/playground.git
$ code playground # またはVS Codeでplaygroundディレクトリを開く
  • VS Codeの機能の概観
    • VS Codeのエクスプローラ・ソース管理の機能を確認する
    • Git Graphでコミット履歴を見る（⌘⇧P → view git graph）

Playgroundを使ったチュートリアル

  • Gitの初期設定（ローカル）
    • ctrl-backquoteでVS Codeのターミナルを開いて以下を設定する
    $ git config --global user.name "<your name in romaji>"
$ git config --global user.email "<your public email address>"
  • GitHub issueの作成（GitHub）

Playgroundを使ったチュートリアル

  • トピックブランチの作成（ローカル）
    • VS Codeでブランチを作成する（⌘⇧P → create branch）
    • ブランチ名にはissue番号を含める（例：astropenguin/issue51）
  • ファイルやコードを編集する（ローカル）
    • ここでは2024/todo.mdの該当タスクにチェックを付ける
  • 変更をコミットする（ローカル）
    • VS Codeのソース管理から変更をコミットする
    • メッセージにはissue番号を含める（#51 Close task of Work B）

Playgroundを使ったチュートリアル

  • 変更をプッシュする（ローカル→GitHub）
    • リモートブランチへプッシュする（⌘⇧P → push）
    • Git Graphでプッシュされたことを確認してみよう
  • 変更をマージする（GitHub）
    • New pull requestからトピックブランチをmainブランチにマージするためのプルリクエストを作成する
    • base: main、compare: <作成した自分のブランチ名>となるようにする
    • レビュワーを誰か一人指定する（例：astropenguin）
    • レビューが通ったらMerge pull requestからマージする

参考文献