0

私たちの git プロセスには、機能ブランチから機能を開発にマージすることが含まれ、安定したら、これらは master にマージされます。

機能にバグが見つかった場合、そのブランチは開発から戻され、最終的に何が master になるかを把握するのが少し難しくなります。

私は、開発中のマージ (元に戻されていない) のリストを生成する単純なシェル スクリプトを考えていましたが、マスターではありませんが、これを生成する方法がわかりません。基本的な git と bash を使用して実行できることはわかっているので、ポインタをいただければ幸いです。

アップデート：

ここの答えから、私は何かに近いものを得ることができました：

git rev-list release_2013_05_20 --not master --merges | xargs -L1 git name-rev | grep -oE '[0-9a-f]{40}\s[^\~\^]*'

ただし、機能が元に戻されてから再びマージされた場合、これは複数のエントリを示しています。

4

1 に答える 1

1

あなたの歴史はどのような形をしており、何をしようとしていますか? あなたの説明から、私がこれまでに理解したのは次のとおりです。

ブランチからのブランチに誤ったマージ コミットMがあります(heads commits: , ):developmenttopicAB

 ---o---o---o---M---x---x
               /
       ---A---B

そして、あなたはこれを得るためにそれを元に戻します$ git revert -m 1 M:

 ---o---o---o---M---x---x---W
               /
       ---A---B

topic次に、ブランチとdevelopmentブランチにさらに変更を加えます。

 ---o---o---o---M---x---x---W---x
               /
       ---A---B-------------------C---D

そして、成熟したと感じたときdevelopmentのようにマージして戻します。M2

 ---o---o---o---M---x---x---W---x---M2
               /                     \
       ---A---B-------------------C---D

Mここで、対応するコミットがないすべてのコミットを見つけたいと思いWますよね? これを行う唯一の方法は (完全な一般性を前提として)、実際に のパッチ テキストを取得し、Mそれが のパッチ テキストの逆であることを確認することですW。Wは単なる通常のコミットであるため、すべてのコミットを調べて、ブランチ全体でその前にあるすべてのマージ コミットと比較する必要があります。他にどのようにこのクラスターファックを処理しますか?

---o---o---o---M1---x---x---M2---x---x--W1---M3---x---W3---x
               /             \                \
       ---A---B-----------C---D------------E---F

あなたのワークフローが壊れていること、そしてやり方を変えなければならないことを、私は決定的に証明しましたか? 今すぐ読んgitworkflows(7)で、この災害について考えてみてください。

于 2013-06-07T20:38:03.303 に答える