【私的】GitHub ブランチ運用ルール
【私的】GitHub ブランチ運用ルール
これは私が協業するメンバーと GitHub レポジトリを管理する際のブランチ運用ルールをまとめたものです。
GitHub のアカウント作成・登録
- GitHub ( https://github.com/ ) のアカウントを作成し、アカウント名・メールアドレスをレポジトリ管理者に連絡してください。
- レポジトリ管理者は連絡されたメールアドレスをレポジトリに登録、アクセス権限を割り当ててください。
- GitHub のアカウント登録後、SSH鍵を GitHub に登録してください。SSH鍵の作成・登録方法は GitHub のドキュメントを参照してください。
手順の 1. と 2. の順番が前後すると、レポジトリへの招待メールが正常に届きません。注意してください。
ブランチの役割
- master: プロダクトとしてリリースするためのブランチ。リリースしたらタグ付けする。
- develop: 開発ブランチ。コードが安定しリリース準備ができたら master へプルリクエストし、マージする。このブランチが最新バージョンとなる。
- feature/xxxxxxxx: 機能の追加。 develop から分岐し develop にプルリクエストし、マージする。
- fix/xxxxxxxx: リリース後のクリティカルなバグフィックスなど、 現在のプロダクトのバージョンに対する変更用。 master から分岐し、 master にプルリクエストし、マージ後、タグをつける。次に develop にマージする。
簡易な Git-flow です。
Git 操作手順
git コマンドを使用したターミナルでの操作手順について説明します。
GUIツールを使用する場合は、各ツールのマニュアル等を参照してください。
1. プロジェクトの取得
最初に GitHub のリモートレポジトリから、自分のローカルにレポジトリを clone します。
- レポジトリにアクセス権限を割り当てられたら、GitHub の該当プロジェクトにアクセスします。(アクセス権限がない場合は
404 Not Found
となります) - 緑色の
Code
をクリックすると clone のメニューが表示されます。ssh
が選択されていることを確認し、📋アイコンをクリックしてレポジトリのパスをクリップボードにコピーします。
- Windows であれば GitBash、mac であれば ターミナル (以降、単に「ターミナル」と表記します) を開き、レポジトリをダウンロードしたいフォルダをカレントディレクトリとします。
-
git clone
と入力し、2.
でコピーした内容をペーストします。以下のようなコマンドになっていることを確認し、return を押します。
git clone git@github.com:{アカウント名}/{プロジェクト名}.git
{アカウント名}
はレポジトリ所有者の (グループあるいはユーザー) アカウント名です。
カレントディレクトリにプロジェクト名のフォルダが生成され、その配下にデフォルトブランチ (既定では master
) の内容が展開されます。
2. 機能の実装
issue の登録
機能を実装する際には GitHub の issue に実装内容を記載します。
以下の項目を入力してください。
- タイトル: 実装内容。簡素かつ具体的に
-
詳細: 実装内容を箇条書きで。
- [ ]
とするとチェックボックスになるので、タスクを箇条書きにしておくと便利 - Assignees: 担当者。自分以外を割り当てる場合は、issue 作成後にその URL を通知してあげること
-
Labels: 機能追加であれば
enhancement
、不具合修正であればbug
間違って issue を登録した場合は、その旨をコメントに記載して Close してください。
(issue の削除はできないんじゃないかな?)
作業漏れなどで一度 Close した issue を再度 Open する場合は、理由をコメントに記載してください。
ブランチの作成
以下の手順で最新の develop から featureブランチ を作成します。
git checkout develop # 現在のブランチを developに変更
git pull # リモートレポジトリと同期
git checkout -b feature/xxxxxxxx
# プレフィックス以外のレポジトリ名は任意ですが、わかりやすい英単語で(英文法として変でも構いません)
コミットとプッシュ
featureブランチ を作成したら、機能の実装を行います。
コミットのコメントは以下のルールとします。
実装の概要 #{issue番号}
(1行開ける)
実装内容を箇条書きで記載
プッシュする前に、最新を再度取得します。
git checkout develop
git pull
featureブランチ 作成時から develop に変更があった場合、以下の手順で取り込みます。
git checkout feature/xxxxxxxx
git rebase develop
rebase で CONFLICT(競合)が発生した場合、後述する 競合解決手順 の内容に従って解消してください。
rebase が完了したらリモートレポジトリにプッシュします。
git push origin HEAD
HEAD
とすることで現在のブランチをリモートレポジトリに push します。
競合解決手順
競合が発生しているファイルを確認します。
git status
該当ファイルをエディタで確認すると、競合箇所が <<<<<<<<
========
>>>>>>>>
で表示されます。
Visual Studio Code で表示すると、以下のようになります。
<<<<<<<<
の上部に競合をどのように修正するか表示されます。
それぞれ以下のような意味になります。
- 現在の変更を取り込む: ローカルの変更を残します。リモートレポジトリの内容は失われます。
- 入力側の変更を取り込む: リモートレポジトリの内容を残します。ローカルでの変更は失われます。
- 両方の変更を取り込む: ローカルの変更とリモートレポジトリの両方の変更を残します。
- 変更の比較: Visual Studio Code の DIFF表示に切り替わります。
修正が完了したらファイルを追加し、再び rebase コマンドを実行します。
git add ファイル名
git rebase --continue
すべての競合が解消されたら、リモートレポジトリに push します。
git push origin HEAD
プルリクエストの作成
ブランチを push すると GitHub にプルリクエスト作成のリンクが表示されます。
develop へのプルリクエストを作成します。
まだ作業中のプルリクエストについては、タイトルの先頭に [WIP]
と付けてください。
レビューが必要な場合は reviewer を指定してください。
3. プルリクエストのマージ
プルリクエストを受け取ったら、内容を確認して develop にマージします。
マージが完了したら、対象 issue を close します。
4. リリース
リリースする際に develop の内容を master に反映させ、タグを設定します。
master の更新
- developブランチを選択し、
New pull request
をクリック -
base: master
となっていることを確認し、タイトルにリリースバージョンを入力 (例: v1.0.0) -
Create pull request
をクリック - 競合がなければそのままマージ
タグの設定
ターミナルを起動し、以下の順でコマンドを実行します。
git checkout master
git pull
git tag -a v1.0.0 -m "2020-10-15"
git push --tags
タグにはバージョンを、タグのコメントにはリリース日付を入力します。
タグの確認
GitHub にてタグが設定されているか確認します。
ソースコードが必要であれば、ZIPでダウンロードしてください。
その他 Tips
ファイル名が文字化けする
git status
などを実行した際にファイル名が文字化けする場合、以下のコマンドを試してください
git config --local core.quotepath false
Discussion