Git運用中に困ったので正しい回答が欲しくメモしておく。
今レポジトリupstream, originがあるとする。
問題
originは常にupstreamに少し変更を加えたものだったので、
常時cronでgit mergeしていた。しかし今日初めて
「upstreamのレポジトリにはpushしたいけど、それがoriginに取り込まれては困る」
というコミットが成されてしまった。
試したこと１
git cherry-pickでそれ以外のコミットを取り込む。
しかしこれでは常にcherry-pickしなければupstreamでの変更を
取り込むことが出来なくなった。
試したこと2
git mergeしたのち、git revert 該当するコミットで変更分を取り戻す。
しかしこのあと該当するブランチとgit mergeしようとすると
その差分を取り込もうとしてしまった。
てっきり私は一度合流してそれを差し戻すコミットをすれば gitは差し戻された状態がただしいのだと判断してくれると思っていたのだが。
解答（？
極めて疑問なのだが以下のような方法で修正は反映せず
git mergeしてもそれが取り込まれなくなった。
git mergeをして、マージコミットをまだしないgit revert 該当するコミットを行う- ここでやっとコミットする
これでなぜ出来て上では駄目なのか全くわからない。が、上手く言っているようだ。
そもそも運用がいびつだというのは理解していて、これは
政治的なアレが原因なのでどうしようもない。
しかしなぜこれで上手く言っているのか分からないし不安である。。。。。。
追記：でこ先生・よんたさんのツイート
git merge -s で merge strategy をいい感じに指定すればいけないかと思うけど使ったことない
— でこれき (@dico_leque) 2017年1月26日
Three-Way Merging: A Look Under the Hood | Dr Dobb's https://t.co/6rS2Tr7Cyi
— でこれき (@dico_leque) 2017年1月26日
『入門Git』（秀和システム）の「2.8.2 3-way マージの社会的前提条件」（マージ対象のブランチの変更がどちらもプロジェクトの達成したい目標に近付くのに役立つ等）を満たさないブランチたちをマージで運用していこうとすると不幸になるんだろうなあという雰囲気で使ってる
— でこれき (@dico_leque) 2017年1月26日
それ。目的が違うけど同じコミットを共用するプロジェクトをgit運用するのはけっこう大変。別gitレポジトリにして気合のチェリーピックなりで取り込みするか、rebaseを魔法のように使って管理するか…。むーん。
— よんゴジラ (@keita44_f4) 2017年1月26日
大変なので、上司が似た別物2つに分けようとするのを、絶対に反対してるマンです。
— よんゴジラ (@keita44_f4) 2017年1月26日
きょんさんのツイート
@no_maddo さっきのやつですが、mergeではなくて、pull --rebaseをつかえばやりたいことができるかと思います。
— きょん＠うさみみモード (@kyon_mm) 2017年1月26日
@no_maddo origin側では通常は常にpull --rebaseでおこなってpatchをあてなおすようなグラフをたもっておきます。そして、こんかいのようなrevertしたいコミットがあるばあいには、pull --rebaseをしてからrevertをします。
— きょん＠うさみみモード (@kyon_mm) 2017年1月26日
@no_maddo おそらくrevertのときにコンフリクトするとおもいますが、それはふつうになおしてください。revertコマンドが完了してコミットが生成されてしまえば、以降のupstreamからの反映はpull --rebaseだけで完結します。
— きょん＠うさみみモード (@kyon_mm) 2017年1月26日
@no_maddo originはupstreamに対してつねに何かのパッチをあてておく。という目的かとおもい、この案を考えました。その場合にはgitではrebaseをつかっていくのがやりやすいです。違う目的の場合とかこれだと達成できなさそうであれば、もうすこし情報もらえれば。
— きょん＠うさみみモード (@kyon_mm) 2017年1月26日
