セットアップ - Git

はじめに

セットアップ シリーズ、Git 編。

主に以下について。

• Git クライアント
• Git サーバー
• Git ワークフロー

方針:

• Git クライアントの GUI 操作は、この記事では紹介しない。
• GUI 操作は、VS Code で事足りると思う。VS Code の拡張機能については、別記事を参照。

🚀 Git クライアント

👑 Windows 用

Git 公式が提供する Windows 用の Git クライアント「Git for Windows」を使う。

インストール:

https://gitforwindows.org/ からインストーラーを入手してインストールする。
インストーラーの選択肢の詳細は以下のとおり。

Information（情報）:

• Next ボタン

Select Destination Location（インストール先の選択）:

• C:\Program Files\Git（デフォルト）
• Next ボタン

Select Components（コンポーネントの選択）:

• 以下にチェック
  • ⬜ Additional Icons（Git Bash のショートカットを追加）
    • ⬜ On the Desktop
  • ✅ Windows Explorer Integration（コンテキストメニューに追加）
    • ✅ Git Bash Here
    • ✅ ➡ ⬜ Git GUI Here
      • Git GUI は使わないので
  • ✅ Git LFS (Large File Support)（大容量ファイルをサポート）
  • ✅ Associate .git* configuration files with the default text editor（.git* 構成ファイルをデフォルトのテキストエディターに関連付ける）
  • ✅ Associate .sh files to be run with Bash（.sh ファイルを Git Bash に関連付ける）
  • ⬜ Use a TrueType font in all console windows（すべてのコンソールウィンドウで TrueType フォントを使う）
    • チェックすると、多バイト文字で問題が出るらしい
  • ⬜ ➡ ✅ Check daily for Git for Windows updates（更新プログラムを毎日確認する）
    • 脆弱性対策のため最新版を使う
• Next ボタン

Select Start Menu Folder（スタートメニューフォルダーの選択）:

• デフォルトのまま Next ボタン

Choosing the default editor used by Git（Git で使うデフォルトエディターの選択）:

• Git のデフォルトエディターを選択する
  • ⚪ Use Vim (the ubiquitous text editor) as Git's default editor（Vim を使う）
    • デフォルト値。非推奨と書かれている
  • 🔵 Use Visual Studio Code As Git’s default editor（Visual Studio Code を使う）
    • 今回はこれを選択する
  • など
• Next ボタン

The Vim editor, while powerful, can be hard to use.
It's user interface is unintuitive and its key binding sare awkward.
Vim エディターは強力ですが、使いにくい場合があります。
そのユーザーインターフェイスは直感的ではなく、キーバインディングは厄介です。

Note: Vim is the default editor of Git for Windows only for historical reasons,
and it is highly recommended to switch to a modern GUI editor instead.
注：Vim は歴史的な理由のみで Git for Windows のデフォルトエディターであるので、
代わりに最新の GUI エディターに切り替えることを強くお勧めします。

Note: This will leave the 'core.editor' option unset, which will make Git fall back to the 'EDITOR' environment variable.
The default editor is Vim - but you may it to some other editor of your choice.
注：これにより、「core.editor」オプションが未設定のままになり、Gitが「EDITOR」環境変数にフォールバックします。
デフォルトのエディターは Vim ですが、他のエディターを選択することもできます。

Adjusting the name of the initial branch in new repositories（新しいリポジトリの最初のブランチ名を設定）:

• 最初のブランチ名を選択する
  • 🔵 Let Git decide（Git に決めさせる）
    • デフォルト値。基本的にこれ
  • ⚪ Override the default branch name for new repositories（新しいリポジトリのデフォルト ブランチ名を上書きする）
    • main など、master 以外のブランチ名を使う場合
• Next ボタン

Adjusting your PATH environment（PATH の設定）:

• Git Bash 以外の端末のために、PATH を通すか？（Git Bash 以外で git コマンドを使う場合以外は無視して OK）
  • ⚪ Use Git from Git Bash only
    • PATH 環境変数に何も設定しない
    • 他の Unix 互換環境（MinGW, cygwin 等）を使っていて、影響を考慮する場合に使う
  • 🔵 Git from the command line and also from 3rd-party software
    • 推奨。デフォルト値。基本的にこれ
    • コマンドプロンプトや PowerShell などからは Git コマンドのみが使えるが、Unix コマンドは使えない
  • ⚪ Use Git and optional Unix tools from the Command Prompt
    • コマンドプロンプトや PowerShell などから Git コマンドだけでなく、Unix コマンドが使えるようになる
    • ただし、find や sort などのコマンドが上書きされてしまうため、注意が必要
