GIT: gemeinsam an einem Zweig arbeiten-Merge

[haentschman]

Hallöle...

Jetzt habe ich die Situation, daß ich mit einem externen Kollegen an einem Zweig arbeiten will.
Der grobe Ablauf sollte klar sein...
* jeder hat den seperaten Branch
* Push/Pull in den separaten Branch

Für mich stellt sich die Frage/n:
Wenn wir dann fertig sind, hat jeder den Branch. Wer merged den Branch ins develop? Ich! Was passiert mit dem Branch des Kollegen? Der sollte eigentlich dann weg sein...oder? Muß der den Branch selbst mergen?

Worauf muß ich achten?

PS: TortoiseGIT

Danke...

[Jumpy]

Das klngt ja als gäbe es kein zentrales Repository, sondern nur zwei lokale, oder?
Ich hätt jetzt gedacht jeder merged in sein develop und einer übernimmt die Verantwortuung und megred die beiden develops. Anschließend muss der gemergede develop nattürlich zum anderen gepushed werden, damit der auch auf dem neusten Stand ist.

[haentschman]

1. ich: lokales Repository (Branch #999)
2. Kollege: lokales Repository (Branch #999)
3. Zentrale Bitbucket: externes Repository (Branch #999)

Push/Pull zum externen Repository hin und her

Ich kann den finalen Stand mergen (develop) und ins externe Repository Pushen... Wenn der Kollege vom develop einen Pull macht, hat er das gemergte auch. Soweit so gut...
Was passiert mit dem Branch #999 in seinem lokalen Repository? Muß er den selbst entfernen? Oder kriegt das GIT mit, das der Zweig gemerged wurde?

[freimatz]

Bleibt / Wenn er ihn nicht will Ja / Ja schon, aber warum sollte git dann den branch löschen? (ich würde das nicht wollen)

[haentschman]

Zitat:

aber warum sollte git dann den branch löschen?

...weil er quasi nicht mehr "offen" ist

[Edelfix]

Wie ist euer Plan? Jeder arbeitet jeder an seinem Branch und nach zum Beispiel zwei Wochen wird dann ein Merge gemacht?

Oder habt ihr ein Täglichen Workflow wo morgens ein Pull von Master gemacht wird und abends ein Commit und Push zum Master?

[pertzschc]

Wenn Ihr mit einem zentralen Repo arbeitet, habt Ihr zwei einfache Möglichkeiten:

1)
- jeder erstellt sich einen eigenen Branch "A" und "B" und mergt seine Ergebnisse nach Fertigstellung in den zentralen Master per Pull Request.
- wer als erstes mergt muss seine Änderungen nur mit dem Stand im Master zusammenbringen
- wer als zweites fertig wird und mergt, muss seine Änderungen mit dem neuen Stand im Master zusammenbringen, wo ja auch bereits die Änderungen des anderen Branches enthalten sind. Am einfachsten geht das dann auch wieder mit einem Pull Request und einem Rebase der eigenen Änderungen auf den Master.

2)
- Ihr erstellt nur einen gemeinsamen Branch "A" und arbeitet daran lokal
- Jeder muss dann regelmäßig seine Commits nach zentral pushen und auf der anderen Seite auch regelmäßig von zentral pullen
- Zum Schluss wird gemergt wie bei Variante eins und danach der Branch gelöscht (und ein neuer eröffnet).


Hier gibt es weitere gute Erklärungen und Demos: https://learngitbranching.js.org/?demo=&locale=de_DE

[haentschman]

Zitat:

Oder habt ihr ein Täglichen Workflow wo morgens ein Pull von Master gemacht wird und abends ein Commit und Push zum Master?

...so hatte ich mir das vorgestellt.

Zitat:

per Pull Request.

...das hatte ich befürchtet. Das ich das noch nie gemacht habe. Da muß ich nochmal lesen.

Zitat:

und danach der Branch gelöscht

Ich hatte gehofft, das das automatisch geht...

[freimatz]

Das Löschen eines Branches geht in TortoiseGIT doch mit drei Klicks ... - wo ist das Problem?
In git ist ein branch (und auch amster ist nur einer) nur ein Pointer auf einem Commit. Es gibt da kein offen oder so.

[Aviator]

Zur Not irgendwann mal alle Branches auf einmal löschen. Da wo noch nicht gemerged wurde meckert GIT sowieso.