अलग-अलग इतिहास वाली शाखाओं को मिलाएँ

• वंश से विचलन को पहचानें.
• एक स्पष्ट मर्ज रिकॉर्डिंग मोड चुनें.
• माता-पिता और संयुक्त सामग्री दोनों को सत्यापित करें।
• स्थानीय मर्ज को सर्वर प्रकाशन से अलग रखें.

जहां पाठ 17 समाप्त हुआ था वहां से प्रारंभ करें: माया की रीडमी प्रतिबद्धता के साथ मुख्य, स्वच्छ; प्रकाशित फीचर/मूल्य-कार्ड अभी भी F1 है, H5 से शाखाबद्ध है। आप तैयारी के रूप में MAIN_ACCESSIBLE को सहेजते हैं और प्रतिबद्ध करते हैं, ताकि मुख्य और सुविधा प्रत्येक में स्वतंत्र प्रतिबद्धता हो।

वीडियो को Git 2.52.0 और GitTree 2.0 के साथ Ubuntu 24.04 पर रिकॉर्ड किया गया था: पेज, उसका कमिट और मर्ज ऐप में किया गया था; पहले की स्थिति, एक अलग प्रतिलिपि में तेजी से आगे बढ़ने से इनकार कर दिया गया और चेक (परियोजना के स्वयं के लिंट, परीक्षण और निर्माण सहित) टर्मिनल में चला गया। macOS या Windows पर कुछ भी नहीं चलाया गया, और Ubuntu ही एकमात्र Linux सिस्टम रिकॉर्ड किया गया है। GitTree का स्रोत Git फ़्लोर 2.39.0 है।

GitTree आपसे साइन इन करने के लिए कहता है; फिर नि:शुल्क योजना यहां हर चरण को कवर करती है। किसी प्रदाता खाते, प्रो/ट्रायल, एपीआई क्रेडेंशियल या इंटरनेट सेवा की आवश्यकता नहीं है। स्थानीय मूल उत्पत्ति GitLab या सीआई नहीं है। सभी पहचान example.com का उपयोग करती हैं; इस पाठ को कभी भी स्रोत चेकआउट के अंदर न चलाएँ।

समान इनपुट पर या तो GitTree या मूल पथ के माध्यम से उत्परिवर्तन करें, दोनों लगातार नहीं। केवल पढ़ने योग्य सत्यापन का पालन किया जा सकता है। टर्मिनल कार्य के रूप में वर्णित किसी भी तैयारी को मूल तैयारी का लेबल दिया जाता है, कभी भी एक आविष्कृत ऐप सुविधा नहीं।

विचलन का मतलब है कि कोई भी टिप केवल वंशज नहीं है जिससे दूसरी शाखा तेजी से आगे बढ़ सके। Git एक सामान्य पूर्वज ढूंढता है और उसके सापेक्ष परिवर्तनों को जोड़ता है। केवल एक शाखा का नाम आपको यह नहीं बता सकता कि मर्ज कमिट की आवश्यकता है या नहीं।

एक मर्ज कमिट क्रम में दो माता-पिता को रिकॉर्ड करता है। पहला अभिभावक चेक-आउट शाखा का पूर्व टिप है; दूसरा विलयित पक्ष है। मौजूदा फीचर कमिट अपनी पहचान बनाए रखते हैं; एक नया मर्ज कमिट उनके वंश को जोड़ता है।

कोई भी पाठ्य विरोध शब्दार्थ शुद्धता का प्रमाण नहीं है। संपूर्ण फ़ाइल में फ़ोकस करने योग्य मुख्य, वर्कफ़्लो अनुभाग और लियो के अनुस्मारक को सत्यापित करें; मौजूदा जाँच चलाएँ. एक स्थानीय मर्ज एक अलग अधिकृत पुश तक मूल को अपडेट नहीं करता है।

तैयारी और मर्ज स्थानीय मुख्य/HEAD को स्थानांतरित करें और इंडेक्स/कार्य को अद्यतन करें। फीचर रेफरी F1 रहता है। दोनों मूल शाखाएँ और v0.1.0 अपनी पूर्व युक्तियाँ बरकरार रखते हैं।

मुख्य सेव MAIN_ACCESSIBLE पर, केवल इंडेक्स.html को स्टेज करें और फिक्स करें: मुख्य लैंडमार्क को फोकस करने योग्य बनाएं। यह मूल/ऐप मर्ज इनपुट को स्पष्ट बनाता है; विलय से पहले पहले से ही संयुक्त मर्ज की गई फ़ाइल को प्रतिबद्ध न करें।

