Git
रिबेसिंग

वाक्य - विन्यास

• git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] [<upstream>] [<branch>]
• git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] --root [<branch>]
• git rebase --continue | --skip | --abort | --edit-todo

पैरामीटर

टिप्पणियों

स्थानीय शाखा रिबासिंग

रिबासिंग एक और प्रतिबद्ध के शीर्ष पर आने वाली श्रृंखलाओं को फिर से लागू करता है।

किसी शाखा को rebase करने के लिए, ब्रांच को चेकआउट करें और फिर दूसरी ब्रांच के शीर्ष पर rebase ।

git checkout topic
git rebase master  # rebase current branch onto master branch

यह कारण होगा:

      A---B---C topic
     /
D---E---F---G master

इसमें बदलने के लिए:

              A'--B'--C' topic
             /
D---E---F---G master

इन परिचालनों को एक एकल कमांड में जोड़ा जा सकता है जो शाखा की जाँच करता है और तुरंत इसे रद्द कर देता है:

git rebase master topic   # rebase topic branch onto master branch

महत्वपूर्ण: रिबास के बाद, लागू किए गए कमिट में एक अलग हैश होगा। आपको उन कमिटों को फिर से नहीं करना चाहिए जिन्हें आपने पहले ही रिमोट होस्ट में धकेल दिया है। परिणाम आपके स्थानीय विद्रोही शाखा को दूरस्थ होस्ट पर git push असमर्थता हो सकती है, जिससे आपको git push --force करने का एकमात्र विकल्प मिल जाएगा।

रीबेस: हमारा और उनका, स्थानीय और दूरस्थ

एक रिबास "हमारा" और "उनका" का अर्थ बताता है:

git checkout topic
git rebase   master    # rebase topic branch on top of master branch

जो भी HEAD की ओर इशारा करता है वह है "हमारा"

पहली बात जो रिबेट करता है वह master को HEAD रीसेट कर रहा है; इससे पहले कि चेरी-पिकिंग पुरानी शाखा के topic से एक नए से शुरू हो जाए (पूर्व topic शाखा में हर प्रतिबद्ध को फिर से लिखा जाएगा और एक अलग हैश द्वारा पहचाना जाएगा)।

मर्ज टूल्स द्वारा उपयोग की जाने वाली शब्दावली के संबंध में ( स्थानीय रेफ या दूरस्थ रेफरी के साथ भ्रमित होने की नहीं)

=> local is master ("ours"),
=> remote is topic ("theirs")

इसका मतलब है कि एक मर्ज / डिफ टूल अपस्ट्रीम ब्रांच को local ( master : उस ब्रांच जिसके ऊपर आप रिबासिंग कर रहे हैं), और वर्किंग ब्रांच को remote की तरह पेश करेंगे ( topic : ब्रांच रिबेड हो रही है)

+-----------------------------------------+
| LOCAL:master |    BASE   | REMOTE:topic |
+-----------------------------------------+
|             MERGED                      |
+-----------------------------------------+

उलटा सचित्र

एक मर्ज पर:

c--c--x--x--x(*) <- current branch topic ('*'=HEAD)
    \
     \
      \--y--y--y <- other branch to merge

हम वर्तमान शाखा topic को नहीं बदलते topic , इसलिए हमारे पास अभी भी वही है जो हम काम कर रहे थे (और हम दूसरी शाखा से विलय करते हैं)

c--c--x--x--x---------o(*)  MERGE, still on branch topic
    \       ^        /
     \     ours     /
      \            /
       --y--y--y--/  
               ^
              theirs

एक छूट पर:

लेकिन एक रिबेस पर हम पक्षों को बदल देते हैं क्योंकि एक रिबेज जो सबसे पहले होता है वह है अपस्ट्रीम ब्रांच को चेक करना ताकि उसके ऊपर से करंट चालू हो!

c--c--x--x--x(*) <- current branch topic ('*'=HEAD)
    \
     \
      \--y--y--y <- upstream branch

एक git rebase upstream पहले HEAD को अपस्ट्रीम ब्रांच में सेट करेगा, इसलिए पिछले "वर्तमान" वर्किंग ब्रांच की तुलना में 'हमारा' और 'उनका' का स्विच।

c--c--x--x--x <- former "current" branch, new "theirs"
    \
     \
      \--y--y--y(*) <- set HEAD to this commit, to replay x's on it
               ^       this will be the new "ours"
               |
            upstream      

रिबास फिर से 'नए' हमारी ' topic शाखा' पर अपना काम फिर से करेगा

