ビジネス ニーズと古い習慣の組み合わせにより、QA/BA チームのメンバーは、リリース時に潜在的なリリース候補の開発作業の任意の組み合わせを選択する能力が必要であると考えているようです。現時点では、revert と revert revert コミット、および「コメント アウト」と「コメント解除」のコミットに関して、多くの git の「傷跡」が残っているため、これは心配です。(悲しいことに: darcs では、これは与えられたツールでもう少し簡単に達成できますが、もちろん、git を使用している darcs を使用していません。) 昨日いくつかの調査を行っているときに、機能ごとにブランチに出くわしました。(BPF) ワークフロー自動化の取り組みと、「完全な分離、完全な統合」(TITI) を維持するためのプロセス。今、私は私たちの職場環境に似たようなものを実装できるかどうかを理解しようとしています. （QA / BA構造に自動化をどのように潜在的に反映させることができるかという他の質問は言うまでもありません...）
BPF の TITI プロセスは共有 git rerere キャッシュに大きく依存しているため、使い捨てブランチまたは統合ブランチで統合マージを実行できますが、リリース候補 (QA) ブランチを構築するときのチェリー ピッキング プロセスには再利用できます。ここで特に重要なのは、ソース ブランチを完全に分離したままにするために、「ソース」ブランチにマージしないことです。そのため、統合マージとして GitHub PR を使用しているワークフローで、それがどのように機能するかを理解しようとしています。明らかに、PR は現在複雑なマージを許可しておらず、現在のワークフローはソース ブランチでのマージの競合を修正することですが、BPF を試した場合、分離の原則に違反することになります。理論的には、使い捨てのマージ手法を実行できますが、rerere キャッシュを共有するために GitHub をどのようにセットアップしますか?
TL;DR:共有された rerere を処理し、GitHub のプル リクエストを引き続き使用するための最良の方法は何ですか?
(余談: 現在、これを行う必要があるのはリポジトリの 1 つだけであり、そのリポジトリは現在 GitHub for Enterprises のオンプレミスでホストされているため、SSH アクセス権を持つ管理者に git をハッキングするよう説得できる可能性がわずかにあります。そのリポジトリのマシンで config を実行して、共有 rerere と auto-rerere をオンにします. しかし、そのようなハックに頼ることには多くの脆弱性があり、他のビジネス ユニットから、なぜ私たちが行っていることを実行できないのかという疑問が生じる可能性があります.パブリック GitHub と、潜在的な GitHub の更新の問題だけでも、git 構成のハックを壊す可能性があります。そもそもそれらが機能することを前提としています...)