2013-11-27 1 views
23

In einem Projekt, an dem ich gerade arbeite, behalten wir jedes Feature für sich und führen es zurück zum Master, wenn das Feature fertig ist. Die Commits in jedem Feature-Zweig können eine Menge "WIP" enthalten und die Funktionalität anderer Features unterbrechen, bis sie vollständig und stabil ist.Wie kann man "gite bisect" nur auf den Commits eines Zweigs setzen?

Wie auch immer, da die Commits des Master-Zweigs die einzigen (angeblich) stabilen sind, möchte ich git bisect nur auf diesem Zweig.

Gibt es eine Möglichkeit, git bisect nur in einem Zweig zu begrenzen?

+1

Mögliche Duplikat: http://StackOverflow.com/Questions/5638211/How-Do-You-Get-Git-Bisect-To-ignore-merged-Branches – bacar

Antwort

16

Es gibt keinen einfachen Weg, dies ohne weitere Arbeit zu erreichen. Nachdem ich eine Weile mit ihr gespielt habe, habe ich etwas, das dir helfen könnte.

git bisect start master f9d5924 

for rev in $(git rev-list f9d5924..master --merges --first-parent); do 
    git rev-list $rev^2 --not $rev^ 
done | xargs git bisect skip 

Das beginnt git bisect mit f9d5924 als gut begehen und master als schlecht begehen. Dann findet es die Vorfahren der rechten Seite jedes Merge-Commits, die nicht auf der linken Seite sind. Es übergibt diese Vorfahren an git bisect skip, um sie zu überspringen. Wenn es jedoch herausfindet, welches Commit fehlerhaft ist, zeigt es alle möglichen übersprungenen Commits des schlechten Merge-Commits an. wie die folgenden

$ git bisect good 
There are only 'skip'ped commits left to test. 
The first bad commit could be any of: 
0622204625d8817c5d8fd1a2a68b3aa91f2dcdf9 
0c771566b9e77e3bdc0a66a7404c8eae9f321a68 
5098b44f43f84b213eaab110073a6acd26a5cc02 
8b05a808d5e15852fbddaa529ba241fdac8ff693 
b0c755c3fa57e3c8d527e76fae38bc9925c01353 
We cannot bisect more! 

In diesem Fall b0c755c3fa57e3c8d527e76fae38bc9925c01353 wurde die Zusammenführung verpflichtet es gescheitert an.

EDIT: Dies wird nicht arbeiten, wenn Sie eine Oktopus Merge haben.

+3

Ich denke 'git Halbierung' braucht ein' --first "parent" Flagge, mit einer Beschreibung in der Hilfe dessen, was dazu gehört. Es würde nur die Commits durchlaufen und die Commits des tatsächlichen Zweiges zusammenfassen, und nicht seine zusammengewachsenen Zweige oder Zweigblasen. Sie würden entweder das Commit in Ihrem Zweig finden, zwischen anderen eingebettet, oder Sie würden ein Merge-Commit abschließen und wissen, dass das Problem irgendwo in dem Zweig war, der an diesem Punkt zusammengeführt wurde. –

+2

Was bedeutet "Octopus Merge"? – Kostas

+1

Wenn Sie mehr als zwei Zweige zusammenführen. Sie können mehrere Zweige zusammenfassen, wie zB 'git merge branch-one branch-two branch-three'. –

0

Ich denke, git bisect mit einer --no-parent Flagge könnte dies leicht tun, aber es existiert nicht.

Das einzige, was mir einfällt, besteht darin, nur die Verzweigung in einem neuen Zweig neu zu erstellen. Hier ist ein Beispiel in der Linux-Shell:

$ git branch bisecttemp <first> 
$ for h in `git log --oneline --decorate --first-parent --reverse --format=%H <first>..<last>`; do git checkout -f $h; sleep .5; git reset bisecttemp; git commit -am"$h"; git checkout testing; git reset --hard [email protected]{1}; done 

dass ein bisecttemp abzweigen der <first> macht commit wir interessieren, bekommt eine Liste der nur die Hashes zwischen den <first> und <last> Commits im Bereich wir kümmern uns um, Besuche je , setzt nach jedem auf den Zweig bisecttemp zurück, ohne den Arbeitsbaum zu ändern, schreibt alles anders mit dem Hash des Commits, von dem es kam, checkt bisecttemp erneut aus und setzt es dann zurück auf den letzten Platz head war, der der neue ist verpflichten.

Möglicherweise gibt es eine klügere Möglichkeit, all dies zu tun, aber die Grundlagen sind, dass es einen neuen Zweig am Anfang der Reihe von Commits erstellt, die uns wichtig sind, und dann den Status der Nur-Branch-Commits festlegt Commits und Merges, aber keine Sub-Branch-Commits) dazu, in der Reihenfolge. Sie können hier nicht einfach nur eine Auswahl treffen, da die Auswahl durch Chick-Picks auf die Eltern gerichtet ist, und das würde bei den Merge-Commits fehlschlagen.

Dies ist nicht wirklich getestet, und alles könnte falsch sein. Es ist nur ein Gedanke. Es könnte alles in einer Funktion aufgerollt werden, die eine Reihe von Commits benötigt.

-1

So verwenden Sie die Git-Halbierung auf einer Verzweigung, ohne auf Master zu überprüfen:
Seien Sie auf der Zweigstelle, die Sie testen möchten.

git bisect start --no-checkout 

Dies wird die bisect auf dem aktuellen Zweig beginnen nur

Ihre bisect normal weiter.

-1

Ich möchte auch eine richtige und native-to-git-Lösung für diese Frage, nur Prüfung Commits auf einem einzigen Zweig und damit "Schuld" eine vollständige Zusammenführung und/oder Pull-Request. Allerdings:

Da die Commits des Master-Zweigs die einzigen (angeblich) stabilen sind, möchte ich git nur in diesem Zweig teilen.

Wenn das Problem auf diese Frage aufgefordert ist, dass einige der Commits Sie sind gegeben werden gebrochen und man kann nicht testen, können Sie verwenden:

git bisect skip

Um das ganz und Check zu überspringen begehen ein anderer. Dies wird das Problem lösen, das Sie mit gebrochenen Commits haben. Sobald Sie das Commit gefunden haben, das das Feature zerstört hat, können Sie es zum Zusammenführen in den Zweig verfolgen, den Sie verfolgen.

Ich nehme an, Sie könnten sogar git bisect skip alle commits, die nicht zusammengeführt werden, entweder durch manuelle Überprüfung oder über ein Skript. Das würde das in der Frage gestellte Verhalten geben.