セットアップ - Git

# はじめに

[**セットアップ シリーズ**](https://qiita.com/yokarikeri/items/a4e41a36c610bb1c798b)、Git 編。

主に以下について。

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

**方針:**

- Git クライアントの **GUI 操作**は、この記事では紹介**しない**。
- GUI 操作は、VS Code で事足りると思う。VS Code の拡張機能については、[別記事](https://qiita.com/yokarikeri/items/d6d9bb1e4f55869395af#-%E6%8B%A1%E5%BC%B5%E6%A9%9F%E8%83%BD-gitlens--git-supercharged)を参照。

# 🚀 Git クライアント

## 👑 Windows 用

[Git 公式](https://git-scm.com/)が提供する 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` ボタン

```txt
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](https://qiita.com/ucho/items/c5ea0beb8acf2f1e4772)
- `Next` ボタン

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

- デフォルトのまま `Install` ボタン

**確認:**

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

```sh
# 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](https://git-scm.com/download/mac)

[Homebrew](https://brew.sh/) で、最新バージョンの Git をインストールする。
`Xcode Command Line Tools` の Git はバージョンが古いので、脆弱性対策のためこちらは使わない。

```sh
# インストール
$ brew install git

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

## 👑 Ubuntu 用

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

ちなみに[公式サイト](https://git-scm.com/book/ja/v2/%E4%BD%BF%E3%81%84%E5%A7%8B%E3%82%81%E3%82%8B-Git%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB)で案内される `git-all` は GUI などのサブパッケージを含むらしい。
cf. [version control - Difference between installing git vs installing git-all - Ask Ubuntu](https://askubuntu.com/questions/796600/difference-between-installing-git-vs-installing-git-all)

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

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

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

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

[公式ドキュメント](https://git-scm.com/book/ja/v2/%E4%BD%BF%E3%81%84%E5%A7%8B%E3%82%81%E3%82%8B-%E6%9C%80%E5%88%9D%E3%81%AEGit%E3%81%AE%E6%A7%8B%E6%88%90)の記載のとおり、インストール後に最初にすべきことは「**ユーザー名**」と「**メールアドレス**」の設定だ。

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

「`no-reply` メールアドレス」を取得するには、[公式ドキュメント](https://docs.github.com/ja/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address)の「GitHub のコミットメールアドレスを設定する」の手順で、`Keep my email address private`（メールアドレスをプライベートに保つ）にチェックを入れる。

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

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

# 確認
$ git config --global user.name && git config --global user.email
> サンプル 太郎
> taro@example.com
```

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

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

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

# 確認
$ git config user.name && git config user.email
> サンプル 次郎
> jiro@example.com
```

# 🚀 Git サーバー

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

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

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

## クラウドサービス型

- [GitHub](https://github.co.jp/)
    - 最もポピュラーな Gti サーバーのホスティングサービス。
    - 2020 年 4 月から、有料だった機能の多くが[無料プラン](https://docs.github.com/en/free-pro-team@latest/github/getting-started-with-github/faq-about-changes-to-githubs-plans)でも利用できるように。
        - CI/CD ([GitHub Actions](https://github.co.jp/features/actions)) の利用や、プライベートリポジトリの作成を含む。
        - SSO の利用等は、引き続き有料プランへの加入が必要。
- [GitLab](https://about.gitlab.com/)
    - OSS であり、オンプレミス サーバー上にも構築可能。
- [Bitbucket](https://bitbucket.org/)
    - Atlassian 社製のため、同社の製品との相性が良いらしい。
- [AWS CodeCommit](https://aws.amazon.com/jp/codecommit/)
    - アマゾン ウェブ サービス (AWS) が提供するため、ユーザー管理等を AWS で統一する場合は選択肢に挙がる。
- [Azure Repos](https://azure.microsoft.com/ja-jp/services/devops/repos/)
    - Microsoft Azure (Azure) が提供するため、ユーザー管理等を Azure で統一する場合は選択肢に挙がる。
- [Cloud Source Repositories]()
    - Google Cloud Platform (GCP) が提供するため、ユーザー管理等を GCP で統一する場合は選択肢に挙がる。

## オンプレミス型

- [GitLab](https://about.gitlab.com/)
    - 2011 年登場の、セルフホスト型では最もメジャーな OSS Git サーバー。
    - 高機能な反面、サーバーの要求スペックは高め。
- [GitBucket](https://github.com/gitbucket/gitbucket)
    - 2013 年登場の Git サーバー。
- [Gogs](https://github.com/gogs/gogs)
    - 2014 年登場の、現行の GitHub に近い見た目の Git サーバー。
    - 軽量。
- [Gitea](https://github.com/go-gitea/gitea)
    - 2016 年に Gogs からフォークされた Git サーバー。

# 🚀 Git ワークフロー

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

- **GitHub フロー:**
    - シンプルで、リリースサイクルの早いワークフロー。
    - 基本的にこれが推奨されるが、CI/CD のないプロジェクトでは採用すべきではない。
    - cf. [GitHub のフロー - GitHub Docs](https://docs.github.com/ja/github/collaborating-with-issues-and-pull-requests/github-flow)
- **git-flow:**
    - 古くからあるワークフロー。
    - 複雑だが着実にリリースするために使われる。
    - cf. [A successful Git branching model » nvie.com](https://nvie.com/posts/a-successful-git-branching-model/)
    - cf. [git-flow cheatsheet](https://danielkummer.github.io/git-flow-cheatsheet/index.ja_JP.html)

詳細は以下の記事が詳しい。
cf. [【図解】git-flow、GitHub Flow を開発現場で使い始めるためにこれだけは覚えておこう：こっそり始める Git／GitHub 超入門（終） - ＠IT](https://www.atmarkit.co.jp/ait/articles/1708/01/news015.html)

## 👑 GitHub フロー

> cf. [Understanding the GitHub flow · GitHub Guides](https://guides.github.com/introduction/flow/)
> cf. [GitHub Flow (日本語訳)](https://gist.github.com/Gab-km/3705015)

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

### 🔖 ルール

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

## 👑 git-flow

> cf. [nvie/gitflow](https://github.com/nvie/gitflow)

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

### 🔖 インストール

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

**Windows:**

Git for Windows に含まれる。

**macOS:**

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

**Ubuntu:**

```sh
# 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 を採用するための初期化が必要になる。

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

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

#### ➊ 開発する

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

```sh
# プル（必要なら）
$ 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 を残す。

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

## サマリー

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

## TODO

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

#### ➌ レビューを依頼する

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

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

## サマリー

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

## テスト結果

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

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

#### ➍ リリースする

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

```sh
# 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` ブランチをリリースする。

```sh
# 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](https://opcdiary.net/technical/programming/%E7%A7%81%E5%AE%B6%E7%89%88-git-for-windows%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E6%89%8B%E9%A0%86/)
    - [【0 から始める Git】Git をインストールしてみた | たくメモ](https://takumi9942.net/blog/?p=1059)
- 初期設定について
    - [Git - 最初の Git の構成](https://git-scm.com/book/ja/v2/%E4%BD%BF%E3%81%84%E5%A7%8B%E3%82%81%E3%82%8B-%E6%9C%80%E5%88%9D%E3%81%AEGit%E3%81%AE%E6%A7%8B%E6%88%90)
    - [Git でのユーザ名を設定する - GitHub Docs](https://docs.github.com/ja/github/getting-started-with-github/setting-your-username-in-git)
    - [コミットメールアドレスを設定する - GitHub Docs](https://docs.github.com/ja/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address)