Git Zusammenarbeit?

Kommt drauf an

Das einfachste wäre, alle arbeiten auf dem selben Branch.
Beim Push meckert Git dann, wenn man nicht auf dem aktuellsten Stand ist, dann kann man aktualisieren, ggf. mergen, nochmal testen und fertig.
Man kann aber auch mit PullRequests arbeiten, das ist dann interessant, wenn viele oder unbekannte Personen (z.B. OpenSource) mit arbeiten und/oder immer jemand drüber lesen soll.

Wir nutzen aber auch häufig Feature- oder Ticket/Issue-Branches. Das ist dann ein Branch für ein bestimmtes Feature oder Ticket/Issue (nennt jeder wie er will), wird auf Basis eines anderen Branches erstellt, entsprechend bearbeitet und anschließend in den richtigen Branch zurück gemerged. Das ist dann spannend, wenn die Umsetzung aufwändiger ist, man nicht alleine oder einen längeren Zeitraum daran arbeitet, aber immer noch am ursprünglichen Branch arbeiten können will.

Und dann haben wir noch Branches für z.B. Live- und für Test-System (und manchmal noch weitere Systeme).

Pullen sollte man immer dann, wenn man den neusten Stand braucht. Wenn Du tagelang an einem Thema arbeitest, kannst Du natürlich hin und wieder pullen, aber da Du hinterher eh mergen musst, liegt das ganz allein bei dir, wann Du pullst.

Bei komplexen Umbauten kann es sich auch lohnen, mit einem Feature-Branch zu arbeiten, vor dem Merge zurück erst noch einmal den Quell-Branch in den Feature-Branch zu mergen, nochmal testen/fixen und danach erst den Feature-Branch in den Quell/Ziel-Branch mergen.

Ach ja: Bei Pull würde ich lokale Commits immer rebasen, das erspart unnötige Merge-Commits und funktioniert meistens ziemlich zuverlässig. Kann man auch global einstellen, indem man in der Config pull.rebase auf true setzt.

Das alles funktioniert aber nur dann wirklich gut, wenn die Software sinnvoll strukturiert ist, sodass zwei Leute an unterschiedlichen Stellen im Code arbeiten können, ohne den Kollegen auf die Füße zu treten.
Außerdem ist es wichtig, dass Formatierungen, Codingquidelines, etc. gleich sind, da man sonst ständig Merge-Konflikte wegen solchen Kleinigkeiten hat.
Wenn aber 1000 Funktionen in einer riesigen chaotisch formatierten 100k Zeilen langen Datei stehen und jeder Mitarbeiter ständig Zeug umformatiert - dann kann auch Git nichts mehr retten.

Ja, jeder cloned das Repo, arbeitet lokal, und pushed dann in das Remote-Repo.

Wenn ihr größere Dinge entwickelt, bietet es sich an, dass jeder in einem eigenen Branch arbeitet. Also wenn du anfängst ein Feature zu entwickeln, forkst (kopierst) du master (den Haupt-Zweig), und arbeitest dann in dem Branch ohne dich groß darum zu kümmern, was die anderen machen. Wenn du dann mit der Entwicklung des Features fertig bist, kannst du deine commits squashen (du fasst mehrere Commits zu einem zusammen), auf master rebasen (du tust so, als ob du vom aktuellen Stand aus angefangen hättest zu entwickeln), und dann den branch nach master mergen (deine Änderungen übernehmen).

Zum ersten Punkt: ersteres.

—

Wenn richtig getrennt gearbeitet wird, reicht es, kurz vor dem Pushen auf den aktuellen Stand des Repos zu aktualisieren, um sicherzustellen, dass es keine Konflikte gibt und das Projekt weiterhin funktioniert (automatisierte Tests helfen da ungemein).

Wenn in einem kleinen Team an einem Branch gearbeitet wird, kann es täglich oder auch mehrmals am Tag dazu kommen, dass Änderungen runter gezogen und mit der eigenen Arbeit in Einklang gebracht werden müssen (ggf. mit Hilfe der Teammitglieder). Da gibt es kein Drumherum, wenn so gemeinsam gearbeitet werden muss.

Generell hilft Kommunikation. Über größere Änderungen (z. B. zur Projektarchitektur oder der Entwicklungsumgebung) sollten alle informiert sein, um die nötigen Schritte gehen zu können.