c--c..x..x..x <- old "theirs" commits, now "ghosts", available through "reflogs"
    \
     \
      \--y--y--y--x'--x'--x'(*) <- topic  once all x's are replayed,
               ^                      point branch topic to this commit
               |
        upstream branch

इंटरएक्टिव रिबेस

इस उदाहरण का उद्देश्य यह वर्णन करना है कि इंटरएक्टिव मोड में git rebase का उपयोग कैसे किया जा सकता है। यह उम्मीद की जाती है कि कोई व्यक्ति इस बात की बुनियादी समझ रखता है कि git rebase क्या है और यह क्या करता है।

निम्नलिखित आदेश का उपयोग करके इंटरएक्टिव रिबास शुरू किया जाता है:

git rebase -i

-i विकल्प इंटरैक्टिव मोड को संदर्भित करता है । इंटरैक्टिव रिबास का उपयोग करके, उपयोगकर्ता प्रतिबद्ध संदेशों को बदल सकता है, साथ ही साथ पुन: विभाजित, विभाजित, और / या स्क्वैश (एक में गठबंधन) कर सकता है।

कहते हैं कि आप अपने पिछले तीन कमिट को फिर से व्यवस्थित करना चाहते हैं। ऐसा करने के लिए आप चला सकते हैं:

git rebase -i HEAD~3

उपरोक्त निर्देश को निष्पादित करने के बाद, आपके पाठ संपादक में एक फ़ाइल खोली जाएगी, जहाँ आप यह चुन सकेंगे कि आपके कमिट को कैसे रिबूट किया जाएगा। इस उदाहरण के उद्देश्य के लिए, बस अपने कमिट के क्रम को बदलें, फ़ाइल को सहेजें और संपादक को बंद करें। यह आपके द्वारा लागू किए गए आदेश से छूट प्रदान करेगा। यदि आप git log जांच करते हैं तो आप अपने नए ऑर्डर में आपके कमिट को देखेंगे।

रिकॉर्डिंग संदेश

अब, आपने निर्णय लिया है कि प्रतिबद्ध संदेशों में से एक अस्पष्ट है और आप चाहते हैं कि यह अधिक वर्णनात्मक हो। आइए एक ही कमांड का उपयोग करके पिछले तीन कमिट की जांच करें।

git rebase -i HEAD~3

आदेश को पुन: व्यवस्थित करने के बजाय, कमिट को फिर से शुरू किया जाएगा, इस बार हम pick , डिफॉल्ट को बदल देंगे, एक reword पर पुन: reword करने के लिए जहां आप संदेश बदलना चाहते हैं।

जब आप संपादक को बंद करते हैं, तो रिबेस शुरू हो जाएगा और यह उस विशिष्ट कमिट मैसेज पर रुक जाएगा, जिसे आप फिर से लिखना चाहते थे। यह आपको आपकी इच्छा को पूरा करने के लिए प्रतिबद्ध संदेश को बदलने देगा। संदेश बदलने के बाद, संपादक को आगे बढ़ने के लिए बस बंद करें।

एक कमिट की सामग्री को बदलना

कमिट मैसेज को बदलने के अलावा आप कमिट द्वारा किए गए बदलावों को भी अपना सकते हैं। ऐसा करने के लिए सिर्फ एक कमिट के लिए edit pick । जब यह कमिट आता है तो गेट बंद हो जाता है और स्टेजिंग क्षेत्र में कमिटमेंट के मूल परिवर्तन प्रदान करता है। अब आप उन परिवर्तनों को अस्थिर करके या नए परिवर्तन जोड़कर अनुकूलित कर सकते हैं।

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

एक एकल को कई में विभाजित करना

कहो कि आपने एक कमिट किया है, लेकिन बाद में निर्णय लिया है कि यह कमिट दो या दो से अधिक हिट में विभाजित हो सकती है। पहले की तरह ही आदेश का उपयोग करना, की जगह pick के साथ edit करने के बजाय और enter दबाएं।

अब, संपादन के लिए आपके द्वारा चिह्नित किए गए कमिट पर git रुक जाएगा और इसकी सभी सामग्री को स्टेजिंग क्षेत्र में रख देगा। उस बिंदु से आप अपने काम की निर्देशिका में कमिट करने के लिए git reset HEAD^ चला सकते हैं। फिर, आप अपनी फ़ाइलों को एक अलग क्रम में जोड़ सकते हैं और प्रतिबद्ध कर सकते हैं - अंततः एन कमिट्स में इसके बजाय एक ही कमिट को विभाजित कर सकते हैं।

एक में कई स्क्वैशिंग करना

