Wie schließe ich einen Feature-Zweig in Mercurial korrekt?


240

Ich habe die Arbeit an einem Feature-Zweig beendet feature-x. Ich möchte die Ergebnisse wieder in der defaultVerzweigung zusammenführen und schließen feature-x, um sie in der Ausgabe von zu entfernen hg branches.

Ich habe mir das folgende Szenario ausgedacht, aber es gibt einige Probleme:

$ hg up default
$ hg merge feature-x
$ hg ci -m merge
$ hg up feature-x
$ hg ci -m 'Closed branch feature-x' --close-branch

Der feature-xZweig (changests 40- 41) ist also geschlossen, aber es gibt einen neuen Kopf , den Änderungssatz für den schließenden Zweig 44, der hg headsjedes Mal aufgelistet wird:

$ hg log ...
o  44 Closed branch feature-x
|
| @  43 merge
|/|
| o  42 Changeset C
| |
o |  41 Changeset 2
| |
o |  40 Changeset 1
|/
o  39 Changeset B
|
o  38 Changeset A
|

Update : Es scheint, dass Mercurial seit Version 1.5 keine Köpfe geschlossener Zweige mehr in der Ausgabe von hg headsanzeigt.

Ist es möglich, einen zusammengeführten Zweig zu schließen, ohne einen weiteren Kopf zu hinterlassen? Gibt es eine korrektere Möglichkeit, einen Feature-Zweig zu schließen?

Verwandte Fragen:


@Andrey: aber der Artikel, auf den hingewiesen wird, spricht NICHT nur über "--close-branch". Es werden vier Möglichkeiten gezeigt, wie Sie Ihren Zweig beschneiden können. Wenn Sie es wirklich nicht mehr wollen, können Sie wie im Artikel beschrieben klonen. Das einzige "Problem" ist, wenn Sie es aus irgendeinem Grund schließen und dennoch behalten möchten.
SyntaxT3rr0r

1
@WizardOfOdds Ja, ich habe den gesamten Artikel über das Beschneiden toter Zweige gelesen. Ich möchte, dass der Zweig in der Revisionshistorie bleibt und nicht weggeworfen wird. Zuvor habe ich nur Feature-Zweige zusammengeführt, defaultohne sie zu "schließen". Es führte zu 0 neuen Köpfen, aber solche Zweige waren für hg branchesimmer sichtbar (als inaktive Zweige).
Andrey Vlasovskikh

Um Features zu entwickeln, neige ich dazu, das gesamte Repository zu klonen und es dann wieder zusammenzuführen, sobald das Feature fertig ist. Ich mag es nicht, die Überreste von (geschlossenen) Zweigen in der Geschichte zu haben.
DanMan

Antworten:


218

Eine Möglichkeit besteht darin, zusammengeführte Feature-Zweige offen (und inaktiv) zu lassen:

$ hg up default
$ hg merge feature-x
$ hg ci -m merge

$ hg heads
    (1 head)

$ hg branches
default    43:...
feature-x  41:...
    (2 branches)

$ hg branches -a
default    43:...
    (1 branch)

Eine andere Möglichkeit besteht darin, einen Feature-Zweig vor dem Zusammenführen mit einem zusätzlichen Commit zu schließen:

$ hg up feature-x
$ hg ci -m 'Closed branch feature-x' --close-branch
$ hg up default
$ hg merge feature-x
$ hg ci -m merge

$ hg heads
    (1 head)

$ hg branches
default    43:...
    (1 branch)

Der erste ist einfacher, hinterlässt aber einen offenen Zweig. Der zweite hinterlässt keine offenen Köpfe / Zweige, erfordert jedoch einen weiteren zusätzlichen Commit. Man kann das letzte tatsächliche Commit für den Feature-Zweig mit diesem zusätzlichen Commit kombinieren --close-branch, aber man sollte im Voraus wissen, welches Commit das letzte sein wird.

