@kyanny's blog

My thoughts, my life. Views/opinions are my own.

最近困っていること

仕事で使ってる Git リポジトリのいくつかは git-flow 的なブランチ運用ルールを採用しており、トピックブランチは原則として develop ブランチにマージしている。また、月曜から木曜まで当番制でプラットフォームの主要アプリケーションのリリース作業(テストシナリオにそってテストを実施し develop ブランチを master ブランチにマージ)を行っている。という状況で最近困っているのが、誤マージしたと勘違いして焦ること。

レビューというのは集中を要する作業なので、 ok だったときは反動で気が抜けてしまう。上記のルールを破らないように、 target ブランチが正しいかもレビューの一環としてしっかりチェックしているのだが、気が張っているのはマージボタンを押すまでで、押してしまったら脱力してボーッとしてしまう。のだが目は知らずのうちにマージコミットの

f:id:a666666:20151019161527p:plain

みたいなやつを見ており、しかし頭はボーッとしてるので、そのリポジトリが git-flow 的なルールだったかどうかまでは判断できず、条件反射的に「やべっ!うっかりして master に向いた Pull Request をマージしちゃったか!?」とびびる。このときお腹が破裂してうんこを漏らしそうなショックを感じるので、毎度寿命が縮む思いをしてしまう。

それと似た別パターンとして、デイリーリリース作業中のマージにも神経を使う。テストを実施する環境は develop ブランチの最新版が継続デプロイされているので、テスト中に develop ブランチに向いた Pull Request をマージしてしまうと、タイミング次第で十分にテストされていない変更が master ブランチにマージされてしまう可能性がある。なのでリリース作業中は develop へのマージを避ければいいのだが、上述のものと合わせると、リリース作業と無関係のリポジトリのレビュー後であっても、

  1. リリース作業中のうっかりマージをやらかしてしまったか!?
  2. リリース作業には影響しないけど master ブランチのうっかりマージをやらかしてしまったか!?

という二重のうんこショックを受けてしまい、ものすごく心臓に悪い。というのが最近の悩み。伝わる気がしない。そのうちほんとにうんこを漏らす気がして不安。

GitHub のマークアップをみると <span class="css-truncate-target">master</span> みたいになっていて、属性値ではどのブランチか判定できないので、ユーザースタイルシートで安全か否か判定して色を変える、みたいなのもできない。ユーザースクリプト(拡張)は大げさでセットアップも面倒だけど、心身の平穏と社会生活上の尊厳を守るために自衛手段を用意したほうが賢明かもしれない。