GIT nach merge branch und remove
-
ich habe im origin einen branch nach master gemerged ( über den gitlab mergerequest ) und dort den branch auch enden lassen.
Nun bin ich aber lokal immer auf dem letzten stand des branches. D.h. lokal ist der nicht weg. Das ist natürlich eine ziemlich heiße angelegenheit, wenn man das projekt nach einem jahr pause dann mal wieder angeht und vielleicht vergessen hat, dass der lokale branch eigentlich gar nicht mehr existiert.Was ist da die "übliche" Vorgehensweise, um Missverständnisse zu vermeiden? Direkt nach dem Merge Master auschecken?
-
Ich lösche den Branch bei sowas dann anschließend auch lokal:
git branch -d <branch_name>
-
Keine Ahnung was üblich ist. Aber wenn ich nach einem Jahr anfange wieder an etwas zu arbeiten, dann schau ich normalerweise schon auf welchen Branch ich bin. Und wechsel dann zu dem Zeitpunkt ggf. auf master zurück.
Davon abgesehen halte ich es für klug nach dem merge lokal auf master zurückzuwechseln und zu "pullen". Den lokalen Branch kann man dann auch löschen. Oder auch nicht, wenn man meint ihn sich aus bestimmten Gründen aufheben zu wollen.
-
Ok. Die Kombination aus beidem macht für mich am meisten Sinn.
Danke euch beiden
-
@It0101 sagte in GIT nach merge branch und remove:
Das ist natürlich eine ziemlich heiße angelegenheit, wenn man das projekt nach einem jahr pause dann mal wieder angeht und vielleicht vergessen hat, dass der lokale branch eigentlich gar nicht mehr existiert.
Noch eine blöde Frage dazu: Normalerweise macht man ja erstmal nen pull wenn man nach langer Pause wieder an ein Projekt drangeht. Dabei fällt einem dann üblicherweise auf dass der Branch weg ist, man bekommt ja dann beim pull nen Fehler. Geht es dir um Projekte wo du als einziger Entwickler dran arbeitest? In dem Fall ist das sowieso alles ziemlich Wurst, denn wenn sich master nicht geändert hat seit dem merge, dann wird ein rebase auf master trivial sein bzw. oft nichtmal nötig. D.h. du bekommst dann sowieso kein Problem wenn du mit dem alten Branch weiter arbeitest. Vor dem pushen solltest du den Branch halt lokal umbenennen damit das nicht verwirrend wird, aber das ist dann auch schon alles.
-
@hustbaer
Ich hatte den Fall noch nicht, weil wir erst vor kurzem auf GIT umgestellt haben. Aber was du sagst leuchtet auf jeden Fall ein.
-
Ich kann noch sehr empfehlen, dir auf Kommandozeile in einem Repo immer den Branch und den lokalen Commit-Stand anzueigen.
Z.B. so:
mein-username > ~/projects/mein-projekt > (featureXY↑3|+4…)
Dann sehe ich sofort, dass ich auf dem Branch "featureXY" bin, dort 3 Commit weiter als der origin bin (wahrscheinlich, weil ich die drei Commits noch gar nicht gepusht habe oder sie noch im Review sind) und ich 4 Dateien geändert habe und dass es untracked files gibt.
Sowas scheint inzwischen Standard bei Linux-Shellkonfigurationen zu sein - geht das eigentlich auch unter Windows cmd.exe?
