Warum git am leave geänderte Dateien herumliegen? Wie kann ich meinen Workflow anpassen besser machen?

Question

Das wird ein langer, aber ich hoffe, dass Sie mit mir ertragen können.

Ich versuche, git zu verwenden, um mein Team den Quellcode unter Versionskontrolle gestellt. Nach dem Versuch, verschiedene Ansätze zu finden, die für mich arbeiten würde, entschied ich mich schließlich git format-patch Funktion zu nutzen. FWIW, das Produkt ist eine ASP.NET Web-Anwendung in Windows ausgeführt wird, und ich bin zur Zeit mit msysgit .

Hintergrund:
Ich habe einen Staging-Server (Spiegel Produktionsserver), die alle aspx-Dateien enthält. Ich habe dann eine Git-Repo mit init-db in meinem Stammordner und hat ein git add . alle Dateien zu verfolgen.

Damit ich auf meinem Laptop eine lokale Kopie zu haben, habe ich eigentlich die „.git“ Ordner aus dem Staging-Server gezippt und FTP'ed es zu meinem lokalen Rechner. Umbenannt es zu „staging.git“ und hat einen git clone staging.git webappfolder gegen meine Entwicklung zu tun.

Nachdem ich 2 Commits für feature1 und feature2, dann ist es Zeit, die Änderungen wieder in den Staging-Server zu übernehmen. Ich habe eine git format-patch -2, die Dateien 0001blah.patch und 0002blah.patch ausgibt.

Diese 2 Patch-Dateien werden dann an den Staging-Server geschickt und ich habe einen git am 0001blah.patch auf dem Staging-Server selbst. ein git log Doing zeigt das ging durch begehen. Aber wenn ich eine git status tun, es zeigt Changed but not updated: modified: file1.aspx.

Was das bedeutet das genau? Ich habe auch versucht eine git apply 0001blah.patch zu tun, aber alles, was ich bekam, war ein error" patch failed: file1.aspx: patch does not apply.

Gibt es ein Problem mit meinem Workflow? Einsicht in Bezug auf die richtige Art und Weise oder Hilfe wäre sehr hilfreich. Auch hier würde das Patchen Modell jetzt die praktikabelste für uns sein, wenn wir nicht bald einen SSH-Server jederzeit einrichten werden.

Answer 1

Ich habe gerade versucht dies:

rm -rf clone?

# clone 1 is the working copy
mkdir clone1
(
    cd clone1
    git init
    echo foo >> file1
    git add file1
    git commit -m "Initial state"
)

# clone 2 is the staging repo
git clone clone1 clone2

# create patches
(
    cd clone1
    git tag staging # tag to track what's in staging

    echo feature1 >> file1
    git add file1
    git commit -m "Feature 1"

    echo feature2 >> file1
    git add file1
    git commit -m "Feature 2"

    rm *.patch
    git format-patch staging
)

# apply patches
(
    cd clone2
    git am ../clone1/*.patch
    # Cygwin/msysgit line ending weirdness when patching. Aborting and
    # reapplying clears it up.
    git am --abort 
    git am ../clone1/*.patch
    git log
    git status
)

Hat das kleinere Problem mit dem Patches nicht eindeutig Anwendung, ohne die Uhr zweimal zu tun, aber ich am Ende mit einem sauberen Arbeits dir in Klon 2 mit dem richtigen Inhalt von Datei1 auf. So scheint es nichts falsch mit Ihrem Workflow per se.

Git gilt nur den Arbeitsbaum aktualisieren, kein Commit durchführt.

Das heißt, ich würde nicht ein Git-Repository für das Staging verwenden. Mein Workflow würde wahrscheinlich eine Release-Zweig / Gabel der Entwicklungs-Repository (oder nicht) machen und bereitstellt nur voll saubere Kopien davon.

Für inkrementelle Aktualisierungen der Staging-Umgebung, nur git tag staging in dem Release-Zweig verwenden "git diff staging..HEAD> update.patch" per E-Mail, und die Standard-Unix "patch -p1", es anzuwenden funktionieren soll. Das heißt, wenn Sie wirklich die Änderungshistorie physisch auf dem Staging-Server benötigen.

Answer 2

Haben Sie versucht, ein

git am -3 

? Aus dem git-am doc ,

-3
--3way

When the patch does not apply cleanly, fall back on 3-way merge

---

Hinweis: Aus Git Google Summer of Code 2009 , gibt es eine Projekt "git-Anwendung Teach die 3-Wege-Merge-Rückfall git-am weiß":

  

Wenn git-apply Patches Datei (en) werden die Dateien Patch möglicherweise nicht sauber. In einem solchen Fall git-apply lehnt derzeit den Patch.
  Wenn es von git-am dann ein 3-Wege-Merge wird versucht, durch genannt wird:

     

  
• den "Index ..." taking Daten aus dem Pflaster und
  
• einen temporären Baum konstruieren,
  
• die Anwendung des Patch auf das, dann
  
• den temporären Baum auf den aktuellen Zweig zusammengeführt werden.
  

     

Aus verschiedenen Gründen wäre es schön, den gesamten temporären Baum Tanz innerhalb von direkt zu tun git-Anwendung, wie sie sagt, profitieren die git-Sequenz der „anwenden“ -Befehl, beschleunigen git-am Verarbeitung von weniger gabeln, etc