केवल नीचे नामित चरण पर ही सहेजें। ये अंतिम नई लाइन के साथ पूर्ण UTF-8/LF निकाय हैं; कभी भी मार्कडाउन बाड़ चिपकाएँ नहीं। अपरिवर्तित चलने योग्य फ़ाइलें नामित इनपुट प्राप्त करती हैं। अलग-अलग संस्करणों में मूल को अधिलेखित नहीं किया जाना चाहिए।

Index.html - MAIN_ACCESSIBLE

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>GitTree Features — course demo</title>
  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <header class="site-header">
    <a href="#main">GitTree Features</a>
  </header>
  <main id="main" tabindex="-1">
    <section class="hero" aria-labelledby="hero-title">
      <p class="eyebrow">GitTree Learn demo project</p>
      <h1 id="hero-title">See your work clearly.</h1>
      <p id="hero-copy">Choose one change, then check what Git saved.</p>
    </section>
    <section class="features" aria-labelledby="features-title">
      <h2 id="features-title">Follow your work</h2>
      <div class="cards">
        <article class="feature-card">
          <h3>History</h3>
          <p>Read commits and branches together.</p>
        </article>
        <article class="feature-card">
          <h3>Changes</h3>
          <p>Review the exact content selected for a commit.</p>
        </article>
        <article class="feature-card">
          <h3>Recovery</h3>
          <p>Inspect the scope of a recovery point before using it.</p>
        </article>
      </div>
    </section>
  </main>
  <footer><p>Built by a fictional team for GitTree Learn. Review one change at a time.</p></footer>
  <script type="module" src="site.js"></script>
</body>
</html>

Index.html - मर्ज किया गया

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>GitTree Features — course demo</title>
  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <header class="site-header">
    <a href="#main">GitTree Features</a>
  </header>
  <main id="main" tabindex="-1">
    <section class="hero" aria-labelledby="hero-title">
      <p class="eyebrow">GitTree Learn demo project</p>
      <h1 id="hero-title">See your work clearly.</h1>
      <p id="hero-copy">Choose one change, then check what Git saved.</p>
    </section>
    <section class="features" aria-labelledby="features-title">
      <h2 id="features-title">Follow your work</h2>
      <div class="cards">
        <article class="feature-card">
          <h3>History</h3>
          <p>Read commits and branches together.</p>
        </article>
        <article class="feature-card">
          <h3>Changes</h3>
          <p>Review the exact content selected for a commit.</p>
        </article>
        <article class="feature-card">
          <h3>Recovery</h3>
          <p>Inspect the scope of a recovery point before using it.</p>
        </article>
      </div>
    </section>
    <section aria-labelledby="plans-title">
      <h2 id="plans-title">Choose the workflow you need</h2>
      <div class="cards">
        <article class="feature-card">
          <h3>Local Git</h3>
          <p>Local Git workflows work without signing in.</p>
        </article>
        <article class="feature-card">
          <h3>Connected workflows</h3>
          <p>Provider integrations and Nour require Pro or an applicable trial.</p>
        </article>
      </div>
    </section>
  </main>
  <footer><p>Built by a fictional team for GitTree Learn. Review one change at a time.</p></footer>
  <script type="module" src="site.js"></script>
</body>
</html>

पैलेट: Command+Shift+P (Ubuntu पर Ctrl+Shift+P); सटीक नामित कमांड टाइप करें और उसका चयन करें। नामांकित-रेफ क्रियाएँ उस पंक्ति के संदर्भ मेनू का उपयोग करती हैं, तर्क-मुक्त पैलेट शॉर्टकट का नहीं।

