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이 두 가지 버전의 yarn.lock 파일을 병합하여 유효한/올바른 파일을 생성한다고 항상 가정할 수 있습니까? yarn이 파일의 내용을 관리해야 하는 유일한 도구인 경우 git이 파일의 내용을 업데이트하도록 하는 것은 잘못된 것 같습니다.

특히 다음과 같이 YAML을 자동 병합하면 항상 유효한 파일이 생성되는지 확신할 수 없습니다.

• 잠금 파일에서 서로 바로 옆에 있는 패키지의 여러 주요 버전
• 두 개의 인접한 항목의 첫 번째 줄은 같거나 유사한 버전으로 확인하면서 동시에 변경될 수 있습니다.

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 버전이에 지정된 범위를 만족 의존성의 최신 버전으로 재 구축됩니다 package.json 효과적으로 yarn install 마지막 실행 이후 변경된 종속성을 업그레이드합니다.

그래서 yarn.lock 를 삭제하는 대신 git checkout origin/master -- yarn.lock 제안했습니다. 즉, 귀하의 재설정 yarn.lock 수 있도록 마스터의 버전에 yarn install 당신의 변경된 패키지 만 업데이트하는 package.json (물론 그들의 하위 deps를) .

@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"