Hg: git के रिबेस की तरह रिबास कैसे करें

Question

Git में मैं यह कर सकता हूं:

1. नई सुविधा पर काम करना शुरू करें:
$ git co -b newfeature-123 # (एक स्थानीय सुविधा विकास शाखा)
कुछ कमिट करें (M, N, O)

मास्टर ए --- बी --- सी
                \
newfeature-123 M --- N --- O

2. ऊपर मास्टर से नए परिवर्तन खींचो:
$ गिट पुल
(मास्टर ff-commits के साथ अद्यतन)

मास्टर ए --- बी --- सी --- डी --- ई --- एफ
                \
newfeature-123 M --- N --- O

3. मास्टर बंद करें ताकि मेरी नई सुविधा हो 
नवीनतम अपस्ट्रीम परिवर्तनों के खिलाफ विकसित किया जा सकता है:
(newfeature-123 से)
$ गिट रिबास मास्टर

मास्टर ए --- बी --- सी --- डी --- ई --- एफ
                            \
newfeature-123 M --- N --- O

मैं यह जानना चाहता हूं कि मर्क्यूरियल में एक ही काम कैसे किया जाए, और मैंने एक उत्तर के लिए वेब को स्कैन किया है, लेकिन सबसे अच्छा मुझे मिल सकता था: git rebase - hg do that

यह लिंक 2 उदाहरण प्रदान करता है:
1. मैं मानता हूँ कि यह: (मेरे स्वयं के उदाहरण से उन उदाहरणों से संशोधन की जगह)

एचजी अप -सीएफ  
hg शाखा -f newfeature-123  
hg ट्रांसप्लांट -a -b newfeature-123 

यह बहुत बुरा नहीं है, सिवाय इसके कि यह पूर्व-विद्रोही MNO को एक बिना सिर के पीछे छोड़ देता है और 3 नए कमिट M ', N', O 'बनाता है जो उन्हें अपडेटेड मेनलाइन से ब्रांचिंग का प्रतिनिधित्व करते हैं।

मूल रूप से समस्या यह है कि मैं इसे समाप्त करता हूं:

मास्टर ए --- बी --- सी --- डी --- ई --- एफ
                \ _
newfeature-123 \ M '--- N' --- O '
                  \
newfeature-123 M --- N --- O

यह अच्छा नहीं है क्योंकि यह स्थानीय, अवांछित कमिट्स को पीछे छोड़ देता है जिन्हें छोड़ दिया जाना चाहिए।

2. उसी लिंक से अन्य विकल्प है

hg qimport -r M: O
hg qpop -a
F को hg करें
hg शाखा newfeature-123
hg qpush -a
hg qdel -r qbase: qtip

और यह वांछित ग्राफ में परिणाम करता है:

मास्टर ए --- बी --- सी --- डी --- ई --- एफ
                            \
newfeature-123 M --- N --- O

लेकिन इन आदेशों (उनमें से सभी 6!) की तुलना में बहुत अधिक जटिल लगते हैं

$ गिट रिबास मास्टर

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

Comments

"यह अच्छा नहीं है क्योंकि यह स्थानीय, अवांछित कमिट्स को पीछे छोड़ देता है जिन्हें छोड़ दिया जाना चाहिए।" - वास्तव में, गिट एक ही काम करता है। यह मूल शाखा में कमिट्स को बदलता या हटाता नहीं है, यह सिर्फ नए बनाता है जो मास्टर के शीर्ष पर परिवर्तनों के समान सेट को लागू करता है। आप अभी भी पुराने का उपयोग कर सकते हैं git reflogऔर वे पूरी तरह से चले गए हैं जब तक कि वे कचरा एकत्र न करें। यदि आप उन्हें एक नामित शाखा में इधर-उधर रखना चाहते हैं, ताकि आपको रिफ्लैग का उपयोग न करना पड़े, तो केवल रिबास करने git branch feature-123_originalसे पहले करें।