Update : Seit Mercurial 1.5 können Sie den Zweig jederzeit schließen, sodass er nicht mehr in beiden hg branchesund hg headsnicht mehr angezeigt wird. Das einzige, was Sie möglicherweise ärgern könnte, ist, dass das Revisionsdiagramm technisch noch eine weitere Revision ohne Kinder enthält.

Update 2 : Seit Mercurial 1.8 sind Lesezeichen zu einem Kernmerkmal von Mercurial geworden. Lesezeichen sind für die Verzweigung bequemer als benannte Verzweigungen. Siehe auch diese Frage:


2
Es ist nicht unbedingt wahr, dass Bookmarks are more convenient for branching than named branches. Hg-Lesezeichen sind nicht dasselbe wie Git-Zweige. Sie sind voll von vielen Randfällen, die sie als Feature-Zweige ungeeignet machen. Beispiel: Wenn Sie ein Repository klonen, erhalten Sie das neueste Commit in der defaultVerzweigung. Wenn Sie Lesezeichen verwenden, entspricht dieser Änderungssatz einem zufälligen (instabilen) Lesezeichen. Wenn Sie benannte Zweige verwenden, erhalten Sie das neueste Commit im stabilen / Standardzweig, was normalerweise gewünscht wird. Lesezeichen werden eines Tages dort ankommen, aber sie sind noch nicht da.
Gili

Ich verwende Lesezeichen als private Tags, die nur in meinem lokalen Repository sichtbar sind. Sie erinnern mich an Änderungssätze, die ich noch einmal besuchen muss.
Gili

Ich habe versucht, diesem Ansatz zu folgen, erhalte jedoch immer noch eine Fehlermeldung, wenn ich versuche, Folgendes zu tun : abort: push creates new remote branches:. Was hätte ich falsch machen können?
Kasperd

79

Imho gibt es zwei Fälle für Filialen, deren Schließung vergessen wurde

Fall 1: Zweig wurde nicht in den Standard zusammengeführt

In diesem Fall aktualisiere ich den Zweig und führe ein weiteres Commit mit --close-branch durch. Leider wählt dies den Zweig zum neuen Tipp. Bevor ich ihn an andere Klone weitergebe, stelle ich sicher, dass der echte Tipp einige weitere Änderungen und andere erhält Sei nicht verwirrt über diesen seltsamen Tipp.

hg up myBranch
hg commit --close-branch

Fall 2: Zweig wurde in Standard zusammengeführt

Dieser Fall unterscheidet sich nicht wesentlich von Fall 1 und kann gelöst werden, indem die Schritte für Fall 1 und zwei weitere Schritte reproduziert werden.

In diesem Fall aktualisiere ich das Zweig-Änderungsset, führe ein weiteres Commit mit --close-branch durch und füge das neue Änderungsset, das zum Tipp wurde, zum Standard zusammen. Die letzte Operation erstellt einen neuen Tipp, der sich im Standardzweig befindet - HOORAY!

hg up myBranch
hg commit --close-branch
hg up default
hg merge myBranch

Hoffe das hilft zukünftigen Lesern.


3
Gute klare Antwort für einen Mercurial-Neuling wie mich. Und danke, dass Sie "ci" nicht verwenden, das nicht als einer der Befehle von hg help aufgeführt ist, also weiß ich nicht, was es bedeutet :)
MB.

8
@MB.: In solchen Fällen hg help ciwird es Ihnen erklären.
Chris Morgan

Ich glaube, wie der Befehl 'hg merge' Ihnen sagen wird, gibt es am Ende noch ein Commit
Chip Grandits

11

BEARBEITEN autsch, zu spät ... Ich weiß, dass Sie Ihren Kommentar gelesen haben, der besagt, dass Sie das Feature-x-Änderungsset beibehalten möchten, sodass der Klonierungsansatz hier nicht funktioniert.

Ich werde die Antwort hier immer noch zulassen, denn sie kann anderen helfen.

Wenn Sie "Feature X" vollständig entfernen möchten, weil es beispielsweise nicht funktioniert hat, können Sie klonen. Dies ist eine der im Artikel erläuterten Methoden, die funktioniert und speziell über Köpfe spricht.

