Yarn: gitではyarn.lockをバイナリファイルとして扱う必要がありますか？

いいえ、すべきではありません。 ファイルはプレーンテキストであり、解決する必要のあるマージの競合がファイルに存在する可能性があります。

ドキュメントには、問題を回避するためにyarn.lockファイルに触れてはならず、yarn自体だけがそれを処理する必要があると書かれています。 次に、マージの競合をどのように解決しますか？

@kittensは、ロックファイルを吹き飛ばして糸を再実行するための競合がある場合に行うべき正しいことですか？ あなたが必要なものを手に入れるだろうと私には思えますか？

@dbashfordそれを吹き飛ばして糸を再実行するyarn upgrade実行していなくても、チルダバージョンはアップグレードされます。

@dbashfordなら、糸を入れるだけの方が簡単です。 gitignoreのロックファイル

これまで私のために働いてきたアプローチはこれです：

git rebase origin/master

最初の競合が発生したら、 yarn.lockをチェックアウトしてから、インストールを再実行します

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

これにより、 yarn.lockのオリジン/マスターバージョンに基づいて新しいyarn.lock生成されますが、 package.json加えた変更も含まれます。 次に、それはただの問題です：

git add yarn.lock
git rebase --continue

そして、私はビジネスに戻っています。

マージの競合を手動で解決していなくても、非バイナリファイルであるということは、マージの競合をを意味します。これは依然として貴重な情報です。

関連して、マージの競合が_no_ある場合でも、gitが2つのバージョンのyarn.lockファイルを有効/正しいファイルになるようにマージしたと常に想定できますか？ ヤーンがそのコンテンツを管理することになっている唯一のツールである場合、gitにファイルのコンテンツを更新させるのは間違っているようです。

YAMLの自動マージが常に有効なファイルになるかどうかはわかりませんが、特に次の場合に当てはまります。

• ロックファイル内で互いに隣接しているパッケージ内の複数のメジャーバージョン
• 2つの隣接するエントリの最初の行は、同じまたは類似のバージョンに解決するときに同時に変更できます。

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ウォークスルーをありがとう！ しかし、 @ idrisの懸念はこのソリューションにも当てはまります。 この方法で多くの依存関係をアップグレードすることになりますが、これは予期しないことです。

@ danny-andrewsどうやって説明できますか？

yarn.lockを消去してyarn install yarn.lockを再実行すると、 yarn.lock全体が、 package.jsonで指定されたバージョン範囲を満たす最新バージョンの依存関係で効果的に再構築されます。 yarn install最後に実行してから変更された依存関係をアップグレードします。

そのため、 yarn.lockを削除する代わりに、 git checkout origin/master -- yarn.lockを提案しました。 これにより、 yarn.lockがマスターのバージョンにリセットされ、 yarn installがpackage.json （およびもちろんそのサブディープ）で変更されたパッケージのみを更新できるようになります。 。

@IanVSはい、それが正しい方法です。

git checkout -- yarn.lockお勧めしますが、これはより一般的で、現在のブランチでコミットされているものにリセットするだけです。

良い点、@ idris。 私は通常、マスターにリベースします。これは上記で使用した例ですが、常にそうであるとは限りません。

@IanVSそのコマンドが何をするのか理解できませんでした。 これyarn.lock 、私が行っているように手動で

これは関連しています：＃3544

@IanVSのアプローチは、yarn.lock上に、持っているものを捨ててyarn installを再生するだけです。

これが私のアプローチで、bashスクリプトを追加します

#!/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"