git - الزئبق:كيفية القيام بتمهيد مثل rebase غيت




mercurial dvcs (5)

لا أعتقد أن الإجابات أعلاه تحقق هدف OP ، وهو الحفاظ على فرع مهمته ، فقط تم إعادة صياغته مقابل نقطة لاحقة على الفرع الأم.

لنفترض أنني بدأت بهذا الرسم البياني (تم إنشاؤه باستخدام ملحق graphlog. حب المهوس الجاد من أجل graphlog).

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

إذا كنت على فرع Feature3 وأرغب في تجميدها مرة أخرى من الالتزام السابق ، ففهمت أنني سأعمل على hg rebase -d default . هذا له النتيجة التالية:

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

تمت المهمة؟ لا أعتقد ذلك. المشكلة أنه عندما تم rebased على الالتزام على فرع Feature3 على againagainagain ، تم حذف فرع feature3 . تم نقل ادعاءاتي إلى الفرع الافتراضي ، وهو ما كنت أحاول تجنبه في المقام الأول.

في Git ، ستبدو النتيجة كما يلي:

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

لاحظ أن فرع الميزة الثالثة لا يزال موجودًا ، حيث لا يزال هناك التزامان على فرع feature3 ، ولا يكون مرئيًا في الوضع الافتراضي. بدون الحفاظ على فرع المهام ، لا أرى كيف يختلف وظيفياً عن الدمج.

حدث : اكتشفت علامة - --keepbranches المدعومة --keepbranches rebase ، ويسعدني الإبلاغ عن كل شيء على ما يرام dokey. باستخدام hg rebase -d default --keepbranches ، أنا بالضبط تكرار سلوك Git كنت متشوقا. زوجان من الأسماء المستعارة في وقت لاحق وأنا أكرر مثل أعمال أحد.

في Git يمكنني القيام بذلك:

1. Start working on new feature:
$ git co -b newfeature-123  # (a local feature development branch)
do a few commits (M, N, O)

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

2. Pull new changes from upstream master:
$ git pull
(master updated with ff-commits)

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

3. Rebase off master so that my new feature 
can be developed against the latest upstream changes:
(from newfeature-123)
$ git rebase master

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


أريد أن أعرف كيف أفعل الشيء نفسه في Mercurial ، وقد قمت بمسح شبكة الإنترنت للحصول على إجابة ، ولكن أفضل ما يمكن أن أجده هو: git rebase - can hg do that

يقدم هذا الرابط مثالين:
1. أنا أعترف أن هذا: (استبدال المراجعات من المثال مع تلك من المثال الخاص بي)

hg up -C F  
hg branch -f newfeature-123  
hg transplant -a -b newfeature-123 

ليس سيئًا للغاية ، إلا أنه يترك خلفًا لـ MNO ما قبل الرزمة كرأس غير مدمج ويخلق 3 إلتزامات جديدة M '، N'، O 'التي تمثلهم متفرعًا عن الخط الرئيسي المحدث.

في الأساس المشكلة هي أنني في نهاية المطاف مع هذا:

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

هذا ليس جيدًا لأنه يترك التهم المحلية غير المرغوب فيها التي يجب إسقاطها.

  1. الخيار الآخر من نفس الرابط هو
hg qimport -r M:O
hg qpop -a
hg up F
hg branch newfeature-123
hg qpush -a
hg qdel -r qbase:qtip

وهذا يؤدي إلى الرسم البياني المطلوب:

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

لكن هذه الأوامر (كل 6 منهم!) تبدو أكثر تعقيدًا من ذلك بكثير

$ git rebase master

أريد أن أعرف ما إذا كان هذا هو المعادل الوحيد في الزئبق أو إذا كان هناك طريقة أخرى متاحة بسيطة مثل Git.


لدى VonC الإجابة التي تبحث عنها ، Rebase Extension. ومع ذلك ، فإنه يستحق إنفاق ثانية أو اثنتين للتفكير في لماذا لا يتم تمكين mq أو rebase بشكل افتراضي في الزئبق: لأن الزئبق هو كل شيء عن التغيرات غير القابلة للمحو. عندما أعمل بالطريقة التي تصفها ، والتي تقريبًا يوميًا ، إليك النمط الذي أتخذه:

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 يمكنني العودة بسهولة إلى الخط الرئيسي عندما أكون سعيدا به. الأهم من ذلك ، ومع ذلك ، لم أغير التاريخ . يمكن لأي شخص أن ينظر إلى csets الخاص بي ويرى ما تم تشفيره في الأصل وكيف تفاعلت مع التغييرات في الخط الرئيسي طوال عملي. ليس كل شخص يعتقد أن له قيمة ، ولكنني مؤمن تمامًا بأن مهمة التحكم بالمصادر هي أن تبين لنا ما كنا نتمنىه ، ولكن ما حدث بالفعل - يجب أن يترك كل مفسد وكل راسخ أثرًا لا يمحى ، وغيرها من تقنيات تحرير التاريخ إخفاء ذلك.

الآن اذهب اختيار إجابة فونك بينما أضع المنبر الخاص بي بعيدا. :)


قد تكون تبحث عن Rebase Extension . (تم تنفيذها كجزء من SummerOfCode 2008 )

في هذه الحالات ، قد يكون من المفيد "فصل" التغييرات المحلية ، ومزامنة المستودع مع التيار الرئيسي ، ثم إلحاق التغييرات الخاصة أعلى التغييرات الجديدة عن بُعد. هذه العملية تسمى rebase.

الحصول من :

إلى:


إذا افترضنا أنك تمتلك تثبيتًا حديثًا للزئبق ، فيمكنك ببساطة إضافة:

[extensions]
rebase = 

إلى ~ / .hgrc.

بعد ذلك ، يمكنك استخدام أوامر hg rebase أو hg pull --rebase أو hg help rebase .


في الواقع ، يقوم نظام rebase بحفظ نقطة البداية الخاصة بك إلى ORIG_HEAD لذلك عادة ما تكون بسيطة مثل:

git reset --hard ORIG_HEAD

ومع ذلك ، فإن reset و rebase merge جميعها حفظ مؤشر HEAD الأصلي في ORIG_HEAD ، لذلك ، إذا قمت بأي من هذه الأوامر لأن rebase كنت تحاول التراجع ، فيجب عليك استخدام reflog.





git mercurial dvcs rebase