- 社内でmono-repositoryを使い始めて4か月目
- mono-repositoryといえばついて回るキーワードであるtrunk-based developmentもあわせて適用中
- trunk-based development戦略に従ってmainブランチにコミットし、releaseブランチにcherry-pickするフローを使っている
- LinkedIn技術ブログの内容をもとにGitHub Actionを構成したが、CONFLICTを自動で解決することはできない。CONFLICTが発生した場合、ユーザーがlocalで直接
git cherry-pickコマンドを実行する必要がある
- この
cherry-pickコマンドを支援するghプラグインを自作してみた
使い方
gh cherry-pick -pr <pr_number> -onto <target_branch> [-merge auto|squash|rebase] [-push]
-mergeオプションでPR merge commitをcherry-pickするか、PRの元のcommit群をcherry-pickするかを選べる
- 指定しない、または
-merge=autoオプションを使うと、PRがmergeされた戦略を自動でinspectして適用してくれる
-pushオプションで、cherry-pick成功時に自動でremote pushできる
所感
- 外部プロセスや状態と継続的に相互作用するプログラムを開発しながら、別途テストリポジトリを作ってTest Datasetを生成した
- CLI体験を良くするためのさまざまな学習
- docker-cliを一人で作ってみるための勉強が役立った
- 思った以上にCLIプログラムを作るには多くの工数がかかる
- パイプライン形式で多くの状態値を管理すること
- ユーザーに直感的なinput interfaceを提供すること
- input validationをできるだけ早い段階で提供すること
- ユーザーのシステムを元の状態に復元すること など
- 1日程度で作れると見込んでいたが、完成までに約5日かかった（GitHub Actions Workflow改善のための開発も並行して進めていたとはいえ、それでも予想よりはるかに多くの時間を要した）
4件のコメント
こんにちは〜 main(trunk) ブランチにマージされたコミットを revert する必要がある場合、どのように対応されていますか？
コミットがたくさん積み重なっていてコンフリクトが発生すると、チェリーピックが難しいケースもあると思うのですが、そのようなケースに対応された経験があるか気になります！
こんにちは。コメントいただきありがとうございます！
Main ブランチに revert PR を出す際に cherry-pick を指定しています。元の PR リンクに cherry-pick の履歴がすべて残っているため、追跡が難しいことはありません。別途、機械的なチェックは行っていません（笑）
まず、trunk-based development を行っていると各 PR が小さな単位になるため、コンフリクトはあまり頻繁には起きません。もしコンフリクトが発生した場合は、手作業でコードを書く必要があります。release を高頻度で行い、あまりに古いバージョンのサポートを素早く deprecate することで、コードの形が大きく変わってしまう現象を避けています。
なぜこれが必要なのか、あまりよく理解できない戦略ですね…。
release-from-trunk で紹介されている内容を読んでみると、理解の助けになるかもしれません（笑）