— MatrixFrog

रैंडम सवाल: क्या आपने अपने आप में बदलावों / शाखाओं को आस्की-ड्रा किया है या ऐसा कोई टूल है जो ऐसा करता है?

— अमीर रुचम

बस उन्हें खुद TextWrangler के साथ "ओवरराइट" करने के लिए सेट किया।

— jpswain

Answer 1

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

1. Start working on a new feature:
$ hg clone mainline-repo newfeature-123
do a few commits (M, N, O)

master A---B---C
                \
newfeature-123   M---N---O

2. Pull new changes from upstream mainline:
$ hg pull

master A---B---C---D---E---F
                \
newfeature-123   M---N---O

3. merge master into my clone so that my new feature 
can be developed against the latest upstream changes:
(from newfeature-123)
$ hg merge F

master A---B---C---D---E---F
                \           \
newfeature-123   M---N---O---P

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

अब मैं अपना साबुनबॉक्स दूर रखने के दौरान वॉनसी का जवाब चुनूं। :)

Comments

नोट: बंद बेशक, Git नहीं करता है वास्तव में आप इतिहास के पुनर्लेखन के लिए केवल नए आसानी से (बनाने की अनुमति utcc.utoronto.ca/~cks/space/blog/tech/GitNewHistory )। RebaseExtension को जोड़कर, Mercurial एक पुराने इतिहास को एक नए द्वारा बदलने के लिए एक ही सटीक सुविधाजनक तरीका प्रदान करता है। क्यों? क्योंकि एक मर्ज हमेशा सही जवाब नहीं होता है, खासकर जब आपके बदलाव को एफ के शीर्ष पर विकसित होने के रूप में देखा जाना चाहिए , न कि रिवर्स (पी ओ के ऊपर विलय हो गया)

— वॉनच

VonC, मैं मानता हूं, एक मर्ज हमेशा सही विकल्प नहीं होता है, लेकिन मुझे लगता है कि अंतर यह है कि कोई व्यक्ति वीसीएस के इतिहास को बताना चाहता है या नहीं। मुझे लगता है कि इतिहास को हमेशा "इस तरह से क्या था कि मैंने इसे पहले से एकीकृत करने की कोशिश की, जो कि काम नहीं करता था और मुझे लगा कि उस समय बेकार था"। वैज्ञानिकों ने गिने हुए पन्नों के साथ लॉगबुक रखी है, और AFAIC सॉफ्टवेयर इंजीनियरों को हर उस बाइट को सहेजना चाहिए जो उन्होंने कभी टाइप की है। इतिहास को फिर से लिखना, यहाँ तक कि पितृत्व को भी खत्म कर देता है, लेकिन निश्चित रूप से पतन, हिस्टीडिट, इत्यादि का उल्लंघन करते हैं। यह पूरी तरह से व्यक्तिगत पसंद की बात है।

— Ry4an Brase

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

— कोस

इसके अलावा, मैं इंटरेक्टिव विद्रोहियों के टन करता हूं क्योंकि मैं सबसे पहले बहुत सारे छोटे-छोटे काम करता हूं, फिर उनमें शामिल होता हूं, लेबल लगाता हूं और उन्हें साफ करता हूं, फिर उन्हें मुख्य शाखा के साथ वापस (या रिबेस) के साथ मर्ज करता हूं। मुझे अलग-अलग चरणों के लिए परिवर्तनों को कोड करना और प्रबंधित करना पसंद है।

— कोस

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

— पीटर कॉर्ड्स

Answer 2

आप ढूंढ रहे होंगे रिबेस एक्सटेंशन की । ( समरऑफकोड 2008 के भाग के रूप में कार्यान्वित )

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

से हो रही है :

सेवा:

---

के रूप में नीचे टिप्पणी की द्वारा steprobe :

