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 ने एक यार्न.लॉक फ़ाइल के दो संस्करणों को इस तरह से मर्ज किया है जिसके परिणामस्वरूप एक वैध/सही फ़ाइल हो? यदि यार्न एकमात्र उपकरण है जो इसकी सामग्री को प्रबंधित करने वाला है, तो गिट को फ़ाइल की सामग्री को अपडेट करने देना गलत लगता है।

मुझे यकीन नहीं है कि 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 की चिंता अभी भी इस समाधान पर लागू होती है। आप इस तरह अपनी बहुत सारी निर्भरताओं को अपग्रेड करना समाप्त कर देंगे, जो अप्रत्याशित हो सकता है।

@ डैनी-एंड्रयूज क्या आप समझा सकते हैं कि कैसे?

जब आप का सफाया yarn.lock और फिर से चलाएं yarn install , पूरे yarn.lock कि संतुष्ट संस्करण में विनिर्दिष्ट सीमाओं निर्भरता के नवीनतम संस्करण के साथ फिर से बनाया जाता है package.json , प्रभावी ढंग से किसी भी निर्भरता को अपग्रेड करना जो पिछली बार yarn install चलाने के बाद से बदल गया है।

यही कारण है कि मैं सुझाव दिया है git checkout origin/master -- yarn.lock के बजाय को हटाने yarn.lock । यह आपके yarn.lock को मास्टर पर संस्करण में रीसेट कर देगा, yarn install को केवल उन पैकेजों को अपडेट करने की अनुमति देगा जो आपके package.json (और उनके उप-डिप्स, निश्चित रूप से) में बदल गए हैं। .

@IanVS हाँ, यह करने का यह सही तरीका है।

हालांकि मैं git checkout -- yarn.lock की अनुशंसा करता हूं, जो अधिक सामान्य है और इसे आपकी वर्तमान शाखा पर जो कुछ भी प्रतिबद्ध है उसे रीसेट करता है।

अच्छा बिंदु, @idris। मैं आमतौर पर मास्टर पर रिबेस करता हूं, जो कि मैंने ऊपर इस्तेमाल किया गया उदाहरण है, लेकिन यह हमेशा ऐसा नहीं होगा।

@IanVS मुझे समझ में नहीं आया कि उस आदेश ने क्या किया। यह yarn.lock मैन्युअल रूप से कॉपी और पेस्ट करने से कहीं बेहतर है जैसा कि मैं करता रहा हूं। साझा करने के लिए धन्यवाद!

यह संबंधित है: #3544

क्या @IanVS का दृष्टिकोण yarn install को उस शाखा में पहले से मौजूद yarn.lock ऊपर फिर से चलाएं जिसमें आप विलय कर रहे हैं।

यहाँ मेरा दृष्टिकोण है, एक बैश स्क्रिप्ट जोड़ने के लिए

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