Yarn: Sollte Garn.lock in Git als Binärdatei behandelt werden?

Nein sollte nicht. Die Datei ist reiner Text und es können Zusammenführungskonflikte in der Datei auftreten, die Sie möglicherweise lösen müssen.

In der Dokumentation steht, dass die Dateigarn.lock nicht angerührt werden sollte, um Probleme zu vermeiden und nur Garn selbst damit umgehen sollte. Wie löse ich dann einen Zusammenführungskonflikt?

@kittens ist das Richtige, wenn es Konflikte gibt, um die Sperrdatei

@dbashford Das Problem beim Wegblasen und erneuten Laufen von Garn besteht darin, dass Sie mehr Änderungen erhalten, als Sie wollten. Tilde-Versionen werden beispielsweise aktualisiert, obwohl Sie yarn upgrade .

@dbashford dann ist es einfacher, das Garn einfach zu legen. Lock-Datei im gitignore

Der Ansatz, der für mich bisher funktioniert hat, ist dieser:

git rebase origin/master

Wenn der erste Konflikt auftritt, checke ich yarn.lock und führe dann die Installation erneut durch

git checkout origin/master -- yarn.lock
yarn install

Dadurch wird ein neues yarn.lock basierend auf der Ursprungs-/Masterversion von yarn.lock generiert, jedoch einschließlich der Änderungen, die ich an meinem package.json . Dann geht es nur noch um:

git add yarn.lock
git rebase --continue

Und ich bin wieder im Geschäft.

Beachten Sie, dass selbst wenn Sie nicht manuell die Zusammenführung Konflikte zu lösen, mit es sich um eine nicht-Binärdatei Mittel sein , um die Zusammenführung Konflikte sehen können, die immer noch wertvolle Informationen.

Können wir, selbst wenn es _keine_ Zusammenführungskonflikte gibt, immer davon ausgehen, dass git zwei Versionen einer Garn.lock-Datei so zusammengeführt hat, dass eine gültige/korrekte Datei entsteht? Es scheint falsch, git den Inhalt der Datei überhaupt aktualisieren zu lassen, wenn Garn das einzige Tool ist, das seinen Inhalt verwalten soll.

Ich bin mir nicht sicher, ob das automatische Zusammenführen von YAML immer zu einer gültigen Datei führt, insbesondere wenn:

• Mehrere Hauptversionen im Paket, die in der Sperrdatei direkt nebeneinander liegen
• Die erste Zeile zweier benachbarter Einträge kann sich gleichzeitig ändern, während sie auf dieselbe oder eine ähnliche Version auflösen:

readable-stream@^2.0.0, "readable-stream@^2.0.0 || ^1.1.13", readable-stream@^2.0.2, readable-stream@^2.0.5, readable-stream@^2.2.2:
  version "2.2.2"
  resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-2.2.2.tgz#a9e6fec3c7dda85f8bb1b3ba7028604556fc825e"
  dependencies:
    buffer-shims "^1.0.0"
    core-util-is "~1.0.0"
    inherits "~2.0.1"
    isarray "~1.0.0"
    process-nextick-args "~1.0.6"
    string_decoder "~0.10.x"
    util-deprecate "~1.0.1"

readable-stream@~2.1.4:
  version "2.1.5"
  resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-2.1.5.tgz#66fa8b720e1438b364681f2ad1a63c618448c9d0"
  dependencies:
    buffer-shims "^1.0.0"
    core-util-is "~1.0.0"
    inherits "~2.0.1"
    isarray "~1.0.0"
    process-nextick-args "~1.0.6"
    string_decoder "~0.10.x"
    util-deprecate "~1.0.1"

@IanVS Danke für die exemplarische Bedenken von @idris gelten immer noch für diese Lösung. Sie werden am Ende viele Ihrer Abhängigkeiten auf diese Weise aktualisieren, was möglicherweise unerwartet ist.

@danny-andrews kannst du erklären wie?

Wenn Sie yarn.lock löschen und yarn install erneut ausführen, wird das gesamte yarn.lock mit den neuesten Versionen von Abhängigkeiten neu erstellt, die die in package.json angegebenen Versionsbereiche erfüllen, effektiv Upgrade aller Abhängigkeiten, die sich seit der letzten Ausführung von yarn install geändert haben.

Aus diesem Grund habe ich git checkout origin/master -- yarn.lock anstatt yarn.lock löschen. Dadurch werden Ihre yarn.lock auf die Version auf dem Master zurückgesetzt, sodass die yarn install nur die Pakete aktualisieren können, die sich in Ihren package.json geändert haben (und natürlich deren Sub-Deps). .

@IanVS ja, das ist der richtige Weg.

Obwohl ich git checkout -- yarn.lock empfehlen würde, was allgemeiner ist und es einfach auf das zurücksetzt, was in Ihrem aktuellen Branch festgeschrieben ist.

Guter Punkt, @idris. Normalerweise rebasiere ich auf Master, was das Beispiel ist, das ich oben verwendet habe, aber das wird nicht immer der Fall sein.

@IanVS Ich habe nicht verstanden, was dieser Befehl tat. Das ist viel besser, als yarn.lock manuell zu kopieren und einzufügen, wie ich es bisher getan habe. Danke für das Teilen!

Dies ist verwandt: #3544

Ist der Ansatz von @IanVS nicht yarn install oben auf was auch immer yarn.lock ist bereits in der Filiale sind verschmelzenden Sie in.

Hier ist mein Ansatz, um ein Bash-Skript hinzuzufügen

#!/usr/bin/env bash
export GIT_TRACE=1
git checkout origin/master -- Pipfile.lock Pipfile
git commit -m "fetch to branch Pipfile.lock, Pipfile from origin/master" -- Pipfile.lock Pipfile
read  -n 1 -p "Do your changes in Pipfile and press Enter ..."
pipenv lock --clear
git commit -m "re-apply changes to Pipfile.lock, Pipfile" -- Pipfile.lock Pipfile
echo "Done"