git運用方針 - hiroyalab/gitflow GitHub Wiki

gitの運用方針を整理

ブランチ管理

branch 用途 作業者
main 本番リリース用ブランチ直接編集不可、developからのマージのみ許可 ライブラリ管理者
develop 開発ベースブランチmainブランチを親として作成、デフォルトブランチに設定する ライブラリ管理者
ita, itb, st, etc... 検証環境用ブランチdevelopブランチを親として作成、環境依存のあるファイルは直接編集して管理する。変更の取り込みはdevelopからプルして最新を反映させる。※developへのマージはNG ライブラリ管理者
feature 個人開発ブランチdevelopブランチへマージしたfeatureブランチはリモートブランチから削除すること 開発者

gitflow

ブランチ運用

個人開発ブランチ

  • ブランチ命名規則

    プロジェクトで決めの問題だが、以下サンプル

    feature/{yyyyMM}/kondo

  • developからブランチ作成

    git checkout -b feature/202401/kondo origin/develop

  • コミットメッセージルール

    リポジトリ直下に.gitmessageを定義

    .gitmessageサンプル

    リポジトリローカルでcommit.templateを利用するように設定

    git config --local commit.template .gitmessage

    git commit -mを使用せず以下を実行すると.gitmessageに記載されたテンプレートが表示される

    git commit

    エディタが開くのでメッセージを入力し、:wqで閉じる

    gitcommit1

検証環境用ブランチ

検証環境用ブランチは環境依存の定義ファイル等があるため、developをベースにして独立したブランチとして管理する。

  1. developからブランチ作成

    例）リモートのdecelopブランチからitbブランチを作成してリモートに登録

    git checkout -b itb origin/develop
git push -u origin itb

  2. 環境依存のファイルを更新、push

    IDE等で更新、commit、push

    update

  3. リリースのタイミングなどで、developの最新を取り込む

    git pull origin develop

    ※環境依存ファイルに変更がある場合は競合(conflict)が発生するので解消する。

    環境依存はローカル優先で、それ以外はdevelopの変更を取り込む

    これもIDE等で更新、commit、push

    conflict

本番リリース運用

運用次第だが、ここではgitのタグ作成をリリースの準備作業として運用方針を記載する。

  1. mainブランチへプルリクエスト

    main ← develop

    ${\color{red}※マージ方法は「Rebase\ and\ merge」で行う事}$ （mainとdevelopのコミットログを一致させるため）

  2. mainブランチをローカルで最新化

    mainブランチをチェックアウト

    git checkout -b main origin/main

    すでにローカルにチェックアウトしてる場合はブランチを切替え

    git checkout main

    最新化

    git pull

  3. リリースタグ作成

    リモートのタグ確認

    git ls-remote --tags

    リリース単位のタグを作成して、プッシュ タグ名はv0.0.0の形式

    git tag -a ｛タグ名｝ -m "[yyyyMMdd]初期リリース"
git push origin {タグ名}

  4. リリース作成

    gitのタグからリリースの作成「Create release from tag」

    release1

    リリース情報を記載してリリース

    記載内容のフォーマットは以下参考

    ## リリース日
2024/02/14

## 対象バージョン
v1.0.0

## リリース概要
gitflowのREADMEの作成

## コミット一覧
**Full Changelog**: https://github.com/hiroyalab/gitflow/commits/v1.0.0

    Full Changelogは下図の「Generate release notes」をクリックすると自動で出来る

    release2

VSCodeでのgit利用方法

