2013-06-25 13 views
9

Ich habe Git nur für Einzelprojekte verwendet. Jetzt möchte ich mit zwei anderen Entwicklern an einem Projekt weiterarbeiten.Ist es sinnvoll, für jeden Entwickler eine Niederlassung zu erstellen?

Würde es Probleme verursachen, wenn ein Entwickler Änderungen festschreiben möchte, aber ein anderer Commit von einem anderen Entwickler erstellt wurde? Wäre es daher sinnvoll, für jeden von uns einen Zweig zu schaffen?

+3

Sie haben einen Zweig für jeden von Ihnen, es sei denn, Sie arbeiten alle an demselben Computer. Wenn Sie Ihren Repo klonen, erhalten Sie Ihren * eigenen * Satz von Zweigen, die zufällig die gleichen Namen wie die Zweige aller anderen haben, aber sie sind immer noch * Ihr eigener Zweig *. – meagar

+1

@meagar Klingt interessant, könnten Sie bitte näher darauf eingehen? – danijar

+1

Jede geklonte Instanz des Repository ist eine vollständig eigenständige Sache. Du hast die Freiheit, * was immer du willst * mit deinem Zweig zu tun, du wirst nicht auf die Zehen eines anderen treten, bis du versuchst zu drücken. Wenn Sie pushen und ziehen, führen Sie eine Zusammenführung Ihrer lokalen Verzweigung mit der Remote-Verzweigung (oder umgekehrt) als Zweig "Tracking" durch. Dies ist identisch mit dem Zusammenführen von zwei Zweigen auf Ihrem lokalen Computer. Tatsächlich ist "Git Pull" wirklich nur ein Abruf, gefolgt von einer Zusammenführung. Git push schränkt Verschmelzungen aus Gründen der Einfachheit auf Schnellvorlauf-Zusammenführungen ein, da Sie Remote-Konflikte nicht effektiv lösen können. – meagar

Antwort

17

Git eignet sich wie die meisten Versionskontrollsysteme hervorragend für die Verwendung durch mehrere Entwickler. In der Tat ist es einer der Hauptpunkte eines Versionskontrollsystems.

Es ist nicht notwendig, eine Verzweigung pro Benutzer zu erstellen. Ich würde sogar so weit gehen zu sagen, dass es kontraproduktiv wäre. Wenn Sie an der gleichen Funktion arbeiten, möchten Sie wahrscheinlich die Änderungen des anderen durch Ziehen und Zusammenführen erhalten. Das Erstellen von Verzweigungen pro Benutzer ist redundant und kompliziert die Dinge unnötig.

Die Commit-Situation, die Sie beschreiben, ist nicht problematisch. Wenn ein anderer Benutzer einen neuen Commit in demselben Zweig erstellt hat wie Sie, werden Sie beim Versuch, push zu versuchen, angehalten. Stattdessen müssen Sie zuerst pull die andere Benutzer Commit und Zusammenführen (oder Rebase) Ihre Arbeit mit diesen Änderungen. Dies ist das Standardverhalten von git pull.

Üblicherweise werden Verzweigungen erstellt, die hauptsächlich auf Features basieren. Wenn Sie eine Anleitung zur Verzweigung benötigen, .

+0

Es hängt davon ab, wie Ihre Arbeit aufgeteilt ist. An einem Ort, an dem ich gearbeitet habe, hätten wir niemals zwei Personen, die gleichzeitig an derselben Funktion arbeiten.Wenn Sie mehrere Entwickler haben, die an derselben Funktion arbeiten, stimme ich Ihnen jedoch vollkommen zu. – Renan

+1

Sie sollten nicht nur separate Zweige * pro Person erstellen *; Es sollten Features sein, die die Erstellung von Zweigen vorantreiben. Jede Person sollte so viele Zweige haben, wie sie Funktionen in der aktiven Entwicklung haben. – meagar

+0

Meiner Meinung nach ist diese Antwort falsch. Sie sollten nicht zwei Entwickler auf demselben Zweig haben. Was ist, wenn jemand eine Reihe von Commits quetscht und Pushs erzwingt? Wenn das Feature zwei Entwicklern rechtfertigt, sollten Sie genau herausfinden, an welchem ​​Umfang jeder Entwickler arbeitet und für jedes Feature einen Zweig haben. Dann können Sie einen zusätzlichen Abzweig-Master (oder einen Meilenstein usw.) haben und diese Feature-Zweige zusammenführen. Dies ermöglicht das Lösen von Zusammenführungskonflikten und das korrekte Testen von integrierten Verzweigungen vor dem Zusammenführen zum Master- und Durchlaufen eines Bereitstellungsprozesses. –

4

Früher haben wir das an einem Ort gemacht, an dem ich gearbeitet habe. Jeder von uns hatte mindestens einen persönlichen Zweig - ich habe für jede Aufgabe, die ich zu erledigen hatte, einen Zweig geschaffen.

Wenn wir fertig waren, würden wir Anfragen an die Hauptzweig ziehen. Wenn sich jemand in den Haupt-Zweigcode eingemischt hat, der mit Ihren Änderungen in Konflikt steht, müssen Sie die Konfliktlösung genauso machen wie mit jeder anderen Quellcode-Kontrollplattform (wie Tortoise, Mercurial usw.), aber es ist keine große Sache, wenn Ihre Entwickler davon wissen was sie tun.

IMO Dies ist der beste Weg, um die Entwicklung in einem Team durchzuführen. Sie können immer in Ihrer eigenen persönlichen Umgebung testen, schnell Code aus jedem Zweig nach Bedarf. Das Pull-Request-System macht auch die Peer-Review-Funktion so viel einfacher, da jeder direkt in den github diff-Seiten Kommentare schreiben und Kommentare zu den relevanten Zeilen schreiben kann.