GitHub＠Git¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. Issue¶
作業内容¶
▼ 作成¶
テンプレートを元に、Issue を作成する。
1 個の Issue とブランチにたくさんの実装をコミットすることは望ましくない。
そこで、大きな対応を個々の対応に分割する。
そして、大きな対応に関する基点 Issue と基点ブランチを作成し、個々の対応に関連する子 Issue と子ブランチを作成していく。
各対応が終了したら、親ブランチへマージしていく。
▼ 削除¶
リポジトリの管理者権限があれば削除できる。
テンプレート¶
▼ 配置場所¶
リポジトリの直下に .github ディレクトリを配置し、ISSUE_TEMPLATE.md ファイルや PULL_REQUEST_TEMPLATE.md ファイルを配置する。
Issue のテンプレートに関して、代わりに ISSUE_TEMPLATE ディレクトリを配置し、任意の名前の md ファイルを配置すると、複数のテンプレートを作成できる。
repository/
├── .github/
│ ├── ISSUE_TEMPLATE.md
│ └── PULL_REQUEST_TEMPLATE.md
│
repository/
├── .github/
│ ├── ISSUE_TEMPLATE/
│ │ ├── FIX.md
│ │ └── UPDATE.md
│ │
│ └── PULL_REQUEST_TEMPLATE.md
│
▼ タイトル¶
タイトルは『〇〇する。』とする。
句読点の有無は好み。
▼ 内容¶
内容は『背景』と『対応方針』が伝わればよい。
文言自体は、そのリポジトリのルールに合わせる。
＊例＊
# 背景
<!-- Issue作成の理由になった要望やバグを記載する -->
<!-- 関連するIssueやプルリクエストがあればリンクを共有する -->
# 対応方針
<!-- どのような方法で対応する予定なのかを箇条書きで記載する -->
<!-- 方法に関するドキュメントや技術記事があればリンクを共有する -->
02. プルリクエスト¶
作業内容¶
▼ 呼び名¶
GitHub ではプルリクエストである。
一方で、GitLab ではマージリクエストという。
▼ 作成¶
テンプレートを元に、プルリクエストを作成する。
▼ 削除¶
削除できないため、クローズするしかない。
犯した罪は背負って生きていかなければならない。
テンプレート¶
▼ 配置場所¶
Issue テンプレートと同じ階層に配置する。
▼ タイトル¶
タイトルは『〇した。』とする。
句読点の有無は好み。
▼ WIP¶
実装途中のプルリクエストであり、実装方法などを質問したい場合、タイトルに『WIP』とつけておく。
レビューしてもらいたくなったら、これをはずす。
レビュー修正時に、実装に時間がかかりそうであったら、再び付けてもよい。
▼ 内容¶
内容は『対応内容』と『レビューしてほしいところ』さえ伝われば、文言自体はそのリポジトリのルールに合わせる。
もし、レビュー期限や動作確認手順を知らせる必要があれば『レビュー期限』『確認手順』の項目を設ける。
＊例＊
# リリース予定日
<!-- リリース予定日を記載する -->
# 対応内容
<!-- どのように対応したのか箇条書きで記載する -->
<!-- 関連するIssueやプルリクエストがあればリンクを共有する -->
# レビューしていただきたいところ
<!-- 対応内容の中で適切か否かが不安なものを記載する -->
コミットの粒度¶
DB からフロント出力までに至る実装をコミットする場合、以下の 3 個を意識する。
- DB からコミット
- 関連性のある実装をまとめてコミット
- 1 回のコミットで、コードサイズを少なくする
レビュー観点¶
▼ ドメインルールや要件通りか¶
実装の条件文や、コメントから、ドメインルールや仕様を理解する。
(1)-
条件文で
var_dump()関数 を実行する。 (2)-
どういった入力がされたときに
trueとして判断しているのかを確認する。
例えば、受注済区分値が設定されているとき、失注区分値へ変わった場合に値を返却しているとする。
この場合、そこから『失注』のドメインルールが垣間見える。
(3)-
定数に添えられたコメントから、仕様を理解。
▼ バリデーションは適切か¶
まさしく区別して empty() 関数 や isset() 関数 などを使えているか否かを確認する
▼ 冗長になっていないか¶
重複する処理を foreach() 関数にまとめられないか否かを確認する。
また、変数の格納が重複していないか否かを確認する。
03. GitHub-API¶
最新リリース¶
GitHub の API を使用することで、リリースページにある最新のバイナリをインストールできる。
# リリースページの最新のバイナリへのURLを取得する
$ LATEST_DOWNLOAD_URL=$(curl -sL https://api.github.com/repos/hiroki-hasegawa/foo-repository/releases/latest | jq -r ".assets[].browser_download_url" | grep linux_amd64)
$ curl -sL -O "${LATEST_DOWNLOAD_URL}"
# 解凍する
$ tar zxvf *.tar.gz
# 相対パスでバイナリを実行する
$ ./foo-bainary --version
04. Git-flow¶
Git-flowとは¶
Git でソフトウェアを開発する場合、役割を持たせたブランチを作成し、ルールに沿ってコミットする。Git-flow を簡略化したものに、GitHub-flow や Gitlab-flow がある。
実行環境とブランチ¶
▼ 対応関係¶
ブランチのデプロイ先となる実行環境は、以下の通りに分類できる。
より上位の実行環境ほど、本番環境に近くなる。
| 実行環境名 | ブランチ |
|---|---|
| 開発環境 (ローカルマシン) | feature |
| テスト環境 (サンドボックス環境、検証環境) | develop/testing (develop/sandbox) |
| ステージング環境 (ユーザー受け入れ環境) | develop/staging (develop/ua) |
| 本番環境 | release |
▼ main ブランチ (production)¶
本番環境にデプロイする機能を準備するためのブランチ。
本番環境への実際のデプロイは、release ブランチから実行する。
▼ hotfix ブランチ¶
リリース後に修正点が見つかった場合、修正用ブランチを作成し、これを速やかにリリースする必要がある。
(1)-
Issue を作成する。
(2)-
mainブランチから、『hotfix/<issue番号>』の名前でブランチを作成する。 (3)-
プルリクエストを作成し、マージの向き先を
mainブランチとする。 (4)-
速攻で approve をもらい、
mainブランチにマージする。このとき、hotfixブランチはあとでdevelopブランチにマージするため、削除しないようにする。 (5)-
パッチ番号を 1 つ増やしたタグを付与し、再リリースする。
(6)-
リリース後、エラーが解決されたら、ローカルマシンで
hotfixブランチをdevelopブランチにマージする。
▼ release ブランチ¶
develop ブランチまたは main ブランチを基点とし (個人的には main ブランチ基点) 、本番環境にデプロイする機能をまとめるためのブランチ。
release ブランチの作成自体が任意であるが、もし作成しない場合には develop ブランチにマージできないプルリクエストがたくさん溜まることになるため、推奨である。
▼ develop/staging ブランチ (develop/ua)¶
develop ブランチを基点とし、ステージング環境 (ユーザー受け入れ環境) に機能をデプロイするためのブランチ。
CI ツールや CD ツールを使用して、コミット (マージコミットを含む) によってデプロイが発火する。
▼ develop/testing ブランチ (develop/sandbox)¶
develop ブランチを基点とし、テスト環境 (サンドボックス環境、検証環境) に機能をデプロイするためのブランチ。
CI ツールや CD ツールを使用して、コミット (マージコミットを含む) によってデプロイが発火する。
▼ feature ブランチ¶
develop ブランチを基点とし、機能を作成/更新/削除するリクエストを作成するためのブランチ。
リリースノート¶
▼ 例¶
▼ タグ¶
『release/v<セマンティックバージョニング>』とする。タグの付与先対象とするブランチは、『Target: main』を選択する。
X.Y.Z |
説明 |
|---|---|
メジャー (X) |
機能の追加/変更/バグ修正である。後方のバージョンと互換性がない。ユーザーは、既存の実装を変更しないと既存機能と新機能を利用できない。 |
マイナー (Y) |
機能の追加/変更/バグ修正である。後方のバージョンと互換性がある。ユーザーは、実装を追加するだけで新機能を利用でき、また実装を変更せずに既存機能を利用できる。 |
パッチ (Z) |
機能のバグ修正である。後方のバージョンと互換性がある。ユーザーは、実装はそのままで既存機能を利用できる。 |
▼ リリース名¶
タグのバージョンをリリース名とする。
▼ 本文¶
以下の通りの本文とする。
『新規追加』『変更』『修正』ごとに、プルリクエスト番号をリスト化する。
3 個のどれに当てはまるかは、プルリクエストがどういった対応なのかで判断する。
最低限リリース内容さえわかればよいので、厳密に分類できなくとも問題ない。
# リリース内容
## 新規追加
- プルリクエスト番号
## 変更
- プルリクエスト番号
- ...
プルリクエスト番号
## 修正
- プルリクエスト番号
05. コンフリクトの解決¶
解決方法¶
▼ Gitを使用して¶
(1)-
git statusを行い、特定のファイルでのコンフリクトが表示される。
Unmerged paths:
(use "git restore --staged <file>..." to unstage)
(use "git add <file>..." to mark resolution)
both modified: foo/bar.twig
(2)-
コンフリクトしていたコード行を取捨選択する。
<?php
/// Phpstromにて、コンフリクトしていたコード行を取捨選択する。
(3)-
一度
addを行い、コンフリクトの修正を Git に認識させる。
$ git add foo/bar.twig
(4)-
git statusを行い、以下が表示される。
コンフリクトが解決されたが、マージされていないと出力される。
差分のファイルがたくさん表示される場合でも問題ない。
All conflicts fixed but you are still merging.
Changes to be committed:
modified: foo.twig
modified: foo.php
(5)-
git commit(-mはつけてはいけない) を行い、vim エディタが表示される。
Merge branch "ブランチ名" into ブランチ名
(6)-
:wqでエディタを終了すれば、コンフリクトを解決したマージコミットが作成される。 (7)-
git statusを実行する。場合によっては、差分のコミット数が表示されるが問題ない。
Your branch is ahead of "origin/feature/update_foo" by 10 commits.
(8)-
プッシュする。このとき、マージコミットを作成するとき、基点ブランチ以外からマージしていると、差分のコミットが 1 つにまとまらず、
▼ GitHubを使用して¶
プルリクエスト上に『Resolve conflicts』ボタンが出現し、ここからコンフリクトを修正できる。
▼ エディタを使用して¶
エディタの例として、PHPStorm を使用する。
一番簡単かもしれない。
ブランチ別の解決方法¶
▼ feature vs. develop¶
feature ブランチから develop ブランチへのマージ時にコンフリクトが起きるとわかった場合、まず develop ブランチから feature ブランチにマージを実行する。
その後、feature ブランチ上のファイルを修正する。
修正でコンフリクトが解決されれば、プルリクエスト上にプッシュする。
▼ develop vs. main¶
develop ブランチから main ブランチへのマージ時にコンフリクトが起きるとわかった場合、まず develop ブランチからコンフリクト解決用の feature ブランチを作成する。
main ブランチから feature ブランチにマージを実行し、この feature ブランチ上のファイルを修正する。
この修正を基に、コンフリクトを解決するためのプルリクエストを新たに作成する。
feature ブランチと develop ブランチとの差分が最小限になるように、必要であれば、develop ブランチから必要なファイルをコピーしてくる。
基点ブランチからの変更の取り込み¶
1 個の基点ブランチから数段階の派生ブランチが作成されている場合、基点ブランチから一段目、一段目から二段目、というように順にマージを行わないと、コンフリクトの原因になる。
(1)-
基点ブランチから、一段目の派生ブランチにマージし、これをプッシュする。ここでプッシュしないと、2 番目のブランチが 1 つ目のブランチとの差分を検出してしまい、大サイズの差分コミットをマージすることになってしまう。
(2)-
一段目のブランチから二段目のブランチにマージし。これをプッシュする。