उस स्थिति में जहाँ आप परिवर्तनों को नहीं खींच रहे हैं, और आपकी रेपो में दो शाखाएँ हैं, आप कर सकते हैं ( उपयोग करkeepbranches ):

hg up newfeature-123 
hg rebase -d master --keepbranches

( --keepbranches: मूल शाखा का नाम इनहेरिट करें।)

Mojca उल्लेख:

मुझे उपयोग करना पसंद है hg rebase --source {L1's-sha} --dest {R2's-sha}, लेकिन मुझे नहीं पता था कि मैं --keepbranchesअंत में जोड़ सकता हूं ।

जैसा कि नीचे जोनाथन ब्लैकबर्न ने चित्रित किया है :

 hg rebase -d default --keepbranches

Comments

मैंने रीबेस एक्सटेंशन को देखा है, लेकिन यह अभी भी मेरे लिए स्पष्ट नहीं है। क्या आप कृपया मेरे द्वारा बताए गए चरणों का वर्णन कर सकते हैं?

— jpswain

उस स्थिति में जहां आप परिवर्तनों को नहीं खींच रहे हैं, और आपकी रेपो में दो शाखाएं हैं, आप ऐसा कर सकते हैं: hg up newfeature-123इसके बादhg rebase -d master --keepbranches

— स्टेपलर

मेरा मानना ​​है कि रिबेस के साथ कुछ भी गलत नहीं है, यह सिर्फ पसंद की बात है। समस्या यह है कि रिबास का दुरुपयोग होता है और मैं @ Ry4an के साथ हूं इस पर इतिहास को फिर से मत लिखो ताकि आप जान सकें कि क्या और कब होता है।

— जॉर्ज वर्गास

@steprobe: --keepbranches का उपयोग करने के लिए संकेत के लिए धन्यवाद। मुझे उपयोग करना पसंद है hg rebase --source {L1's-sha} --dest {R2's-sha}, लेकिन मुझे नहीं पता था कि मैं --keepbranchesअंत में जोड़ सकता हूं । अन्य निम्न रैंकिंग उत्तरों में इसका उल्लेख किया गया है, लेकिन इस उत्तर को स्पष्ट रूप से लिखना भी अच्छा होगा।

— Mojca

@Mojca कोई समस्या नहीं। मैंने उसी के अनुसार उत्तर संपादित किया है।

— वॉन

Answer 3

मान लें कि आपके पास एक आधुनिक Hg इंस्टॉलेशन है, तो आप बस जोड़ सकते हैं:

[extensions]
rebase = 

से ~ / .hgrc

तो फिर तुम आदेशों का उपयोग कर सकते हैं hg rebase, hg pull --rebaseया hg help rebase।

Comments

बस कमांड के इस में जोड़ने के लिए तो आप को निष्पादित करने की आवश्यकता होगी: hg rebase -s o -d f

— सरल-समाधान

Answer 4

मुझे नहीं लगता कि ऊपर दिए गए उत्तर ओपी के लक्ष्य को प्राप्त करते हैं, जो उसकी कार्य शाखा को बनाए रखने के लिए था, बस मूल शाखा पर एक बाद के बिंदु के खिलाफ विद्रोह किया।

मान लें कि मैं इस ग्राफ के साथ शुरू करता हूं (ग्रेफ्लॉग एक्सटेंशन का उपयोग करके उत्पन्न होता है। ग्राफोल के लिए गंभीर गीक लव)।

@  9a4c0eb66429 Feature 3 commit 2 tip feature3
|
| o  af630ccb4a80 default againagainagain  
| |
o |  98bdde5d2185 Feature 3 branch commit 1  feature3
|/
o  e9f850ac41da foo   

यदि मैं फीचर 3 शाखा पर हूं और इसे फिर से बनाने के लिए फिर से शुरू करना चाहता हूं, तो मैं समझता हूं कि मैं चलाऊंगा hg rebase -d default। इसका निम्न परिणाम है:

@  89dada24591e Feature 3 commit 2 tip 
|
o  77dcce88786d Feature 3 branch commit 1  
|
o  af630ccb4a80 default againagainagain  
|
o  e9f850ac41da foo  

मिशन पूरा हुआ? मुझे ऐसा नहीं लगता। समस्या यह है कि जब फीचर 3 शाखा पर आने वाले पुनर्जागरण पर छूट दी गई थी , तो फीचर 3 शाखा को हटा दिया गया था । मेरे आवागमन को डिफ़ॉल्ट शाखा में स्थानांतरित कर दिया गया है, जो कि मैं पहली जगह में बचने की कोशिश कर रहा था।

Git में, परिणाम इस तरह दिखेगा:

@  9a4c0eb66429 Feature 3 commit 2 tip
|
o  98bdde5d2185 Feature 3 branch commit 1 **feature3**
|
o  af630ccb4a80 default againagainagain
|
o  e9f850ac41da foo

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

अद्यतन : मैंने --keepbrancheshg रिबास द्वारा समर्थित ध्वज की खोज की , और मुझे सब कुछ ओके-डोके की रिपोर्ट करने में खुशी हो रही है। का उपयोग करते हुए hg rebase -d default --keepbranches, मैं वास्तव में मेरे द्वारा किए गए Git व्यवहार को दोहराता हूं। कुछ उपनाम बाद में और मैं किसी के व्यवसाय की तरह पुन: काम कर रहा हूं।

Comments

बस रिबेट पर --keepbranches ध्वज की खोज की। समस्या सुलझ गयी। क्या यह मेरा कोड था जिसे मैं डिफ़ॉल्ट बनाऊंगा, लेकिन यह सिर्फ मैं ही हूं।

— जोनाथन ब्लैकबर्न

मुझे लगता है कि यह उपयोगी होगा यदि आपने उपरोक्त जानकारी को अपनी प्रतिक्रिया में जोड़ा - मुझे इसे खोजने में थोड़ा समय लगा।

— हंसारी

Answer 5

चूँकि कुछ लोगों ने यह कहते हुए धोखा दिया है कि उन्हें हर चीज़ का हर चलना अच्छा लगता है, मैं बताता हूँ कि बड़े ओपन-सोर्स प्रोजेक्ट्स के लिए, मर्ज और डेवलपमेंट इटरेशन से भरे बदलावों को स्वीकार करना एक गन्दी मेनलाइन रिवीजन हिस्ट्री के लिए, और बनाना होगा वर्तमान संस्करण कैसे मिला, यह देखने के लिए संशोधन इतिहास कम उपयोगी है।

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

X265 योगदानकर्ताओं पृष्ठ बताता है कि कैसे परिवर्तन का एक सेट आप पर काम कर रहे पुन: प्रतिबद्ध करने के लिए, उन्हें प्रस्तुत करने के लिए तैयार होने के लिए x265 परियोजना के लिए। (कुछ करने के लिए TortoiseHG का उपयोग करना शामिल है, लेकिन व्यक्तिगत फ़ाइल में सभी परिवर्तन नहीं होते हैं, जैसे git gui का चरण / unstage प्रतिबद्ध के लिए अलग हंक)।

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

मुझे लगता है कि आप कॉपी / पेस्ट करेंगे और फिर एक पैचसेट के पिछले पुनरावृत्तियों के संदेशों को संपादित करेंगे जिन्हें आप संशोधित कर रहे हैं। या हो सकता है कि आप अपने पुराने कमिट्स (git-भाषा में चेरी-पिक) को ग्राफ्ट कर सकते हैं, और फिर उन्हें संपादित करने के लिए एक प्रारंभिक बिंदु के रूप में अपने पुराने प्रतिबद्ध संदेशों को प्राप्त करने के लिए एक-एक करके संशोधन कर सकते हैं।