Zusammenarbeit mit Kollegen, die kein Git verwenden

Question

Während ich git für alle meine Projekte verwende, muss ich gelegentlich mit Kollegen zusammenarbeiten, die git nicht verwenden. Sie ziehen es vor, ihre gezippten Quellen hin und her zu senden. Es ist nervig und umständlich, aber ich muss damit umgehen. Der Workflow ist wie folgt:

Wenn sie meinen Code benötigen, verwende ich git archive und senden Sie ihnen eine Zip-Datei export.zip. Ich arbeite weiter und mache die Änderungen, die ich mache, während sie mit meinen veralteten Quellen arbeiten. Illustration:

┌ archive & mail 
    │ 
    A ← B ← C 
     └───┴── my later changes 

Einige Zeit später, sie schicken mir ihre Antwortdatei import.zip. Was ist der beste Weg, um die Zip-Datei in meinen Git Tree zu importieren und zu implementieren? kann ich denke an die folgenden drei Optionen, die semantisch unterscheiden:

1. meine spätere Änderungen Betrachten wir auf der Grundlage ihrer Änderungen:

   ┌ archive & mail 
       │ 
       A ← A' ← B ← C 
        │ └───┴── my later changes 
        │ 
        └─ their changes 
   

   Hier würde ich Kasse A, entpacken import.zip, begehen als A' und dann wenden Sie wieder B und C an (und was auch immer folgte). Wie setze ich einen erneuten Antrag auf HEAD?

2. Betrachten Sie ihre Änderungen auf der Grundlage meiner späteren Änderungen:

   A ← B ← C ← A' 
   

   Hier würde ich einen Patch auf der diff erstellen basierend zwischen A und import.zip und dann Anwendung, wenn auf C.

3. einen Zweig erstellen und zusammenführen:

   A ← B ← C ← M 
       ↖  ↙ 
        A' 
   

   Während diese Frage zu schreiben, ich kam zu dem Schluss, dass diese Option die allgemein anwendbar ist und die robusteste. Sind Sie einverstanden?

Ich bin dankbar für weitere Ratschläge in Bezug auf diesen Workflow. Zum Beispiel finde ich es mühsam und fehleranfällig, sich an das Commit A zu erinnern, das ich archiviert habe.

Answer 1

Sie haben Recht, # 3 ist das Beste. Ich würde eine Verzweigung für jede Person erstellen, die Ihnen Änderungen senden könnte. Überprüfen Sie ihre Verzweigung, entpacken Sie das Archiv und übernehmen Sie die Änderungen in ihre Verzweigung. Irgendwann kannst du deine Änderungen mit ihren Änderungen zusammenführen, und git wird dir Konflikte aufzeigen, was offensichtlich nicht optimal ist, aber relativ OK, wenn man bedenkt, dass es sich um Leute handelt, die Reißverschlüsse versenden. Wenn Sie bereit sind, Ihnen die letzten Änderungen zu senden, würde ich empfehlen, das Commit, das Sie archivieren, als "collab-zip-<date>" oder etwas zu markieren, mit einer Tag-Nachricht, die besagt "Senden von Änderungen an X, weil Y". Das beantwortet Ihr letztes Bit darüber, wie Sie verfolgen, was Sie wann gesendet haben.

Answer 2

Ich finde es mühsam und fehleranfällig, sich an das Commit A zu erinnern, das ich archiviert habe.

Machen Sie einen export Zweig, und arbeiten Sie an einem anderen Zweig. Wann immer Sie bereit sind, an Ihre Kollegen zu senden, können Sie einfach Ihren letzten zu export zusammenführen und diesen archivieren.Ich würde vorschlagen, dies in Verbindung mit Option 3 zu verwenden.

Und Sie haben auch Option 4 vergessen: Überzeugen Sie Ihre Kollegen, Git zu benutzen, indem Sie ihnen helfen, sich einzurichten und damit anzufangen. Bringen Sie einem Mann zum Fischen usw. bei.

Answer 3

Wie andere bereits erwähnten, ist # 3 die zweitbeste * Lösung. Es ist ungefähr das gleiche wie wenn sie auch Git benutzen würden, nur dann würden Sie Remote-Zweige anstelle von lokalen verschmelzen, und sie hätten wahrscheinlich mehrere Commits anstatt nur eines.

Sie könnten natürlich Ihre Commits über ihre Änderungen (wie Ihre erste Option), aber dann würden Sie Geschichte neu schreiben, die eine ganze Reihe anderer Probleme einführen würde.

Ich würde wirklich nicht vorschlagen, manuelle Patches (Option # 2) zu verwenden. Git hat ein sehr gutes merge Werkzeug, das für diese Situationen entwickelt wurde.

*: Die beste Lösung ist immer noch, Ihre Kollegen davon zu überzeugen, Git zu verwenden. Gerade jetzt verbringen Sie eine Menge Zeit und Mühe wegen ihrer Präferenzen. Wenn sie nicht bereit sind, dir zu zuhören, sprich einfach mit deinem Chef und sag ihm, dass du wegen seiner Sturheit viel Zeit verschwendest und dass es ein höheres Risiko birgt, Bugs einzuführen, und das (na ja, ich Ich schätze, Sie können noch weitere Argumente vorbringen, um ihn davon zu überzeugen, dass es etwas Geld sparen wird.