कहते हैं कि आपने कुछ काम किया है और आपके पास कई सारे काम हैं जो आपको लगता है कि इसके बजाय एक ही प्रतिबद्ध हो सकते हैं। है कि आप बाहर ले जा सकता है के लिए git rebase -i HEAD~3 , की जगह 3 प्रतिबद्ध की एक उचित राशि के साथ।

इस बार squash जगह pick । रिबेस के दौरान, आपने जिस कमिटमेंट को स्क्वैश करने का निर्देश दिया है, उसे पिछली कमेटी के ऊपर स्क्वैश किया जाएगा; बदले में उन्हें एक ही कमिट में बदल दिया।

एक इंटरएक्टिव रिबेस को निरस्त करना

आपने एक इंटरेक्टिव रीबेस शुरू किया है। संपादक में जहां आप अपना कमिटमेंट चुनते हैं, आप तय करते हैं कि कुछ गलत हो रहा है (उदाहरण के लिए कोई कमिटमेंट गायब है, या आपने गलत रीबेस को चुना है), और आप रिबेट को निरस्त करना चाहते हैं।

ऐसा करने के लिए, बस सभी कमिट और एक्शन (यानी # साइन से शुरू नहीं होने वाली सभी लाइनें) डिलीट कर दें और रिबास निरस्त कर दिया जाएगा!

संपादक का सहायता पाठ वास्तव में यह संकेत प्रदान करता है:

# Rebase 36d15de..612f2f7 onto 36d15de (3 command(s))
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# Note that empty commits are commented out

एक छूट के बाद धक्का

कभी-कभी आपको एक रीबेस के साथ इतिहास को फिर से लिखने की आवश्यकता होती है, लेकिन git push ऐसा करने के बारे में शिकायत करता है क्योंकि आपने इतिहास को फिर से लिखा है।

इसे एक git push --force साथ हल किया जा सकता है, लेकिन git push --force-with-lease पर विचार करें, यह दर्शाता है कि आप चाहते हैं कि यदि स्थानीय रिमोट-ट्रैकिंग शाखा दूरस्थ से शाखा से भिन्न हो, तो आप असफल होना चाहते हैं, जैसे, कोई अंतिम लाने के बाद रिमोट पर धकेल दिया गया। यह अनजाने में किसी और के हालिया पुश ओवरराइटिंग से बचा जाता है।

नोट : git push --force - और यहां तक कि उस मामले के लिए --force-with-lease - एक खतरनाक कमांड हो सकता है क्योंकि यह शाखा के इतिहास को फिर से लिखता है। यदि किसी अन्य व्यक्ति ने जबरन धक्का देने से पहले शाखा को खींच लिया था, तो उसके / उसके git pull या git fetch में त्रुटियां होंगी क्योंकि स्थानीय इतिहास और दूरस्थ इतिहास को बदल दिया जाता है। इससे व्यक्ति को अप्रत्याशित त्रुटियां हो सकती हैं। रिफ्लेक्स को देखने के साथ ही अन्य उपयोगकर्ता के काम को पुनः प्राप्त किया जा सकता है, लेकिन यह बहुत समय बर्बाद कर सकता है। यदि आपको अन्य योगदानकर्ताओं के साथ शाखा के लिए एक मजबूर धक्का करना चाहिए, तो उनके साथ समन्वय करने का प्रयास करें ताकि उन्हें त्रुटियों से निपटना न पड़े।

शुरुआती कमिटमेंट को रिबेस करें

Git 1.7.12 के बाद से रूट कमिट के लिए रिबेस करना संभव है। रूट कमिट एक रिपॉजिटरी में बनाया गया पहला कमिट है, और आम तौर पर इसे संपादित नहीं किया जा सकता है। निम्न आदेश का उपयोग करें:

git rebase -i --root

एक कोड समीक्षा से पहले रिबासिंग

सारांश

इस लक्ष्य को आसान कोड समीक्षा के लिए अपने सभी बिखरे हुए कमिट्स को और अधिक सार्थक कमानों में पुनर्गठित करना है। यदि एक साथ बहुत सारी फ़ाइलों में परिवर्तनों की बहुत सारी परतें हैं, तो कोड समीक्षा करना कठिन है। यदि आप सामयिक रूप से बनाए गए अपने कालानुक्रमिक कार्यों को पुनर्गठित कर सकते हैं, तो कोड समीक्षा प्रक्रिया आसान है (और संभवत: कोड समीक्षा प्रक्रिया के माध्यम से कम बग फिसल जाते हैं)।

यह अति-सरलीकृत उदाहरण बेहतर कोड समीक्षा करने के लिए गिट का उपयोग करने के लिए एकमात्र रणनीति नहीं है। यह वह तरीका है जो मैं इसे करता हूं, और यह दूसरों को प्रेरित करने पर विचार करने के लिए है कि कोड समीक्षा और इतिहास को आसान / बेहतर कैसे बनाया जाए।

यह भी सामान्य रूप से रिबेस की शक्ति को प्रदर्शित करता है।

यह उदाहरण मानता है कि आप इंटरैक्टिव रिबासिंग के बारे में जानते हैं।

मान लिया जाये कि:

• आप मास्टर की एक सुविधा शाखा पर काम कर रहे हैं
• आपकी सुविधा में तीन मुख्य परतें हैं: फ्रंट-एंड, बैक-एंड, डीबी
• आपने एक सुविधा शाखा पर काम करते हुए बहुत सारे काम किए हैं। प्रत्येक प्रतिबद्ध एक ही बार में कई परतों को छूता है
• आप चाहते हैं (अंत में) आपकी शाखा में केवल तीन काम करता है
  • जिसमें सभी फ्रंट एंड में बदलाव होते हैं
  • सभी बैक एंड परिवर्तनों से युक्त
  • सभी DB परिवर्तनों वाले एक

रणनीति:

• हम अपने कालानुक्रमिक परिवर्तनों को "सामयिक" कमिट में बदलने जा रहे हैं।
• सबसे पहले, सभी कमिट्स को कई, छोटे कमिट में विभाजित करें - प्रत्येक में एक समय में केवल एक ही विषय होता है (हमारे उदाहरण में, विषय फ्रंट एंड, बैक एंड, डीबी परिवर्तन हैं)
• फिर एक साथ हमारे सामयिक प्रतिबद्धताओं को फिर से व्यवस्थित करें और उन्हें एकल सामयिक प्रतिबद्धताओं में बदल दें

उदाहरण:

$ git log --oneline master..
975430b db adding works: db.sql logic.rb
3702650 trying to allow adding todo items: page.html logic.rb
43b075a first draft: page.html and db.sql
$ git rebase -i master

यह पाठ संपादक में दिखाया जाएगा:

pick 43b075a first draft: page.html and db.sql
pick 3702650 trying to allow adding todo items: page.html logic.rb
pick 975430b db adding works: db.sql logic.rb

इसे इसमें बदलें:

e 43b075a first draft: page.html and db.sql
e 3702650 trying to allow adding todo items: page.html logic.rb
e 975430b db adding works: db.sql logic.rb

फिर git एक समय में एक प्रतिबद्ध लागू करेगा। प्रत्येक प्रतिबद्ध के बाद, यह एक संकेत दिखाएगा, और फिर आप निम्न कार्य कर सकते हैं:

Stopped at 43b075a92a952faf999e76c4e4d7fa0f44576579... first draft: page.html and db.sql
You can amend the commit now, with

        git commit --amend

Once you are satisfied with your changes, run

        git rebase --continue

$ git status
rebase in progress; onto 4975ae9
You are currently editing a commit while rebasing branch 'feature' on '4975ae9'.
  (use "git commit --amend" to amend the current commit)
  (use "git rebase --continue" once you are satisfied with your changes)

nothing to commit, working directory clean
$ git reset HEAD^ #This 'uncommits' all the changes in this commit.
$ git status -s
 M db.sql
 M page.html
$ git add db.sql  #now we will create the smaller topical commits
$ git commit -m "first draft: db.sql"
$ git add page.html
$ git commit -m "first draft: page.html"
$ git rebase --continue

फिर आप हर कमिट के लिए उन चरणों को दोहराएंगे। अंत में, आपके पास यह है:

$ git log --oneline
0309336 db adding works: logic.rb
06f81c9 db adding works: db.sql
3264de2 adding todo items: page.html
675a02b adding todo items: logic.rb
272c674 first draft: page.html
08c275d first draft: db.sql

अब हम रिबोर और स्क्वैश के लिए एक और बार रिबास चलाते हैं:

$ git rebase -i master

यह पाठ संपादक में दिखाया जाएगा:

pick 08c275d first draft: db.sql
pick 272c674 first draft: page.html
pick 675a02b adding todo items: logic.rb
pick 3264de2 adding todo items: page.html
pick 06f81c9 db adding works: db.sql
pick 0309336 db adding works: logic.rb

इसे इसमें बदलें:

pick 08c275d first draft: db.sql
s 06f81c9 db adding works: db.sql
pick 675a02b adding todo items: logic.rb
s 0309336 db adding works: logic.rb
pick 272c674 first draft: page.html
s  3264de2 adding todo items: page.html

सूचना: सुनिश्चित करें कि आप git rebase को लागू करने के लिए कहते हैं / छोटे सामयिक कमानों को स्क्वैश करने के लिए जिस क्रम में वे कालानुक्रमिक रूप से प्रशंसित थे । अन्यथा आप से निपटने के लिए झूठे, अनावश्यक विलय का सामना करना पड़ सकता है।

जब उस इंटरैक्टिव रिबेस को सभी ने कहा और किया है, तो आपको यह मिलता है:

$ git log --oneline master..
74bdd5f adding todos: GUI layer
e8d8f7e adding todos: business logic layer
121c578 adding todos: DB layer

संक्षिप्त

आपने अब अपने कालानुक्रमिक प्रतिबद्धताओं को सामयिक प्रतिबद्धताओं में बदल दिया है। वास्तविक जीवन में, आपको हर बार ऐसा करने की आवश्यकता नहीं हो सकती है, लेकिन जब आप ऐसा करना चाहते हैं या करना चाहते हैं, तो अब आप कर सकते हैं। इसके अलावा, उम्मीद है कि आपने गिट रिबेस के बारे में अधिक जानकारी प्राप्त की है।

मर्ज के बजाय स्वचालित रूप से रिबास के लिए सेटअप गिट-पुल

यदि आपकी टीम रिबेस-आधारित वर्कफ़्लो का अनुसरण कर रही है, तो यह गिट सेटअप करने के लिए एक फायदेमंद हो सकता है ताकि प्रत्येक नई बनाई गई शाखा एक रिसेट ऑपरेशन को मर्ज ऑपरेशन के बजाय, git pull दौरान करेगी।

स्वचालित रूप से .gitconfig करने के लिए हर नई शाखा को सेटअप करने के लिए, निम्न को अपने .gitconfig या .gitconfig .git/config जोड़ें।

[branch]
autosetuprebase = always

कमांड लाइन: git config [--global] branch.autosetuprebase always

वैकल्पिक रूप से, आप git pull कमांड को हमेशा व्यवहार करने के लिए सेटअप कर सकते हैं जैसे कि विकल्प --rebase पारित किया गया था:

[pull]
rebase = true

कमांड लाइन: git config [--global] pull.rebase true

सभी रिबास के दौरान परीक्षण

एक पुल अनुरोध करने से पहले, यह सुनिश्चित करना उपयोगी है कि संकलन सफल है और शाखा में प्रत्येक समिति के लिए परीक्षण गुजर रहे हैं। हम -x पैरामीटर का स्वचालित रूप से उपयोग कर सकते हैं।

उदाहरण के लिए:

git rebase -i -x make

प्रत्येक निष्पादित करने के लिए प्रतिबद्ध के बाद इंटरैक्टिव रिबेस और बंद प्रदर्शन करेंगे make । में मामला make विफल रहता है, Git आप मुद्दों को ठीक और संशोधन अगले एक उठा के साथ आगे बढ़ने से पहले प्रतिबद्ध करने के लिए एक मौका देने के लिए बंद हो जाएगा।

ऑटोस्टैश को कॉन्फ़िगर करना

स्थानीय परिवर्तनों के लिए रिबास का उपयोग करते समय ऑटोस्टैश एक बहुत ही उपयोगी विन्यास विकल्प है। अक्सर, आपको अपस्ट्रीम शाखा से कमिट में लाने की आवश्यकता हो सकती है, लेकिन अभी तक प्रतिबद्ध होने के लिए तैयार नहीं हैं।

हालांकि, Git कार्यशील निर्देशिका के साफ न होने पर रिबेट शुरू करने की अनुमति नहीं देता है। बचाव के लिए ऑटोस्टैश:

git config --global rebase.autostash    # one time configuration
git rebase @{u}                         # example rebase on upstream branch

जब भी रिबास समाप्त होगा, तो ऑटोस्टैश लागू किया जाएगा। इससे कोई फर्क नहीं पड़ता कि रिबास सफलतापूर्वक खत्म होता है, या यदि इसे निरस्त किया जाता है। किसी भी तरह से, ऑटोस्टैश लागू किया जाएगा। यदि रिबास सफल रहा, और बेस कमिट इसलिए बदल गया, तो ऑटोस्टैश और नए कमिट के बीच संघर्ष हो सकता है। इस मामले में, आपको संघर्ष करने से पहले समाधान करना होगा। यह अलग नहीं है यदि आप मैन्युअल रूप से धराशायी हो जाते हैं, और फिर लागू होते हैं, इसलिए इसे स्वचालित रूप से करने के लिए कोई नकारात्मक पहलू नहीं है।