Soweit ich weiß, haben Sie dies und möchten den "feature-x" -Kopf ein für alle Mal loswerden:

@    changeset:   7:00a7f69c8335
|\   tag:         tip
| |  parent:      4:31b6f976956b
| |  parent:      2:0a834fa43688
| |  summary:     merge
| |
| | o  changeset:   5:013a3e954cfd
| |/   summary:     Closed branch feature-x
| |
| o  changeset:   4:31b6f976956b
| |  summary:     Changeset2
| |
| o  changeset:   3:5cb34be9e777
| |  parent:      1:1cc843e7f4b5
| |  summary:     Changeset 1
| |
o |  changeset:   2:0a834fa43688
|/   summary:     Changeset C
|
o  changeset:   1:1cc843e7f4b5
|  summary:     Changeset B
|
o  changeset:   0:a9afb25eaede
   summary:     Changeset A

Also machst du das:

hg clone . ../cleanedrepo --rev 7

Und Sie werden Folgendes haben, und Sie werden sehen, dass Feature-x tatsächlich weg ist:

@    changeset:   5:00a7f69c8335
|\   tag:         tip
| |  parent:      4:31b6f976956b
| |  parent:      2:0a834fa43688
| |  summary:     merge
| |
| o  changeset:   4:31b6f976956b
| |  summary:     Changeset2
| |
| o  changeset:   3:5cb34be9e777
| |  parent:      1:1cc843e7f4b5
| |  summary:     Changeset 1
| |
o |  changeset:   2:0a834fa43688
|/   summary:     Changeset C
|
o  changeset:   1:1cc843e7f4b5
|  summary:     Changeset B
|
o  changeset:   0:a9afb25eaede
   summary:     Changeset A

Ich habe vielleicht falsch verstanden, was Sie wollten, aber bitte nicht modifizieren, ich habe mir Zeit genommen, Ihren Anwendungsfall zu reproduzieren :)


7

Es ist seltsam, dass noch niemand die robusteste Methode zum Schließen von Feature-Zweigen vorgeschlagen hat ... Sie können Merge Commit einfach mit dem Flag --close-branch kombinieren (dh geänderte Dateien festschreiben und den Zweig gleichzeitig schließen):

hg up feature-x
hg merge default
hg ci -m "Merge feature-x and close branch" --close-branch
hg branch default -f

Das ist also alles. Niemand extra Kopf auf Revgraph. Kein zusätzliches Commit.


Ich habe es in meiner Antwort erwähnt: "" Man kann das letzte tatsächliche Festschreiben für den Feature-Zweig mit diesem zusätzlichen Festschreiben mit --close-branch kombinieren, aber man sollte im Voraus wissen, welches Festschreiben das letzte sein wird. " "
Andrey Vlasovskikh

OK, ich verstehe. Ich verstehe den letzten Teil des Satzes einfach nicht ganz ("aber man sollte es wissen ..."), also dachte ich, dass es etwas anderes bedeutet. Außerdem möchte ich darauf hinweisen, dass diese Methode von den meisten GUI-Tools (TortoiseHG, SourceTree usw.) nicht unterstützt wird.
bis

@AndreyVlasovskikh Der Sinn dieser Antwort besteht darin, den Zweig beim Zusammenführen und nicht beim letzten Festschreiben des Feature-Zweigs zu schließen.
Kasperd

@tav Bevor Sie den mergeBefehl ausgeben, sollten Sie hg branchüberprüfen, ob der Zweigstellenname der Zusammenführung derjenige ist, den Sie offen halten möchten.
Kasperd

2
Bei näherer Betrachtung scheint die Zusammenführung immer auf dem geschlossenen Zweig zu sein. Das gewünschte Ergebnis wäre, dass es sich auf dem Zweig eines seiner Elternteile befindet und den Zweig seines anderen Elternteils schließt. Das scheint nicht möglich zu sein. Das sieht also doch nicht nach einer praktikablen Lösung aus. Schade, ich wollte unbedingt eine Zusammenführung als Abschlusspunkt eines Zweigs verwenden.
Kasperd
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.