首先

设定系列，Git 编。

主要涉及以下内容。

• Git クライアント

 

• Git サーバー

 

Git ワークフロー

指导原则:

• Git クライアントの GUI 操作は、この記事では紹介しない。

 

GUI 操作は、VS Code で事足りると思う。VS Code の拡張機能については、別記事を参照。

? Git 客户端

中国正版 Windows 适用

使用由Git官方提供的Windows版Git客户端——“Git for Windows”。

安装

从 https://gitforwindows.org/ 下载安装程序并进行安装。
安装程序选项的详细内容如下所示。

资讯:

Next ボタン

选择目标位置（安装目标位置选择）

C:\Program Files\Git（デフォルト）

Next ボタン

选择组件

• 以下にチェック

⬜ 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 ボタン

选择开始菜单文件夹

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

选择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 ですが、他のエディターを選択することもできます。

调整新仓库中初始分支的名称。

• 最初のブランチ名を選択する

? Let Git decide（Git に決めさせる）

デフォルト値。基本的にこれ

⚪ Override the default branch name for new repositories（新しいリポジトリのデフォルト ブランチ名を上書きする）

main など、master 以外のブランチ名を使う場合

Next ボタン

调整您的 PATH 环境（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 ボタン

选择HTTPS传输后端（选择HTTPS传输后端的设置）

• ルート証明書の参照先を選択する

? Use the OpenSSL library（OpenSSL のものを参照）

デフォルト値。基本的にこれ

⚪ Use the native Windows Secure Channel library（Windows の Secure Channel を参照）

独自証明書を使っている場合

Next ボタン

配置行尾转换设置

• 改行コードを自動変換するか選択する

⚪ 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 ボタン

配置终端模拟器以在Git Bash中使用（终端设置）

• ターミナルエミュレーターを選択する

? Use MinTTY

デフォルト値。基本的にこれ

⚪ Use Windows’s default console windows

Windows のコンソールを使う場合

Next ボタン

选择git pull的默认行为。

git pull のデフォルト動作を選択する

? Default (fast-forward or merge)

デフォルト値。基本的にこれ。Git の標準的な動作に従う

⚪ Rebase
⚪ Only ever fast-forward

Next ボタン

选择一个凭据助手。

• 資格情報ヘルパーを選択

? Git Credential Manager Core

デフォルト値。基本的にこれ

⚪ Git Credential Manager

非推奨。旧バージョンのものが必要な場合

⚪ None

資格情報ヘルパーを使わない

Next ボタン

配置额外选项：

• 以下にチェック

✅ Enable file system caching（キャッシュを使う）
⬜ Enable symbolic links（シンボリックリンクを使う）

Windows のシンボリックリンクは POSIX との完全な互換性がないので、無理に使うのはやめる派
有効化する場合は、以下を参照

cf. Git for Windows でシンボリックリンクを扱えるようにする – Qiita

Next ボタン

配置实验选项

デフォルトのまま 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 ボタンをクリック

專為蘋果電腦設計的操作系統。

参考Git – 下载软件包

使用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 等子包。参考资料：版本控制-在 Ubuntu 上安装 Git 和安装 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），您可以使用它。

在官方文件的「设置GitHub提交的邮件地址」的步骤中，勾选“保持我的邮件地址私有（Keep my email address private）”即可获得“no-reply 邮箱地址”。

当您确定要使用的电子邮件地址后，使用Git Bash执行以下操作。

# ユーザー名とメールアドレスを設定する（グローバル設定: 全リポジトリーの共通設定）
$ 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

另外，在特定的存储库中应用”除全局设置外的其他设置”的步骤如下：

# 作業中のリポジトリーへ移動（必要なら）
$ 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

最もポピュラーな 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工作流如下。

GitHub フロー:

シンプルで、リリースサイクルの早いワークフロー。
基本的にこれが推奨されるが、CI/CD のないプロジェクトでは採用すべきではない。
cf. GitHub のフロー – GitHub Docs

git-flow:

古くからあるワークフロー。
複雑だが着実にリリースするために使われる。
cf. A successful Git branching model » nvie.com

cf. git-flow cheatsheet

以下的文章很详细，请参考以下的文章。
例如 【图解】git-flow、GitHub Flow 在开发现场中开始使用时需要记住的要点：秘密开始 Git/GitHub 超入门（完）- ＠IT

? GitHub 流程

参考GitHub指南了解GitHub流程
参考GitHub流程的日本语译版

简洁明了，无需特别解释，不过还是简单解释一下。

? 规则 (guī zé)

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

master ブランチが更新されたら、直ちにデプロイをする。

? Git流程

参见nvie/gitflow

以下是使用git-flow的pull request的工作流程示例。

? 安装

安装用于 git-flow 的工具。

Windows 操作系统。

包含在Windows版本的Git中。

macOS: 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 分支，就创建一个以合并到 develop 分支的形式的拉取请求。
如果工作还没有完成，在拉取请求的标题中加上 [WIP]，并在正文中留下 TODO。

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

## サマリー

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

## TODO

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

请写一篇评论

特性分支的工作完成后，请进行推送。
从拉取请求标题中删除[WIP]标记，并更新正文，将负责人更改为审核者，并请求审核。

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

## サマリー

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

## テスト結果

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

如果没有问题，评审人可以使用拉取请求将提交的内容合并到develop分支，并删除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

只在必要的情况下进行紧急应对。

在紧急情况下，使用 hotfix 分支代替 feature 分支进行应对。
当修复工作在 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