• Next ボタン

Choosing HTTPS transport backend（HTTPS トランスポートの設定）:

• ルート証明書の参照先を選択する
  • 🔵 Use the OpenSSL library（OpenSSL のものを参照）
    • デフォルト値。基本的にこれ
  • ⚪ Use the native Windows Secure Channel library（Windows の Secure Channel を参照）
    • 独自証明書を使っている場合
• Next ボタン

Configuring the line ending conbersions（行末の変換設定）:

• 改行コードを自動変換するか選択する
  • ⚪ Checkout Windows-style, commit Unix-style line endings
    • チェックアウト時に CRLF へ変換し、コミット時に LF へ変換。デフォルト値
  • ⚪ Checkout as-is, commit Unix-style line endings
    • チェックアウト時に何もないが、コミット時に LF へ変換
  • 🔵 Checkout as-is, commit as-is
    • 何もしない
    • これを選択して、Git には任せず .editorconfig などで制御するのがオススメ
• Next ボタン

Configuring the terminal emulator to use with Git Bash（ターミナルの設定）:

• ターミナルエミュレーターを選択する
  • 🔵 Use MinTTY
    • デフォルト値。基本的にこれ
  • ⚪ Use Windows’s default console windows
    • Windows のコンソールを使う場合
• Next ボタン

Choose the default behavior of git pull（git pull のデフォルト動作を選択）:

• git pull のデフォルト動作を選択する
  • 🔵 Default (fast-forward or merge)
    • デフォルト値。基本的にこれ。Git の標準的な動作に従う
  • ⚪ Rebase
  • ⚪ Only ever fast-forward
• Next ボタン

Choose a credential helper（資格情報ヘルパーを選択）:

• 資格情報ヘルパーを選択
  • 🔵 Git Credential Manager Core
    • デフォルト値。基本的にこれ
  • ⚪ Git Credential Manager
    • 非推奨。旧バージョンのものが必要な場合
  • ⚪ None
    • 資格情報ヘルパーを使わない
• Next ボタン

Configuring extra options（追加オプションの設定）:

• 以下にチェック
  • ✅ Enable file system caching（キャッシュを使う）
  • ⬜ Enable symbolic links（シンボリックリンクを使う）
    • Windows のシンボリックリンクは POSIX との完全な互換性がないので、無理に使うのはやめる派
    • 有効化する場合は、以下を参照
      • cf. Git for Windows でシンボリックリンクを扱えるようにする - Qiita
• Next ボタン

Configuring experimental options（実験オプションの設定）:

• デフォルトのまま Install ボタン

確認:

スタート メニュー > Git > Git Bash で起動し、以下を入力して確認。

# git の確認
$ which git && git --version
/mingw64/bin/git
git version 2.31.1.windows.1

# git flow の確認（一緒にインストールされている）
$ git flow version
1.12.3 (AVH Edition)

設定:

• ➊ スタート メニュー > Git > Git Bash を順にクリック
• ➋ 起動した Git Bash のタイトル バーを右クリック > Options... をクリック
  • Looks > Transparency で High を選択（端末の背景を半透明に）
  • Text > Font で Lucida Console ➡ Consolas や HackGenNerd Console などに変更（日本語を見やすく）
  • Save ボタンをクリック

👑 macOS 用

cf. Git - Downloading Package

Homebrew で、最新バージョンの Git をインストールする。
Xcode Command Line Tools の Git はバージョンが古いので、脆弱性対策のためこちらは使わない。

# インストール
$ brew install git

# 確認
$ which git && git --version
/usr/local/bin/git
git version 2.31.1

👑 Ubuntu 用

APT を使ってインストールする。

ちなみに公式サイトで案内される git-all は GUI などのサブパッケージを含むらしい。
cf. version control - Difference between installing git vs installing git-all - Ask Ubuntu

今回は不要なので git パッケージをインストールする。

# インストール
$ sudo apt install git

# 確認
$ which git && git --version
/usr/bin/git
/bin/git
git version 2.25.1

🔧 Git クライアントの初期設定

公式ドキュメントの記載のとおり、インストール後に最初にすべきことは「ユーザー名」と「メールアドレス」の設定だ。

コミット情報で「個人のメールアドレス」を公開したくない場合は、GitHub なら「no-reply メールアドレス」（<ID+username>@users.noreply.github.com）を提供してくれるので、これを使う。

「no-reply メールアドレス」を取得するには、公式ドキュメントの「GitHub のコミットメールアドレスを設定する」の手順で、Keep my email address private（メールアドレスをプライベートに保つ）にチェックを入れる。

