Im Allgemeinen ist unser Code ziemlich modular, sodass Entwickler nicht gleichzeitig Änderungen an denselben Dateien vornehmen. Aber ich bin auf eine Situation gestoßen und ich sehe zwei Möglichkeiten, es zu lösen, also suche ich nach Meinungen darüber, welcher der beste Weg ist und warum (oder zusätzliche Lösungen). Mein Kollege hat Änderungen an einigen Dateien in seinem Feature-Zweig vorgenommen, die ich gerne in meinem Feature-Zweig verwenden würde. Dies sind separate Features, keine gemeinsamen Feature-Zweige. Ich sehe zwei Lösungen:
1) Er kann seinen Feature-Zweig in Entwicklung und Push zum Ursprung zusammenführen. Ich kann dann den Entwicklungszweig ziehen und meinen Feature-Zweig lokal auf ihn zurücksetzen.
2) Ich kann seinen Feature-Zweig direkt in meinen zusammenführen.
Ich mag das letztere nicht wirklich, weil es einfach abgeht; Zusammenführen eines Feature-Zweigs in einen Feature-Zweig direkt, wenn die beiden Features nicht in Beziehung stehen, nur ein paar Abhängigkeiten. Also, ich ging mit dem ersten, aber für zukünftige Referenz bin ich neugierig, wie andere mit dieser Situation umgehen würden.
Was Sie in git tun, ist nur eine Reflexion des Entwicklungsprozesses.
1) Sie müssen Ihre Arbeit im Entwicklungszweig nicht einfach neu erstellen , sondern einfach den Entwicklungszweig zusammenführen dein Arbeitszweig. Wenn du dich neu legst, kannst du deine Arbeit nicht teilen.
2) Sie müssen seine Arbeit einarbeiten, aber er ist nicht bereit, sich weiterzuentwickeln. Dann gibt es kein technisches Problem, wenn Sie seine Arbeit zusammenführen. Seien Sie nur vorsichtig, wenn Sie Beta-Arbeit einbauen!
Dies ist kein git-Problem. Sie sind nur abhängig von der Arbeit, die noch nicht fertig ist. Sie passiert die ganze Zeit, die Sie regelmäßig mit der Arbeit des anderen Entwicklers verschmelzen müssen, bis er fertig ist.
Ich verstehe Ihren Instinkt, die erste Lösung zu bevorzugen, und ich denke, es ist der richtige Weg, denn:
develop zusammenführen. Das ist sehr natürlich: er führt seine eigenen Änderungen zusammen und löst, falls nötig, seine eigenen Konflikte auf. develop rebasen, führen Sie effektiv eigene Änderungen zusammen und lösen gegebenenfalls Ihre eigenen Konflikte . Auch dies ist sehr natürlich und intuitiv. In der anderen Alternative werden Sie seinen Zweig mit Ihrem zusammenführen, und vielleicht müssen Sie seine Konflikte lösen. Und das ist eigentlich nur die Spitze des Eisbergs, denn selbst wenn die Zusammenführung ohne Konflikte verläuft, was ist, wenn der Bau bricht? Oder was, wenn der Build noch in Ordnung ist, aber jetzt hat das Programm ein seltsames Verhalten? Der andere Typ würde am besten wissen, wie man mit diesen Problemen umgeht.
Wenn die ursprünglichen Entwickler ihre eigenen Änderungen zusammenführen, sind sie dafür verantwortlich, alles in Ordnung zu halten: Konflikte lösen, den Build passieren lassen, die Tests bestehen lassen, die Änderungen validieren, was zu einem Paket führt, das von anderen genutzt werden kann und voll funktionsfähig ist . Auf diese Weise kann der nächste Entwickler, der oben auf dem gut validierten Zweig arbeitet, sicher annehmen, dass, wenn etwas nach seiner Änderung nicht funktioniert, die Ursache seine eigenen Änderungen sein müssen.
Ich benutze das täglich. Ich bin sehr wohl dabei, meine eigenen Änderungen oder Änderungen meines Teams zusammenzuführen, weil ich weiß, worum es geht. Ich hasse es, die Änderungen anderer Teams zusammenzufassen (wenn es nötig ist), weil ich nicht weiß, worum es geht und wie ich das Ergebnis testen kann.
Tags und Links git atlassian-sourcetree dvcs