GIT-Workflow

[Benedikt (Gast)]

Hallo zuammen,

ich arbeite mich gerade in Git ein und habe Fragen zum Workflow. In 
vielen Tutorials wird beschrieben, dass man z.B. einen Master-Branch und 
dazu viele Feature-Branches haben kann. Mir ist klar, dass man von dem 
Master-Branch beliebig viele neue Feature-Branches abzweigen kann, aber 
was mir nicht so richtig klar ist, ist wie man bestimmte Operationen 
(Pull/Push/Merge) in einem Team dann praktiziert, um z.B. Konflikte oder 
unerwünschte verborgene Merge-Entscheidungen zu vermeiden.

Nehmen wir mal an, es wurden vom Master-Branch gerade 3 neue 
Feature-Branches erstellt, die alle von verschiedenen Programmieren 
bearbeitet werden:
Programmierer 1: feature-payment
Programmierer 2: feature-invoice
Programmierer 3: feature-dunning

Programmierer 1 ist zuerst fertig. "Merged" dieser nun den Master-Branch 
in seinen lokalen Branch, um Konflikte zu erkennen bzw. zu beheben, und 
um danach seinen lokalen gemergten Stand via Push ins Git bzw. in den 
Remote-Feature-Branch hochzuladen und dann einen Pull-Request für 
"feature-payment into master" mit z.B. Programmierer 2 als Reviewer zu 
erstellen? Oder wie ist hier die richtige Vorgehensweise, um die eigenen 
Änderungen hochzuladen?

Sollten alle Programmierer zwischendurch immer wieder den Master-Branch 
in ihre eigenen Branches "mergen", um so frühzeitig die fortlaufenden 
Änderungen im Master-Branch einzuspielen und die "Unterschiede" zwischen 
dem Master-Branch und dem eigenen Branch nicht zu groß werden zu lassen?

Ist ein "Pull" dann nur dafür gedacht, den lokal ausgecheckten und 
möglicherweise veralteten Branch durch den dazu passenden Remote-Branch 
zu aktualisieren?
Mir ist nicht ganz klar, ob man lokale Branches nur pullt, damit z.B. 
lokale Entwicklungs-Umgebungen den neuesten Stand haben, oder ob es 
Situationen gibt, in denen man z.B. einen ganz anderen Branch in den 
eigenen Branch pullt?

Vielen Dank und viele Grüße
Benedikt

[Imonbln (Gast)]

Achtung, der richtige Workflow in Git ist immer ein Gutes 
Diskussionsthema. jeder Entwickler hat da seien Vorlieben und 
Entwicklerteams können herrlich darüber streiten.

Benedikt schrieb:
> Sollten alle Programmierer zwischendurch immer wieder den Master-Branch
> in ihre eigenen Branches "mergen", um so frühzeitig die fortlaufenden
> Änderungen im Master-Branch einzuspielen und die "Unterschiede" zwischen
> dem Master-Branch und dem eigenen Branch nicht zu groß werden zu lassen?

hier wäre mein Vorschlag eher ein rebase des Privatenbranches. Solange 
der Branch nur lokal ist und keine anderen Entwickler darauf Arbeiten, 
sorgt der rebase dafür das die der Master nur mit Merge belastet wird 
welche wirklich neue Features in das Projekt bringen. Ausserdem macht 
der rebase des Lokalen branch den Bisect einfacher und ermöglicht mir 
als Entwickler gleich noch aufzuräumen, da ich Commits zusammenführen 
kann und Fehlversuche die keinen mehrwert für das Projekt bringen unter 
den Tisch fallen lassen kann. Der Nachteil ist allerdings, das gibt 
potenziell mehr Merge Konflikte wahrend des rebase, aber hey das Schult 
und nimmt den Mergekonflikt den schrecken.