Lycolog

シンプルで事故が起き辛いGitのブランチフローを考えて実務で運用した話

投稿日：: 2022/03/09

ソフトウェア::Git開発::設計開発::自動化

これは、かつて参画したGitHubを利用したプロジェクトでブランチフローが悪く事故が多発したので考案し、運用した内容です。
基本的には後々の運用を考えた時に情報源になり、かつGit操作に極力手間を取られることがなく、CI/CDを回しながら品質を維持できる内容で考えています。

フローの要件として考えたこと

取り回しが単純明快であること

開発以外の要素に振り回されないように単純なフローにしていて、世に言われる履歴の綺麗さとか言うのは個人的には関心が薄いので重視していません。その代わりコミットが壊れないことや、インデックスとして見やすくなるような部分を重視しています。

まず個々の開発タスクをIssueベースで管理し、Pull Requestベースで取り込む運用としました。
Pull Requestの取り込み方式はSquash Mergeとし、メインブランチのコミット履歴がPull Requestのマージコミットになるようにしました。
これはメインブランチのコミット履歴はPull Requestのマージコミットだけあれば後から追えるというのと、メインブランチのコミットログを単純にする意味でこの方式にしています。

CI/CDを活用しやすいこと

これは割とどこでもやっていると思いますが、ブランチ名にdevelopとかstaging, productionとか付けて管理することで、自動的に環境を識別できるようにしました。

実際に運用したフロー

フロー図

フローの運用内容

develop/mainブランチを最新ブランチとする運用
- develop/mainブランチ相当のものが複数ある状態というのが世の中にあると思いますが、管理が非常に大変なのでそれはしない方向にしました
機能ブランチをdevelop/mainブランチに取り込むのはSquash Merge
- 基本的に変更履歴を見る時はGitLensやblameで変更行からPull Requestを当てて、そこを見に行くという運用にしていました
機能ブランチにdevelop/mainブランチを取り込むのはmerge
- 一般的にはrebaseが多いと思いますが、次の観点から採用しませんでした
  - どのポイントで取り込んだのかわからない
  - mergeと比較した場合にコンフリクト対応に手を取られる
    - 経験上ここで事故が頻発する
  - 素直にpush出来ない
- mergeであれば以下のように単純な流れに出来ますし、push前に差分確認して事故を防ぐことも容易です
  - git switch develop/main
  - git pull
  - git switch -
  - git merge -
  - コンフリクトがあれば解消
  - git push
デプロイ方式によるルートブランチ分割
- ルートブランチ名によってデプロイ先を変更できるようにしました
- GitHub Actionsでブランチ名を拾って環境変数を差し替えることでデプロイするワークフローを組んでいます
- staging/やproduction/ブランチはdevelop/mainからcheckoutする運用です
  - これらはデプロイするためだけの使い捨てブランチなので毎回生えます

あとがき

このフローの利点としてはマージでコンフリクトが起きても基本的にCurrentとIncomingを一回比較するだけで済むのでコンフリクトの解消が簡単で、コンフリクト時はIncomingが壊れないようにCurrentを直すのが基本になり、Currentを優先する場合は適宜上書きするといった内容です。

ブランチの合流はmergeだとマージコミット分一回の解消だけでいいので事故の発生要因が低いのがrebaseと比較した時の利点です。rebaseだとコミット回数分再帰的に合流させる必要があるのでブランチの寿命が長かったりすると苦行になってきます。

このフローができた経緯としては元々はGitHub Flowをベースにしていたのですが、色々やっていくうちにこうしたらもっと良くなるのではないか？というのを試行錯誤していてこの形に落ち着いたのですが、後から調べたらGitLab Flowに近い形式に見えたので、似た内容は既に誰かが考えているものだなと感じました。

上で挙げた内容の他にもGitHubのリポジトリ設定でブランチ保護のルールを設定したり、Pull Requestのマージ設定でSquash mergingだけ許可したり、ヘッドブランチの自動削除をするなど、基本的に面倒なことを考えたり、しなくて良い様にするなど、開発に注力しやすいように環境を整えると心理的な抵抗が少なく運用できて便利だなと感じています。

コメント（0件）

MSYS2でzshのGitプロンプトを快適に使う方法

投稿日：: 2022/02/13

ソフトウェア::MSYS2ソフトウェア::Gitソフトウェア::zsh

MSYS2でzsh使いたくない？使いたいよね？そう、使いたい！
しかしその上で一つ大きな障害があります
MSYS2のzshでプロンプトにGitのブランチを表示させようとすると微妙に上手くいきません

問題

.zshrcを使ってPROMPTに現在のGitブランチの状態を表示させようとするとフリーズするケースがあります
具体的には以下のような設定を書くとターミナルのサイズ変更時にシェルがフリーズします
原因は不明ですがPROMPT='$(git)'だけでフリーズするのでGit for Windowsとの相性がなにか良くないのだと思っています

# git functions

current_git_branch() {
  (git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1/')
}

parse_git_dirty() {
  local DIRTY=$(git status -s | tail -1)
  if [[ -n $DIRTY ]]; then
    echo "%{$fg_bold[magenta]%})%{$fg_bold[red]%}✗"
  else
    echo "%{$fg_bold[magenta]%})%{$fg_bold[blue]%}✓"
  fi
}

print_git_prompt() {
  local FIND_BRANCH=$(git branch 2> /dev/null | tail -1)
  if [[ -n $FIND_BRANCH ]]; then
    echo "%{$fg_bold[magenta]%}(%{$reset_color%}%{$fg_bold[yellow]%}"$(current_git_branch)$(parse_git_dirty)" %{$reset_color%} "
  else
    echo ""
  fi
}

# setting propmt

PROMPT="
%{$fg_bold[cyan]%}%n%{$reset_color%}%{$fg_bold[blue]%}@%m%{$reset_color%}:%{${fg_bold[green]}%}%~%{$reset_color%}
%(?:%{$fg_bold[green]%}➜:%{$fg_bold[red]%}➜)  %{${reset_color}%}"'$(print_git_prompt)'

RPS1="%(?..%{$fg_bold[red]%} [ %? ]%{$reset_color%}) %D - %*"

解決策1

プロンプト表示に使うgitバイナリだけmsys2の物に差し替えると上手くいくようになります
具体的には以下のようにしてGit for Windowsと競合しないようにMSYS2のGitを構成しPROMPT='$(msys2_git)'のように呼び出してやると上手くいきます

pacman -S git
mv /usr/bin/git /usr/bin/msys2_git

課題

msys2/gitをアップデートするときに毎回リネームをする必要がある
ここが面倒で脆弱性に繋がる可能性がゼロではない

解決策2

Git for Windowsだけでやる場合の方法です
add-zsh-hook precmdでプロンプトに出したいコマンドを呼び出し、変数の値を書き換えてそれを表示するスタイルでやると上手くいきます

課題

プロンプトの速度が遅い
プロンプトする時に一瞬フォーカスが飛ぶ（別プロセルがコールされ一瞬窓ができている気がする