利用するメールアドレスが決まったら、Git Bash で以下を実行する。

# ユーザー名とメールアドレスを設定する（グローバル設定: 全リポジトリーの共通設定）
$ git config --global user.name "サンプル 太郎"
$ git config --global user.email [e-mail]

# 確認
$ git config --global user.name && git config --global user.email
> サンプル 太郎
> [e-mail]

なお、特定のリポジトリーで「グローバル設定以外の設定」を適用する手順は以下のとおり。

# 作業中のリポジトリーへ移動（必要なら）
$ cd <作業中のリポジトリーのフォルダーパス>

# ユーザー名とメールアドレスを設定する（ローカル設定: グローバル設定より優先される、特定リポジトリーのための設定）
$ git config user.name "サンプル 次郎"
$ git config user.email [e-mail]

# 確認
$ git config user.name && git config user.email
> サンプル 次郎
> [e-mail]

🚀 Git サーバー

Git サーバーのホスティング先は、かつては自社サーバー等の「オンプレミス環境」も一般的だった。
（Git が国内で浸透し始めた 2010 年頃）

現在は、コスト的メリットから「クラウドサービス」が第一候補となるケースが多い。

代表的な Git サーバーのホスティング先は以下のとおり。

クラウドサービス型

• GitHub
  • 最もポピュラーな Gti サーバーのホスティングサービス。
  • 2020 年 4 月から、有料だった機能の多くが無料プランでも利用できるように。
    • CI/CD (GitHub Actions) の利用や、プライベートリポジトリの作成を含む。
    • SSO の利用等は、引き続き有料プランへの加入が必要。
• GitLab
  • OSS であり、オンプレミス サーバー上にも構築可能。
• Bitbucket
  • Atlassian 社製のため、同社の製品との相性が良いらしい。
• AWS CodeCommit
  • アマゾン ウェブ サービス (AWS) が提供するため、ユーザー管理等を AWS で統一する場合は選択肢に挙がる。
• Azure Repos
  • Microsoft Azure (Azure) が提供するため、ユーザー管理等を Azure で統一する場合は選択肢に挙がる。
• Cloud Source Repositories
  • Google Cloud Platform (GCP) が提供するため、ユーザー管理等を GCP で統一する場合は選択肢に挙がる。

オンプレミス型

• GitLab
  • 2011 年登場の、セルフホスト型では最もメジャーな OSS Git サーバー。
  • 高機能な反面、サーバーの要求スペックは高め。
• GitBucket
  • 2013 年登場の Git サーバー。
• Gogs
  • 2014 年登場の、現行の GitHub に近い見た目の Git サーバー。
  • 軽量。
• Gitea
  • 2016 年に Gogs からフォークされた Git サーバー。

🚀 Git ワークフロー

代表的な Git ワークフローは以下の 2 種類がある。

• GitHub フロー:
  • シンプルで、リリースサイクルの早いワークフロー。
  • 基本的にこれが推奨されるが、CI/CD のないプロジェクトでは採用すべきではない。
  • cf. GitHub のフロー - GitHub Docs
• git-flow:
  • 古くからあるワークフロー。
  • 複雑だが着実にリリースするために使われる。
  • cf. A successful Git branching model » nvie.com
  • cf. git-flow cheatsheet

詳細は以下の記事が詳しい。
cf. 【図解】git-flow、GitHub Flow を開発現場で使い始めるためにこれだけは覚えておこう：こっそり始める Git／GitHub 超入門（終） - ＠IT

👑 GitHub フロー

cf. Understanding the GitHub flow · GitHub Guides
cf. GitHub Flow (日本語訳)

シンプルなので特に説明することもないが、一応解説する。

🔖 ルール

• master ブランチは常時デプロイ可能な状態にする。
• 新しい何かに取り組む際は、master ブランチから feature ブランチを作成する。 （e.g. 会議開催通知機能を追加するなら feature/add-meeting-notice）
• あなたは feature ブランチで作業し、コミットする。定期的に push して、作業進捗を共有することも忘れずに。
• フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、プルリクエスト を作成する。
• 他の誰かがレビューをして OK を出してくれたら、プルリクエストで feature ブランチを master ブランチへマージする。
• master ブランチが更新されたら、直ちにデプロイをする。

👑 git-flow

cf. nvie/gitflow

git-flow でプルリクエストを使う場合のワークフロー例は以下のとおり。

🔖 インストール

git-flow 用のツールをインストールする。

