Wir haben einen Build-Server, der entworfen wurde, um eine Version des Codes von git auszuchecken und zu bauen. Im Allgemeinen wird der Server den Zweig develop auschecken und erstellen, aber er kann von einer GUI gesteuert werden, um einen bestimmten Zweig oder ein bestimmtes Tag zu erstellen.
Unser Git-Archiv ist groß, also wollen wir nur einmal ein git clone durchführen. Meine Frage ist also: Welche Sequenz von Git-Befehlen sollte ausgegeben werden, um das aktuelle Arbeitsverzeichnis bezüglich des Remote-Git-Archivs auf den neuesten Stand zu bringen.
Mein anfänglicher naive Versuch wurde gerade durchgeführt git checkout <branch> , gefolgt von git pull . Dies berücksichtigte jedoch nicht alle Artefakte, die durch den vorherigen Build erzeugt wurden, der gelöscht werden musste, sowie einige automatische Code-Modifikationen, die durch den Build-Prozess vorgenommen wurden, z. zu den Versionsnummern in Assembly-Dateien.
Was wir also brauchen, ist die Befehlsfolge nach
Bitte beachten Sie, dass der benannte Zweig oder Tag möglicherweise nicht bereits im lokalen Repository bekannt ist. Wenn beispielsweise auf dem Remote-Server ein neuer Zweig release/xxx erstellt wird, ist dies dem lokalen Erstellungscomputer nicht a priori bekannt. Dies ist ein weiteres Problem, auf das meine naive Einstellung gestoßen ist.
Und schließlich ist es möglich, dass der git-Server gelegentlich seine Geschichte korrigiert hat. Ich bin sicher, dass dies ein seltenes Ereignis sein wird, aber es wäre wünschenswert, wenn der Integrationsserver keine Anpassung nach einem Historienumschreiben benötigt.
Vielen Dank
Dies ist der Mechanismus, den wir derzeit verwenden. % Co_de% wird nur einmal als Teil des Setups ausgeführt, und dann wird für jeden Build das Folgende ausgeführt.
Ich habe die Fehlerbehandlung aus Gründen der Übersichtlichkeit entfernt.
%Vor% Wir haben neue Tags / Zweige auf einem Entwicklungscomputer erstellt, diese auf den Server übertragen und dieses Skript ruft sie korrekt ab und erstellt die Ergebnisse. Wir haben mit dem Hinzufügen des Präfix git clone zu den Zweig- oder Markennamen experimentiert, aber dieser Ansatz funktionierte nicht für uns (die Markennamen wurden nicht erkannt).
Ich denke, der Hauptunterschied zwischen diesem Skript und der viel einfacheren Antwort von @Yasser ist, dass der Git HEAD auf die richtige Stelle zeigt und der Befehl origin/ eine vernünftige Antwort gibt. Ob das wichtig ist - ich bin mir nicht sicher.
Tags und Links git continuous-integration