1. शो फ़ाइलें → Index.html → सहेजें के माध्यम से MAIN_ACCESSIBLE सहेजें; केवल टैबिंडेक्स जोड़ की समीक्षा करें।
2. कार्य परिवर्तन दिखाएँ; स्टेज फ़ाइल Index.html; कमिट फिक्स: सामान्य विकल्पों को बंद करके मुख्य लैंडमार्क को फोकस करने योग्य बनाएं।
3. मुख्य और फ़ीचर/मूल्य-कार्ड ग्राफ़ वंश का निरीक्षण करें; मुख्य जांच करते रहें.
4. लोकल के अंतर्गत feature फ़ोल्डर खोलें, pricing-cards → Merge feature/pricing-cards into main पर राइट-क्लिक करें। संवाद Record it as के साथ चलता है।
5. यदि संभव हो तो Record it as में विकल्प फास्ट-फॉरवर्ड होते हैं, अन्यथा एक मर्ज कमिट; Always a merge commit; केवल तेजी से आगे बढ़ना; और चरणबद्ध परिवर्तनों में स्क्वैश (कोई प्रतिबद्धता नहीं)। हमेशा एक मर्ज कमिट चुनें. यदि वास्तविक पूर्वावलोकन अप्रत्याशित पथ या विरोध दिखाता है तो रद्द करें।
6. एक बार मर्ज चुनें और वास्तविक समापन की प्रतीक्षा करें। स्क्वैश को चरणबद्ध परिवर्तनों में प्रतिस्थापित न करें।
7. परिणामी प्रतिबद्धता के दो माता-पिता का निरीक्षण करें और पूर्ण Index.html की तुलना MERGED से करें; सभी तीन स्वतंत्र परिवर्तनों को सत्यापित करें।
8. स्थानीय जाँच और स्वच्छ-स्थिति क्वेरी चलाएँ; मुख्य को स्थानीय मर्ज पर छोड़ दें, बिना किसी पुश आफ्टर कमिट के। ऐप का अपना मर्ज विषय "मर्ज ब्रांच 'फीचर/प्राइसिंग-कार्ड्स'" है; इसका नीचे दिए गए मूल संदेश से मेल खाना जरूरी नहीं है।

प्रत्येक सामान्य प्रतिबद्धता के लिए: सारांश बताया गया विषय है; विवरण रिक्त; पिछली प्रतिबद्धता में संशोधन करें, हुक छोड़ें, हस्ताक्षरित-ऑफ-बाय, अलग लेखक जोड़ें, प्रतिबद्धता के बाद पुश करें और खाली प्रतिबद्धता को अनुमति दें; कोई सह-लेखक नहीं. केवल नामित फ़ाइलों को चरणबद्ध करें, फिर एक बार एन फ़ाइलों में परिवर्तन करें (एक के लिए फ़ाइल), या विकल्प के रूप में कमांड+एंटर करें। वास्तविक परिणाम की प्रतीक्षा करें. एक पाठ जो स्पष्ट रूप से संशोधन करता है वह केवल उस बताए गए विकल्प को बदलता है।

MAIN_ACCESSIBLE सहेजने के बाद, मूल तैयारी और विलय:

git add -- index.html
git commit --quiet -m "fix: make the main landmark focusable"
git branch course-before-merge
git merge --quiet --no-ff feature/pricing-cards --message "merge: combine workflow cards with accessibility"
git log -1 --format=%s
git rev-list --parents -n 1 HEAD
git status --short

वास्तविक विषय:

merge: combine workflow cards with accessibility

मूल क्वेरी वास्तविक मर्ज SHA उत्सर्जित करती है जिसके बाद ठीक दो मूल SHA होते हैं; आईडी अलग-अलग होती हैं. संपूर्ण मर्ज किया गया इंडेक्स.एचटीएमएल फिक्स्चर में मर्ज किए गए बाइट-फॉर-बाइट से मेल खाता है; स्थिति खाली थी. स्पष्ट मूल विषय को ऐप के जेनरेट किए गए विषय से मेल खाने की आवश्यकता नहीं है: यदि वंश/सामग्री सहमत है तो वास्तविक ऐप संदेश स्वीकार करें, कभी भी नकली मूल संदेश को ओवरले न करें।

npm run --silent lint
npm test -- --test-reporter=tap
npm run --silent build

इन्हें मर्ज किए गए चेकपॉइंट के विरुद्ध चलाएँ; केवल स्रोत पाठ और मूल गणना से ही जाँच सिद्ध नहीं होती। फिक्सचर सुइट में छह परीक्षण हैं। डायवर्ज्ड इनपुट पर एक अलग एफएफ-ओनली प्रयास को चुपचाप इस मर्ज मोड को चुनने के बजाय अस्वीकार कर देना चाहिए।

Where you end: एम को पहले पैरेंट के साथ तैयार मुख्य टिप और दूसरे पैरेंट एफ1 के साथ विलय करने के मुख्य बिंदु; पूर्ण मर्ज किए गए पृष्ठ में वर्कफ़्लो कार्ड, लियो फ़ुटर और फ़ोकस करने योग्य मुख्य शामिल हैं। सूचकांक/कार्य साफ़; कोई दूरस्थ धक्का नहीं.

