सवाल गिट के साथ एक नई शाखा में सबसे हालिया प्रतिबद्धताओं को ले जाएं


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

अर्थात। मैं इससे कैसे जा सकता हूं

master A - B - C - D - E

इसके लिए?

newbranch     C - D - E
             /
master A - B 

3762
2017-10-27 03:07


मूल


नोट: मैंने विपरीत सवाल पूछा यहाँ - Benjol
के संभावित डुप्लिकेट गिट का उपयोग कर मास्टर से एक शाखा में ले जाएं - Chris Moschini
eddmann.com/posts/... यह एक काम करता है - Sagar Naliyapara
क्या यहां टिप्पणियां शुद्ध थीं? मैं पूछता हूं क्योंकि मेरे प्रश्नोत्तरी के दौरान इस प्रश्न पर जाएं, मैं हमेशा उस टिप्पणी से स्क्रॉल करता हूं। - Tejas Kale


जवाब:


एक नई शाखा में जा रहे हैं

चेतावनी: यह विधि काम करती है क्योंकि आप पहली कमांड के साथ एक नई शाखा बना रहे हैं: git branch newbranch। यदि आप एक को स्थानांतरित करना चाहते हैं मौजूदा शाखा निष्पादन से पहले आपको मौजूदा शाखा में अपने परिवर्तनों को मर्ज करना होगा git reset --hard HEAD~3 (देख मौजूदा शाखा में जा रहे हैं नीचे)। यदि आप पहले अपने बदलावों को मर्ज नहीं करते हैं, तो वे खो जाएंगे।

जब तक अन्य परिस्थितियां शामिल न हों, तब तक इसे आसानी से ब्रांचिंग और रोलिंग करके किया जा सकता है।

# Note: Any changes not committed will be lost.
git branch newbranch      # Create a new branch, saving the desired commits
git reset --hard HEAD~3   # Move master back by 3 commits (GONE from master)
git checkout newbranch    # Go to the new branch that still has the desired commits

लेकिन यह सुनिश्चित करें कि कितने लोग वापस जाने के लिए प्रतिबद्ध हैं। वैकल्पिक रूप से, आप इसके बजाय कर सकते हैं HEAD~3, बस प्रतिबद्धता के हैश प्रदान करें (या जैसे संदर्भ मूल / मास्टर) आप "वापस वापस" करना चाहते हैं स्वामी (/ वर्तमान) शाखा, उदाहरण:

git reset --hard a1b2c3d4

* 1 आप करेंगे केवल मास्टर शाखा से "हारने" हो, लेकिन चिंता न करें, आप नए ब्रांच में काम करेंगे!

चेतावनी: गिट संस्करण 2.0 और बाद में, यदि आप बाद में git rebase मूल पर नई शाखा (master) शाखा, आपको एक स्पष्ट की आवश्यकता हो सकती है --no-fork-point ले जाने वाले कामों को खोने से बचने के लिए रिबेस के दौरान विकल्प। बीत रहा है branch.autosetuprebase always सेट यह और अधिक संभावना बनाता है। देख जॉन मेलर का जवाब ब्योरा हेतु।

मौजूदा शाखा में जा रहे हैं

यदि आप अपनी प्रतिबद्धताओं को एक स्थानांतरित करना चाहते हैं मौजूदा शाखा, यह इस तरह दिखेगा:

git checkout existingbranch
git merge master
git checkout master
git reset --hard HEAD~3 # Go back 3 commits. You *will* lose uncommitted work.
git checkout existingbranch

4795
2017-07-22 22:37



