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
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.