• गलत दिशा में विलय.
• स्क्वैश को दो-अभिभावक विलय कहना।
• अर्थपूर्ण प्रमाण के रूप में बिना किसी विरोध वाले पूर्वावलोकन पर भरोसा करना।

यदि कोई वास्तविक मर्ज रुक जाता है, तो उसकी संचालन स्थिति बनाए रखें और बाद में सिखाए गए संघर्ष/निरस्त वर्कफ़्लो का उपयोग करें; असंबंधित रीसेट जारी न करें. पूर्ण मूल मर्ज से पहले, कोर्स-बिफोर-मर्ज केवल पुराने प्रतिबद्ध टिप को संरक्षित करता है, मनमाने ढंग से काम करने वाले बाइट्स को नहीं।

प्रत्येक प्रश्न का उत्तर दें, फिर क्यों पढ़ें। "आवश्यक" चिह्नित प्रश्न पाठ को पूरा करने में गिने जाते हैं।

1. प्रश्न 1 में से 6

   प्रश्न 1 में से 6

   मर्ज कमिट को क्या विशिष्ट बनाता है?

   एक उत्तर चुनें.

   इसका रंग

   इसके विषय में मर्ज समाहित है

   एकाधिक माता-पिता

   उत्तर जांचें
2. प्रश्न 2 में से 6

   प्रश्न 2 में से 6

   कौन सा सबूत चाहिए?

   लागू होने वाला प्रत्येक उत्तर चुनें.

   माता-पिता दोनों की भूमिकाएँ

   केवल एक नो-कॉन्फ्लिक्ट लेबल

   संयुक्त पूरा पेज

   उत्तर जांचें
3. प्रश्न 3 में से 6

   प्रश्न 3 में से 6आवश्यक

   F1 की पहचान का क्या होता है?

   एक उत्तर चुनें.

   यह अपरिवर्तित रहता है

   इसे F1′ के रूप में पुनः चलाया जाता है

   यह मुख्य का पितृहीन मूल बन जाता है

   उत्तर जांचें
4. प्रश्न 4 में से 6

   प्रश्न 4 में से 6आवश्यक

   इस भिन्न इनपुट पर केवल ff चुनें: परिणाम?

   एक उत्तर चुनें.

   सुविधा विलोपन

   स्वचालित मर्ज प्रतिबद्धता

   इनकार

   उत्तर जांचें
5. प्रश्न 5 में से 6

   प्रश्न 5 में से 6

   कोई पाठ्य विरोध का अर्थ यह नहीं है कि परीक्षण अनावश्यक हैं?

   एक उत्तर चुनें.

   हाँ

   केवल माता-पिता की संख्या ही मायने रखती है

   नहीं

   उत्तर जांचें
6. प्रश्न 6 में से 6

   प्रश्न 6 में से 6आवश्यक

   अंतिम दायरा क्या है?

   लागू होने वाला प्रत्येक उत्तर चुनें.

   दो माता-पिता के साथ स्थानीय मुख्य एम

   सब कुछ स्वचालित रूप से धकेल दिया गया

   फ़ीचर F1 और सर्वर रेफरी अपरिवर्तित हैं

   उत्तर जांचें

F1 अपरिवर्तित के साथ सटीक मर्ज किए गए बाइट्स और दो वास्तविक माता-पिता को सत्यापित करें। भविष्यवाणी करें कि फास्ट-फॉरवर्ड केवल मूल डायवर्ज्ड इनपुट पर अस्वीकार करता है; केवल एक अलग प्रति में परीक्षण करें।

• विचलन एक पैतृक संबंध है.
• मर्ज पुरानी प्रतिबद्ध पहचानों को सुरक्षित रखता है।
• सामग्री और मूल जांच दोनों आवश्यक हैं।

• एक फीचर शाखा बनाएं और केवल डिस्पोजेबल रेफरी को रिटायर करें (पाठ 9)
• पुश कमिट करें और एक शाखा प्रकाशित करें (पाठ 13)
• डाउनलोड करें GitTree

मर्ज - دمج; मर्ज कमिट - إيداع دمج; सामान्य पूर्वज - سلف مشترك; पहले माता-पिता - الأب الأول.