gitコマンドでの利用は個人のスキル、理解度によって運用しづらい事を考慮し、VSCodeでのgit利用方法を記載する。

  1. リポジトリのクローン

    cloneは普通にCLIで適当なディレクトリに作成する

    git clone https://github.com/hiroyalab/gitflow.git

  2. 個人ローカルブランチの作成

    クローンしたリポジトリをVSCodeで開いて

    ブランチの作成

    1. ソース管理 → メニュー → ブランチ → ブランチの作成元 vscode1

    2. リモート ブランチの作成元を指定（origin/develop） vscode2

    3. ローカル ブランチ名を記入 vscode3

    4. ブランチの変更を確認（ウィンドウの左下が現在のブランチ） vscode4

  3. 変更のコミット

    1. コミットの前に、developの最新を取り込む

      これをしておかないと、他の変更がある際にマージコミットが挟んじゃうのでやっておく

      ソース管理 → メニュー → プル、プッシュ → 指定元からプル vscode11

      プル元のリモート ブランチ（origin/develop）を指定 ![vscode12]https://github.com/hiroyalab/gitflow/wiki/(images/vscode12.png)

    2. 変更の確認してステージにあげる

      サイドメニューのソース管理で確認

      +をクリックするとステージにあげる vscode5 ステージされているファイルを確認 vscode6

    3. コミット

      .gitmessageを設定をしていない場合は実施する

      ターミナルをあげて、コマンド実行

      git config --local commit.template .gitmessage

      vscode7

      メッセージ欄を空にした状態でコミットを押下する

      COMMIT_EDITMSGが開かれるのでコミットメッセージを入力し、Ctrl+sで保存してタブを閉じてコミット完了 vscode8

    4. リモート ブランチへプッシュ

      コミットが完了するとBranch の発行ボタンが出るので押下

      初回以降は変更の同期ボタンになる vscode9

      リモートのgit上にブランチが作成されていることを確認 vscode10

リポジトリ設定(settings)

gitリポジトリの設定。（ライブラリ管理者向け）

個人開発用のGitHubリポジトリで設定した項目たち

General（基本設定）

  • Default branch

    develop

  • Features

    Features 利用 概要
    Wikis ON ウィキ。README以外に使う感じ
    Issues ON 問題ページ
    Sponsroships OFF スポンサー？使わない
    Preserve this repository OFF gitの保存。いらない
    Discussions OFF ディスカッション。いらない
    Projects OFF プロジェクトの連携？。いらない

  • Pull Requests

    種別 利用 概要
    Allow merge commits ON マージコミットを入れるやつ
    Allow squash merging OFF スカッシュ。よくわからんので無効
    Allow rebase merging ON リベースしてコミット。mainとdevelopのコミットログを合わせたいので有効

    GithubでのWeb上からのマージの仕方3種とその使いどころ

  • Always suggest updating pull request branches 有効

    PRを作成してからベースブランチに新たに変更が入った場合、画面上に「ブランチを更新する」ボタンが表示されるようになります。

  • Allow auto-merge 無効

  • Automatically delete head branches 有効

    プルリクエストマージ後に作業ブランチを自動で削除します。

Branch protection rules（ブランチルール）

GitHub Branch protection rulesの機能一覧

項目 小項目 説明 main develop ita, itb, etc…
Require a pull request before merging マージする前に、プルリクエストを要求する ○ ○ ○
Require approvals プルリクエストにおいて、承認（approval）を要求する ○ ○ ○
Dismiss stale pull request approvals when new commits are pushed 新しいコミットがプッシュされたときに古い承認を取り消す ○ ○ ○
Require review from Code Owners Code Ownersによるレビューを要求する - - -
Restrict who can dismiss pull request reviews プルリクエストのレビュー（変更を要求するレビュアによる承認を必要とする状態）を却下できる人を制限する - - -
Allow specified actors to bypass required pull requests 指定したユーザーに対し、プルリクエストの要求を課さない - - -
Require approval of the most recent reviewable push Approvalを得た後にプッシュされた変更がある場合は、approvalを要求する 最後のレビュー可能なpushを行った人以外からのapprovalを要求する - - -
Require status checks to pass before merging マージする前に、status checkをクリアしていることを要求する ○ ○ ○
Require branches to be up to date before merging マージする前に、作業ブランチが最新（マージ先のブランチの変更が取り込まれている）であることを要求する ○ ○ ○
Require conversation resolution before merging マージする前に、プルリクエストのconversation（コメント）が解決されていることを要求する - - -
Require signed commits 署名付きのコミットを要求する - - -
Require linear history 履歴の分岐を許さない - - -
Require merge queue マージキューを要求する - - -
Require deployments to succeed before merging マージする前に、deploymentsが成功することを要求する - - -
Lock branch ブランチをロックする（プッシュを禁止する） - - -
Do not allow bypassing the above settings （管理者とカスタムロールで"bypass branch protections"の権限を持つユーザーに対し）上記の設定のbypassを許さない - - -
Restrict who can push to matching branches 対象のブランチに対し、pushできる人を制限する - - -
Restrict pushes that create matching branches 命名規則が合致するブランチの作成ができる人を制限する - - -
Allow force pushes force pushを許す - - -
Allow deletions ブランチの削除を許す - - ○

参考