अप्रकाशित कार्य को नए आधार पर पुनः आधार बनाएँ

• सटीक निजी रीप्ले रेंज की पहचान करें।
• पुनः चलाने से पहले पुराने प्रतिबद्ध इतिहास को सुरक्षित रखें।
• पुनः निर्मित प्रतिबद्ध पहचानों को पहचानें।
• मूल और पूर्ण परिणामी वृक्ष का सत्यापन करें।

पाठ 18 के परिणाम की एक अलग प्रति से शुरू करें (मुख्य मर्ज एम है, साफ): निजी विषय फीचर/साइनअप-फॉर्म में एक कमिट एस है, अपडेटेड-मेन में एक अलग कमिट एन है, दोनों एम पर हैं, और बचाव/साइनअप-बिफोर-रीबेस भी एस पर इंगित करता है। विषय की जांच की गई है, साफ और अप्रकाशित है।

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

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

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

रीबेस वर्तमान विषय के लिए अद्वितीय प्रतिबद्धताओं का चयन करता है और उनके परिवर्तनों को एक नए आधार पर दोहराता है। यह पुरानी प्रतिबद्धताओं को स्वयं नहीं हिलाता; यह नए माता-पिता और आमतौर पर नई आईडी के साथ नई प्रतिबद्धताएँ बनाता है।

स्रोत शाखा इच्छित वर्तमान शाखा होनी चाहिए। इस फिक्सचर में S साइनअप जोड़ता है और N एक अलग दस्तावेज़ जोड़ता है, इसलिए रीप्ले संघर्ष-मुक्त है, लेकिन यह मनमाने रिबेस को सुरक्षित नहीं बनाता है।

प्रकाशित इतिहास एक समन्वय सीमा है। ये प्रतिबद्धताएं जानबूझकर निजी हैं; केवल अपना ग्राफ सीधा करने के लिए पहले से प्रकाशित मूल्य निर्धारण सुविधा को दोबारा आधार न बनाएं। एक बचाव रेफरी प्रतिबद्ध वंश की रक्षा करता है, न कि सहेजे गए पाठ की नहीं।

फ़ीचर और हेड एडवांस S→S′; सूचकांक/कार्य संयुक्त वृक्ष बन जाता है। एन/अपडेटेड-मेन, रेस्क्यू एस और मूल मेन/एम स्थिर रहें। कोई सर्वर म्यूटेशन या स्वचालित पुश नहीं।

प्रोजेक्ट की एक अलग सामान्य प्रतिलिपि से प्रारंभ करें क्योंकि पाठ 18 ने इसे छोड़ दिया है (मुख्य मर्ज एम है)। मूल गिट्री-विशेषताएं संरक्षित रहती हैं; इस परिदृश्य को मूल या स्रोत चेकआउट में न चलाएं। फिर नीचे दी गई सटीक तैयारी करें। रेपो-लोकल डेमो साइनिंग बंद है और GitTree डेमो <demo@example.com> पहचान है।

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

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>
    <section aria-labelledby="signup-title">
      <h2 id="signup-title">Try the demo form</h2>
      <form id="signup-form" novalidate>
        <label for="demo-email">Demo email</label>
        <input id="demo-email" name="email" type="email" autocomplete="off" aria-describedby="signup-hint">
        <p id="signup-hint">Use a fictional example.com address. Nothing is sent.</p>
        <button type="submit">Check the address locally</button>
        <p id="signup-result" role="status"></p>
      </form>
    </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>

दस्तावेज़/एकीकरण-नोट.एमडी - DOC_MERGE

# Integration review

This note was written on main while signup work was private.

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

1. नीचे लेबल किए गए मूल सेटअप का उपयोग करके सटीक विचलन और बचाव शाखा तैयार करें; किसी भी प्रकाशित शाखा को दोबारा नहीं लिखा गया है।
2. ऐप में कन्फ़र्म फ़ीचर/साइनअप-फ़ॉर्म चेक आउट, साफ़ और अप्रकाशित; एस और एन का निरीक्षण करें.
3. ग्राफ़ में updated-main पर राइट-क्लिक करें → Rebase feature/signup-form onto updated-main; संवाद वर्तमान शाखा और लक्ष्य को नाम देता है।
4. पढ़ें Options for this rebase. Stash local changes and put them back और Move the branches that point into these commits को छोड़ दें। संवाद कहता है कि पुरानी सुविधा/साइनअप-फॉर्म को रेफरी/ओजीटी/ट्रैश के अंतर्गत रखा गया है।
5. एक बार Rebase feature/signup-form चुनें; रिबेस समाप्त होने की सूचना की प्रतीक्षा करें। यदि यह रुक जाता है, तो दोबारा क्लिक करने के बजाय इसकी संचालन स्थिति बनाए रखें।
6. S' अभिभावक N और विषय का निरीक्षण करें। टर्मिनल आउटपुट के रूप में मॉडल लेबल की नहीं, बल्कि वास्तविक पुरानी/नई आईडी की तुलना करें।
7. परिणामी पेड़ में पूर्ण साइनअप और DOC_MERGE का निरीक्षण करें; बचाव शाखा अभी भी पुराने एस की ओर इशारा करती है।
8. साफ़ स्थिति सत्यापित करें और कोई रिबेस ऑपरेशन नहीं; मूल मुख्य/एम और सभी सर्वर रेफरी को अकेला छोड़ दें।

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

एक अलग स्वच्छ पाठ 18/एम कॉपी में, निजी विषय बनाएं:

git switch --create feature/signup-form

सहेजी गई SIGNUP फ़ाइल को Index.html पर रखें (वीडियो ने पाठ की फ़ाइलों को ~/डाउनलोड में सहेजा है और cp ~/Downloads/SIGNUP.html index.html का उपयोग करता है), फिर:

git add -- index.html
git commit --quiet -m "feat: add the local signup demonstration"
git branch rescue/signup-before-rebase
BASE_SHA="$(git rev-parse HEAD~1)"
git switch --quiet --create updated-main "$BASE_SHA"

अपडेटेड-मेन पर DOC_MERGE को docs/integration-note.md (cp ~/Downloads/DOC_MERGE.md docs/integration-note.md) पर रखें, फिर:

git add -- docs/integration-note.md
git commit --quiet -m "docs: add the integration review"
git switch --quiet feature/signup-form

BASE_SHA निजी साइनअप प्रतिबद्धता से पहले मापा गया M पैरेंट है। विषय और अद्यतन-मुख्य दोनों की अब एक स्वतंत्र प्रतिबद्धता है; बचाव/साइनअप-बिफोर-रीबेस पुराने विषय को बरकरार रखता है। इस विषय से कुछ भी प्रकाशित नहीं है.

मूल रीप्ले विकल्प:

git rebase --quiet --no-autostash --no-update-refs --no-autosquash updated-main
git log -1 --format=%s
git rev-parse HEAD HEAD^ updated-main rescue/signup-before-rebase
git status --short

अवलोकन किया गया विषय:

feat: add the local signup demonstration

वास्तविक HEAD बचाए गए S से भिन्न है; हेड^ अद्यतन-मुख्य/एन के बराबर है। स्वतंत्र दस्तावेज़ और सटीक साइनअप निकाय दोनों बने रहते हैं; लघु स्थिति मौन है. बल विकल्प जोड़ने के बजाय अप्रत्याशित प्रकाशित/गंदे इनपुट पर रोकें। संघर्ष के प्रकार के लिए, पाठ 23 देखें; रुके हुए रिबेस को पहले ही समाप्त मान न लें।

Where you end: फीचर/साइनअप-फॉर्म पॉइंट S', पैरेंट N, साइनअप प्लस DOC_MERGE के साथ; पुराना S बचाव/साइनअप-बिफोर-रीबेस में बच जाता है। कोई ऑपरेशन सक्रिय, स्वच्छ नहीं; मुख्य/एम और सर्वर अपरिवर्तित.

• एक सीधा ग्राफ़ मानने का मतलब है कि पुरानी प्रतिबद्ध आईडी बची हुई है।
• वैकल्पिक फलक को मूल चेकपॉइंट के रूप में मानना।
• ऐप की सफलता के बाद पूर्ण उत्परिवर्तन को दोहराया जा रहा है।

दोबारा चलाने से पहले बचाव शाखा एस को बरकरार रखती है। यदि ऑपरेशन रुक जाता है, तो बैनर का निरीक्षण करें और समाधान करें या स्पष्ट रूप से निरस्त करें; पूर्ण रिबेस को रिबेस --एबॉर्ट द्वारा निरस्त नहीं किया जाता है। यह कभी न मानें कि नेटिव रीप्ले ने एक GitTree जर्नल लिखा है।

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

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

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

   क्या दोबारा खेला जाता है?

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

   प्रत्येक रिपॉजिटरी फ़ाइल आँख बंद करके

   दूरस्थ सर्वर

   निजी विषय परिवर्तन

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

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

   क्या जांचना चाहिए?

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

   वर्तमान शाखा एवं लक्ष्य

   निजी रेंज और बचाव रेफरी

   केवल ग्राफ़ रंग

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

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

   S को N पर पुनः चलाया गया: अभिभावक?

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

   अद्यतन-मुख्य प्रतिबद्धता एन

   S अपने माता-पिता के रूप में

   केवल पुराना एम

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

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

   इनपुट बदलें: दोनों तरफ एक ही हीरो लाइन बदल गई।

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

   हमेशा कोई विवाद नहीं

   एक तरफ को स्वचालित रूप से त्यागें

   किसी विरोध के कारण दोबारा खेलना बंद हो सकता है

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

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

   क्या --abort पहले से ही समाप्त रिबेस को पूर्ववत कर सकता है?

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

   यह सर्वर पुश को पूर्ववत करता है

   हमेशा

   कोई सक्रिय ऑपरेशन मौजूद नहीं है

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

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

   यह परिणाम क्या सिद्ध करता है?

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

   नई आईडी और मूल एन

   पुराने एस को बचाया गया, पूरी फ़ाइलें साफ़ की गईं

   केवल संदेश अपरिवर्तित

   उत्तर जांचें

सिद्ध करें कि नया HEAD बचाव से भिन्न है, इसका मूल भाग N के बराबर है और पूर्ण साइनअप/दस्तावेज़ बाइट्स सहमत हैं। यदि दोनों पक्ष एक ही नायक पंक्ति को बदलते हैं, तो एक अलग पाठ 23 प्रति में टकराव की भविष्यवाणी करें।

• रीबेस कमिट को दोबारा बनाता है।
• वर्तमान शाखा चुनें और स्पष्ट रूप से लक्ष्य करें।
• निजी इतिहास और पुनर्प्राप्ति का दायरा मायने रखता है।

• अलग-अलग इतिहास वाली शाखाओं को मिलाएं (पाठ 18)
• फ़ास्ट-फ़ॉरवर्ड मर्ज को समझें (पाठ 19)
• एक फीचर शाखा बनाएं और केवल डिस्पोजेबल रेफरी को रिटायर करें (पाठ 9)
• डाउनलोड करें GitTree

रिबेस - إعادة تأسيس; फिर से खेलना - إعادة تطبيق; बचाव रेफरी - مرجع حفظ.