खास तरीके से, नहीं उस बिंदु से आगे वापस जाने का प्रयास करें जहां आपने पिछली बार दूसरी रिपोजिटरी में प्रवेश किया था, जिससे किसी और ने खींचा होगा। - Greg Hewgill
आश्चर्य है कि अगर आप यह बता सकते हैं कि यह क्यों काम करता है। मेरे लिए आप एक नई शाखा बना रहे हैं, पुरानी शाखा से 3 कामों को हटा रहे हैं, और फिर आपके द्वारा बनाई गई शाखा की जांच कर रहे हैं। तो नई शाखा में आप जादूगर को कैसे हटाते हैं? - Jonathan Dumaine
@ जोनाथन ड्यूमाइन: क्योंकि मैंने पुरानी शाखा से काम करने से पहले नई शाखा बनाई थी। वे अभी भी नई शाखा में हैं। - sykora
गिट में शाखाएं सिर्फ मार्कर हैं जो इतिहास में काम करने के लिए इंगित करती हैं, क्लोन, बनाई गई या हटाई गई कुछ भी नहीं है (मार्कर को छोड़कर) - knittl
यह भी ध्यान दें: अपनी कामकाजी प्रति में असामान्य परिवर्तनों के साथ ऐसा न करें! यह बस मुझे थोड़ा सा! :( - Adam Tuttle


उन लोगों के लिए सोच रहा है कि यह क्यों काम करता है (जैसा कि मैं पहले था):

आप सी पर वापस जाना चाहते हैं, और डी और ई को नई शाखा में ले जाना चाहते हैं। यह पहले जैसा दिखता है:

A-B-C-D-E (HEAD)
        ↑
      master

बाद git branch newBranch:

    newBranch
        ↓
A-B-C-D-E (HEAD)
        ↑
      master

बाद git reset --hard HEAD~2:

    newBranch
        ↓
A-B-C-D-E (HEAD)
    ↑
  master

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


847
2018-02-07 16:58



आपको आवश्यकता है - क्योंकि, अन्यथा गिट रीसेट से परिवर्तनों को काम करने वाली निर्देशिका में करता है (या कम से कम मेरे लिए किया जाता है)। - Andrew
मुझे भी ऐसा करने की ज़रूरत है git push origin master --force मुख्य भंडार में परिवर्तन के लिए परिवर्तन के लिए। - Dženan
यह उत्तर कम करने का कारण बनता है: अगली बार आप git rebase, 3 काम चुपचाप से त्याग दिया जाएगा newbranch। देख मेरा जवाब विवरण और सुरक्षित विकल्पों के लिए। - John Mellor
@ जॉन, यह बकवास है। यह जानने के बिना कि आप क्या कर रहे हैं, खोने का कारण बनता है। यदि आप काम करते हैं, तो मुझे आपके लिए खेद है, लेकिन यह जवाब आपकी प्रतिबद्धता खो नहीं पाया। ध्यान दें कि origin/master उपरोक्त आरेख में प्रकट नहीं होता है। यदि आप को धक्का दिया जाता है origin/master और फिर उपरोक्त परिवर्तन किए, निश्चित रूप से, चीजें मजाकिया हो जाएंगी। लेकिन यह एक "डॉक्टर है, जब मैं ऐसा करता हूं तो यह दर्द होता है" समस्या। और मूल प्रश्न पूछने के लिए यह दायरे से बाहर है। मेरा सुझाव है कि आप इस परिदृश्य को अपहरण करने के बजाय अपने परिदृश्य का पता लगाने के लिए अपना खुद का प्रश्न लिखें। - Ryan Lundy
@ जॉन, आपके जवाब में, आपने कहा "ऐसा मत करो! git branch -t newbranch"वापस जाएं और जवाब दोबारा पढ़ें। कोई भी नहीं ऐसा करने का सुझाव दिया। - Ryan Lundy


सामान्य रूप में...

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

ओपी चाहता है कि यह प्राप्त करने के लिए, यह एक 2-चरणीय प्रक्रिया है:

चरण 1 - नोट जो मास्टर से आप चाहते हैं वह करता है newbranch

निष्पादित

git checkout master
git log

ध्यान दें कि (3 कहें) के हैंश पर आप चाहते हैं newbranch। यहां मैं उपयोग करूंगा:
सी प्रतिबद्धता: 9aa1233
डी प्रतिबद्धता: 453ac3d
ई प्रतिबद्ध: 612ecb3 

ध्यान दें: आप पहले सात अक्षर या उपयोग कर सकते हैं   पूरी प्रतिबद्ध हैश

चरण 2 - उन्हें रखो newbranch

git checkout newbranch
git cherry-pick 612ecb3
git cherry-pick 453ac3d
git cherry-pick 9aa1233

या (गिट 1.7.2+ पर, श्रेणियों का उपयोग करें)

git checkout newbranch
git cherry-pick 612ecb3~1..9aa1233

गिट चेरी-पिक उन तीन कामों को न्यूब्रैंच पर लागू करता है।


343
2018-03-26 08:13



ओपी नहीं जाने की कोशिश कर रहा था से स्वामी सेवा मेरे नई शाखा? यदि आप मास्टर पर चेरी-पिक चुनते हैं, तो आप मास्टर शाखा में जोड़ देंगे - जो वास्तव में पहले से ही काम करता है। और यह शाखा के सिर को वापस बी में नहीं ले जाता है या क्या कुछ सूक्ष्म और ठंडा है जो मुझे नहीं मिल रहा है? - RaveTheTadpole
यदि आप गलती से गलत, गैर-मास्टर शाखा करते हैं, तो यह बहुत अच्छी तरह से काम करता है, जब आपको एक नई सुविधा शाखा बनाना चाहिए था। - julianc
कुछ स्थितियों में उपयोगी दृष्टिकोण के लिए +1। यह अच्छा है अगर आप केवल अपनी खुद की प्रतिबद्धताओं (जो दूसरों के साथ छेड़छाड़ कर रहे हैं) को एक नई शाखा में खींचना चाहते हैं। - Tyler V.
यह बेहतर जवाब है। इस तरह आप किसी भी शाखा में काम कर सकते हैं। - skywinder
चेरी चुनने का आदेश महत्वपूर्ण है? - kon psych


अभी तक केवल 2 कमांड का उपयोग करके ऐसा करने का एक और तरीका है। अपने वर्तमान काम कर रहे पेड़ को बरकरार रखता है।

git checkout -b newbranch # switch to a new branch
git branch -f master HEAD~3 # make master point to some older commit

पुराना संस्करण - इससे पहले कि मैंने सीखा git branch -f

git checkout -b newbranch # switch to a new branch
git push . +HEAD~3:master # make master point to some older commit 

करने में सक्षम push सेवा मेरे . जानना एक अच्छी चाल है।


252
2018-04-06 22:38



वर्तमान निर्देशिका। मुझे लगता है कि यह केवल तभी काम करेगा यदि आप शीर्ष निर्देशिका में हैं। - aragaer
स्थानीय धक्का grin-inducing है, लेकिन प्रतिबिंब पर, यह कैसे अलग है git branch -f यहाँ? - jthill
@GerardSexton . वर्तमान निदेशक है। गिट रिमोट्स या जीआईटी यूआरएल को धक्का दे सकता है। path to local directory गिट यूआरएल वाक्यविन्यास समर्थित है। में जीआईटी यूआरएल अनुभाग देखें git help clone। - weakish
मुझे नहीं पता कि यह उच्च मूल्यांकन क्यों नहीं किया गया है। मृत सरल, और गिट रीसेट के छोटे लेकिन संभावित खतरे के बिना - हार्ड। - Godsmith
@ गोडस्मिथ मेरा अनुमान है कि लोग तीन सरल कमांड को दो थोड़ा अधिक अस्पष्ट आदेशों में पसंद करते हैं। इसके अलावा, शीर्ष वोट वाले उत्तरों को पहले प्रदर्शित होने की प्रकृति द्वारा अधिक अपवर्तक प्राप्त होते हैं। - JS_Riddler


सबसे पिछले जवाब खतरनाक रूप से गलत हैं!

यह मत करो:

git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch

अगली बार जब आप दौड़ते हैं git rebase (या git pull --rebase) उन 3 कामों को चुपचाप से त्याग दिया जाएगा newbranch! (नीचे स्पष्टीकरण देखें)

इसके बजाए ऐसा करें:

git reset --keep HEAD~3
git checkout -t -b newbranch
git cherry-pick ..HEAD@{2}
  • सबसे पहले यह 3 सबसे हालिया कामों को छोड़ देता है (--keep के समान ही --hard, लेकिन सुरक्षित, असम्बद्ध परिवर्तनों को फेंकने के बजाए विफल रहता है)।
  • फिर यह बंद हो जाता है newbranch
  • फिर यह चेरी-पिक्स उन 3ों को वापस चालू करता है newbranch। चूंकि अब उन्हें किसी शाखा द्वारा संदर्भित नहीं किया जाता है, इसलिए यह गिट का उपयोग करके करता है reflog: HEAD@{2} वह प्रतिबद्धता है HEAD 2 ऑपरेशंस पहले संदर्भित करने के लिए प्रयोग किया जाता था, यानी हम पहले 1. चेक आउट newbranch और 2. इस्तेमाल किया git reset 3 कामों को त्यागने के लिए।

चेतावनी: डिफ़ॉल्ट रूप से रीफ्लॉग सक्षम है, लेकिन यदि आपने इसे मैन्युअल रूप से अक्षम कर दिया है (उदा। "बेयर" गिट रिपोजिटरी का उपयोग करके), आप दौड़ने के बाद 3 को वापस नहीं कर पाएंगे git reset --keep HEAD~3

एक विकल्प जो रिफ्लॉग पर भरोसा नहीं करता है:

# newbranch will omit the 3 most recent commits.
git checkout -b newbranch HEAD~3
git branch --set-upstream-to=oldbranch
# Cherry-picks the extra commits from oldbranch.
git cherry-pick ..oldbranch
# Discards the 3 most recent commits from oldbranch.
git branch --force oldbranch oldbranch~3

(यदि आप पसंद करते हैं तो आप लिख सकते हैं @{-1} - पहले की जाँच की गई शाखा - इसके बजाए oldbranch)।


तकनीकी स्पष्टीकरण

क्यों होता git rebase पहले उदाहरण के बाद 3 कामों को त्यागें? ये इसलिए git rebase बिना किसी तर्क के सक्षम बनाता है --fork-point डिफॉल्ट रूप से विकल्प, जो स्थानीय रेफ्लॉग का उपयोग करता है ताकि अपस्ट्रीम शाखा के खिलाफ बलपूर्वक धक्का दिया जा सके।

मान लीजिए कि जब आपने एम 1, एम 2, एम 3 को नियुक्त किया है तो आपने मूल / मास्टर को ब्रांच किया है, फिर तीन ने खुद को बनाया है:

M1--M2--M3  <-- origin/master
         \
          T1--T2--T3  <-- topic

लेकिन फिर कोई व्यक्ति एम 2 को हटाने के लिए बल-पुशिंग मूल / मास्टर द्वारा इतिहास को फिर से लिखता है:

M1--M3'  <-- origin/master
 \
  M2--M3--T1--T2--T3  <-- topic

अपने स्थानीय रिफ्लॉग का उपयोग करना, git rebase देख सकते हैं कि आपने मूल / मास्टर शाखा के पहले अवतार से फोर्क किया था, और इसलिए एम 2 और एम 3 प्रतिबद्धता वास्तव में आपकी विषय शाखा का हिस्सा नहीं हैं। इसलिए यह उचित रूप से मानता है कि एम 2 को अपस्ट्रीम शाखा से हटा दिया गया था, इसलिए जब आप विषय शाखा का पुन: उपयोग कर लेते हैं तो आप इसे अपनी विषय शाखा में नहीं चाहते हैं:

M1--M3'  <-- origin/master
     \
      T1'--T2'--T3'  <-- topic (rebased)

यह व्यवहार समझ में आता है, और आम तौर पर पुन: प्रयास करते समय करना सही होता है।

तो कारण निम्न आदेश विफल:

git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch

ऐसा इसलिए है क्योंकि वे गलत स्थिति में रिफ्लॉग छोड़ देते हैं। गिट देखता है newbranch जैसा कि एक संशोधन में अपस्ट्रीम शाखा को फेंक दिया गया है जिसमें 3 काम शामिल हैं, फिर reset --hard काम को हटाने के लिए अपस्ट्रीम के इतिहास को फिर से लिखता है, और अगली बार जब आप दौड़ते हैं git rebase यह उन्हें किसी अन्य प्रतिबद्धता की तरह त्याग देता है जिसे अपस्ट्रीम से हटा दिया गया है।

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

अधिक जानकारी के लिए, की परिभाषा देखें --fork-point में गिट रिबेस तथा गिट मर्ज बेसडॉक्स।


210
2017-10-19 14:12



यह जवाब कहता है "ऐसा मत करो!" किसी चीज से ऊपर कोई भी सुझाव नहीं दिया। - Ryan Lundy
@ किरालेसा, द -t आप में जिक्र कर रहे हैं git branch यदि आपके पास है तो निश्चित रूप से होता है git config --global branch.autosetuprebase always सेट। भले ही आप नहीं करते हैं, मैं पहले ही समझाया गया है आप के लिए एक ही समस्या तब होती है जब आप इन आदेशों को निष्पादित करने के बाद ट्रैकिंग सेट अप करते हैं, क्योंकि ओपी संभवतः अपना प्रश्न देने का इरादा रखता है। - John Mellor
@ रॉकली, हां, सामान्य परिस्थितियों को ठीक करने का तरीका एक सुरक्षित प्रारंभिक बिंदु से एक नई शाखा (newbranch2) बनाना है, फिर चेरी-उन सभी कामों को चुनें जिन्हें आप रखना चाहते हैं (Badnewbranch से newbranch2 तक)। चेरी-पिकिंग नए हैंश को प्रतिबद्ध करेगी, इसलिए आप सुरक्षित रूप से newbranch2 को पुनः प्राप्त करने में सक्षम होंगे (और अब Badnewbranch को हटा सकते हैं)। - John Mellor
@Walf, आप गलत समझा: गिट रिबेस अपने इतिहास को फिर से लिखने वाले अपस्ट्रीम के खिलाफ मजबूत होने के लिए डिज़ाइन किया गया है। दुर्भाग्यवश, उस मजबूती के दुष्प्रभाव सभी को प्रभावित करते हैं, भले ही न तो वे और न ही उनके अपस्ट्रीम ने इतिहास को फिर से लिखा हो। - John Mellor
आप भी उपयोग कर सकते हैं --no-fork-point जब आप दौड़ते हैं git rebase। - torek


यह उन्हें तकनीकी अर्थ में "स्थानांतरित" नहीं करता है लेकिन इसका एक ही प्रभाव है:

A--B--C  (branch-foo)
 \    ^-- I wanted them here!
  \
   D--E--F--G  (branch-bar)
      ^--^--^-- Opps wrong branch!

While on branch-bar:
$ git reset --hard D # remember the SHAs for E, F, G (or E and G for a range)

A--B--C  (branch-foo)
 \
  \
   D-(E--F--G) detached
   ^-- (branch-bar)

Switch to branch-foo
$ git cherry-pick E..G

A--B--C--E'--F'--G' (branch-foo)
 \   E--F--G detached (This can be ignored)
  \ /
   D--H--I (branch-bar)

Now you won't need to worry about the detached branch because it is basically
like they are in the trash can waiting for the day it gets garbage collected.
Eventually some time in the far future it will look like:

A--B--C--E'--F'--G'--L--M--N--... (branch-foo)
 \
  \
   D--H--I--J--K--.... (branch-bar)

27
2018-01-21 16:10



आप उपयोग नहीं कर सकते rebase एक ही चीज़ के लिए? - Bergi
हाँ आप वैकल्पिक रूप से उपयोग कर सकते हैं rebase उपरोक्त परिदृश्य में अलग शाखा पर। - Sukima


इतिहास को फिर से लिखने के बिना ऐसा करने के लिए (यानी यदि आपने पहले से ही काम किया है):

git checkout master
git revert <commitID(s)>
git checkout -b new-branch
git cherry-pick <commitID(s)>

तब दोनों शाखाओं को बल के बिना धकेल दिया जा सकता है!


19
2017-09-20 10:17



लेकिन फिर आपको रिवर्ट परिदृश्य से निपटना होगा, जो आपके परिस्थिति के आधार पर बहुत कठिन हो सकता है। यदि आप शाखा पर एक प्रतिबद्धता वापस लेते हैं, तो गिट अभी भी उन लोगों को देखेगा जो कि किए गए हैं, इसलिए इसे पूर्ववत करने के लिए, आपको वापस लौटना होगा। यह बहुत से लोगों को जला देता है, खासकर जब वे विलय को वापस लाते हैं और शाखा को वापस विलय करने का प्रयास करते हैं, केवल यह पता लगाने के लिए कि गिट का मानना ​​है कि यह पहले से ही उस शाखा में विलय कर चुका है (जो पूरी तरह से सच है)। - Makoto
यही कारण है कि मैं अंत में एक नई शाखा में, चेरी-चुनाव करता हूं। इस तरह गिट उन्हें नए काम के रूप में देखता है, जो आपकी समस्या हल करता है। - teh_senaus
यह पहले से कहीं अधिक खतरनाक है, क्योंकि आप वास्तव में इस राज्य के प्रभावों को समझने के बिना भंडार के इतिहास की स्थिति बदल रहे हैं। - Makoto
मैं आपके तर्क का पालन नहीं करता - इस उत्तर का मुद्दा यह है कि आप इतिहास बदल नहीं रहे हैं, बस नए काम जोड़ रहे हैं (जो प्रभावी रूप से परिवर्तनों को दोबारा पूर्ववत करें)। इन नए कामों को धक्का दिया जा सकता है और सामान्य के रूप में विलय किया जा सकता है। - teh_senaus


बस इस स्थिति में था:

Branch one: A B C D E F     J   L M  
                       \ (Merge)
Branch two:             G I   K     N

मैंने प्रदर्शन किया:

git branch newbranch 
git reset --hard HEAD~8 
git checkout newbranch

मुझे उम्मीद थी कि प्रतिबद्धता मैं सिर होगी, लेकिन प्रतिबद्धता एल अब है ...

इतिहास में सही स्थान पर उतरने के लिए सुनिश्चित करना सुनिश्चित करें कि प्रतिबद्धता के हैश के साथ काम करना आसान हो

git branch newbranch 
git reset --hard #########
git checkout newbranch

12
2018-05-01 07:50





बहुत आसान समाधान

अगर:

  1. आपका प्राथमिक उद्देश्य वापस रोल करना है master, तथा
  2. आप परिवर्तन रखना चाहते हैं लेकिन विशेष रूप से इसकी परवाह नहीं करते हैं व्यक्तिगत काम करता है, और
  3. आपने अभी तक धक्का नहीं दिया है,

फिर निम्नलिखित बहुत आसान है (शाखा से शुरू होता है master गलत काम करता है):

git reset HEAD~3
git stash
git checkout newbranch
git stash pop

यह क्या करता है:

  1. पिछले तीन काम (और उनके संदेश) को पूर्ववत करता है master, लेकिन सभी काम करने वाली फाइलों को बरकरार रखता है
  2. बनाने के लिए, सभी काम कर रहे फ़ाइल परिवर्तनों को दूर करता है master सिर ~ 3 राज्य के बराबर काम कर रहे पेड़।
  3. एक मौजूदा शाखा में स्विच newbranch
  4. बदले गए फ़ाइलों को छीनने और अपनी कार्यशील निर्देशिका में खींचता है।

अब आप इसका उपयोग कर सकते हैं git add तथा git commit जैसा कि आप सामान्य रूप से करेंगे। सभी परिवर्तनों में किया जाएगा newbranch

यह क्या नहीं करता है:

  • यह आपके पेड़ को छेड़छाड़ करने वाली यादृच्छिक अस्थायी शाखाओं को नहीं छोड़ता है।
  • यह गलत काम करता है और संदेशों को प्रतिबद्ध नहीं करता है। आपको इस नई प्रतिबद्धता में एक नया प्रतिबद्ध संदेश जोड़ना होगा। हालांकि, ओपी ने कहा कि लक्ष्य परिवर्तन खोने के बिना "उन कामों से पहले मास्टर को वापस लेना" था और यह समाधान ऐसा करता है।

मैं सप्ताह में कम से कम एक बार ऐसा करता हूं जब मैं गलती से नई प्रतिबद्धता करता हूं master के बजाय develop। आमतौर पर मेरे पास रोलबैक के लिए केवल एक ही प्रतिबद्धता है git reset HEAD^ रोलबैक सिर्फ एक प्रतिबद्ध करने के लिए काम करता है।


8
2018-06-01 05:40





1) एक नई शाखा बनाएं, जो आपके सभी परिवर्तनों को new_branch में ले जाती है।

git checkout -b new_branch

2) फिर पुरानी शाखा में वापस जाओ।

git checkout master

3) गिट रिबेस करें

git rebase -i <short-hash-of-B-commit>

4) फिर खुले संपादक में पिछले 3 प्रतिबद्ध जानकारी शामिल हैं।

...
pick <C's hash> C
pick <D's hash> D
pick <E's hash> E
...

5) बदलें pick सेवा मेरे drop उन सभी 3 काम करता है। फिर संपादक को सहेजें और बंद करें।

...
drop <C's hash> C
drop <D's hash> D
drop <E's hash> E
...

6) अब मौजूदा शाखा से पिछले 3 काम हटा दिए गए हैं (master)। अब शाखा को मजबूती से दबाएं + शाखा नाम से पहले हस्ताक्षर करें।

git push origin +master

1
2018-05-25 14:14