Windows:

Git for Windows に含まれる。

macOS:

# Homebrew でインストール
$ brew install git-flow-avh

Ubuntu:

# APT でインストール
$ sudo apt install git-flow

🔖 ルール

基本ルール

• 基本となるブランチ:
  • master ブランチは、リリースされた現行バージョンと同じ。
  • develop ブランチは、開発中の次期バージョン。（ワークフローの中心となるブランチ）
  • feature ブランチは、各自の作業途中の状態。
• 開発フロー:
  • 各自は develop ブランチから feature ブランチはを作成し、そこで作業する。
  • 定期的に feature ブランチを push して作業進捗を共有しつつ、プルリクエストで TODO を示すこと。
  • feature ブランチでの作業が完了したら、プルリクエストで develop ブランチにマージする。
• リリースフロー:
  • develop から master ブランチにマージし、master ブランチをリリースする。

応用ルール

• 緊急対応の場合は feature ブランチの代わりに hotfix ブランチを作成する。
• hotfix ブランチでの作業が完成したら、develop と master ブランチにマージし、master ブランチをリリースする。

🔖 具体的な流れ

（最初のみ）デフォルトブランチを設定する

Git サーバー側の「デフォルトブランチ」を develop ブランチに変更する。

（最初のみ）初期化する

各ローカルリポジトリーごとに、git-flow を採用するための初期化が必要になる。

# 作業中のリポジトリーへ移動（必要なら）
$ cd <作業中のリポジトリーのフォルダーパス>

# git-flow で初期化
## -d ... 推奨のブランチ名を採用する
$ git flow init -d

➊ 開発する

develop ブランチを元に、作業毎にfeature ブランチを作成する。
ブランチ名は、後から分かりやすいように説明的な名前をつけること。

# プル（必要なら）
$ git pull origin develop

# feature ブランチを作成
# e.g. git flow feature start add-meeting-notice
$ git flow feature start <説明的なブランチ名>

修正のまとまり毎にコミットする。
feature ブランチは、完成前でも定期的に push して、作業進捗を共有する。

➋ 開発進捗を報告する

feature ブランチを push したら、develop ブランチにマージする形でプルリクエストを作成する。
作業が完了していない場合、プルリクエストのタイトルに　[WIP] と記載し、本文に TODO を残す。

タイトル: [WIP] ○○ 機能の新規追加
本文:

## サマリー

- ○○ を ○○ する機能を追加する。

## TODO

- [x] ○○.php に form を作成する
- [x] ○○ テーブルを作成する
- [ ] form をカスタマイズする
- [ ] form の挙動を確認する
- [ ] CSS の適応
- [ ] テスト

➌ レビューを依頼する

feature ブランチでの作業が完了したら、push する。
プルリクエストのタイトルから　[WIP] の記載を削除し、本文を更新した上で担当者をレビュアーに変更し、レビューを依頼する。

タイトル: ○○ 機能の新規追加
本文:

## サマリー

- ○○ を ○○ する機能を追加する。
- （その他、共有すべき内容を記載）

## テスト結果

- （試験結果のエビデンスを記載）

コミット内容などに問題がなければ、レビュアーはプルリクエストを使って develop ブランチにマージし、feature ブランチを削除する。
問題があればレビュー依頼者に差し戻す。

➍ リリースする

必要な feature ブランチがマージし終われば、develop ブランチが問題ないことを確認する。
これも問題なければ、develop ブランチから master ブランチにマージし、master ブランチをリリースする。

# develop から release ブランチを作成し、master と develop ブランチにマージ
$ git flow release start v1.0.0
$ git flow release finish v1.0.0

# プッシュ
$ git push origin master develop && git push origin --tags

（必要な場合のみ）緊急対応する

緊急対応には、feature ブランチの代わりに hotfix ブランチを使う。
hotfix ブランチでの修正が終われば、develop ブランチと master ブランチにマージし、master ブランチをリリースする。

# master から hotfix ブランチを作成
$ git flow hotfix start v1.0.1

# 修正をコミット

# hotfix ブランチを master と develop ブランチにマージ
$ git flow hotfix finish v1.0.1

# プッシュ
$ git push origin master develop && git push origin --tags

参考文献

• Git for Windows のインストールについて
  • 私家版 Git For Windows のインストール手順 | OPCDiary
  • 【0 から始める Git】Git をインストールしてみた | たくメモ
• 初期設定について
  • Git - 最初の Git の構成
  • Git でのユーザ名を設定する - GitHub Docs
  • コミットメールアドレスを設定する - GitHub Docs