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




mercurial dvcs (4)

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

[extensions]
rebase = 

إلى ~ / .hgrc.

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

في 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.


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

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

الحصول من :

إلى:


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

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


نظرًا لأن بعض الأشخاص قد صرّحوا بقولهم أنهم يعتقدون أنه من الجيد الحفاظ على كل تكرار لكل شيء ، فسأشير إلى أنه بالنسبة للمشروعات ذات المصادر المفتوحة الأكبر ، فإن قبول التغييرات المليئة بالدمج وسيؤدي تطوير التكرار إلى إنشاء سجل مراجعة فوضوي رئيسي ، وجعل تاريخ المراجعة أقل فائدة لمعرفة كيف حصلت على الإصدار الحالي هناك.

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

تشرح صفحة المساهمين x265 كيفية إعادة تنفيذ مجموعة من التغييرات التي تعمل عليها ، لجعلها جاهزة للتقديم إلى مشروع x265. (بما في ذلك استخدام TortoiseHG لارتكاب بعض وليس كل التغييرات في ملف فردي ، مثل مرحلة git gui / unstage diff hunk للالتزام).

وتتمثل العملية في الحصول على تحديث hg إلى الطرف العلوي ، ثم الحصول على جميع التغييرات غير ملتزم بها في دليل العمل. أرفِق كل ما لا يمثل جزءًا مما تريد تقديمه ، ثم قسّم الباقي إلى عدد مناسب من الإلتزامات المنفصلة ، مع رسائل التزام لطيفة.

أظن أنك ستقوم بنسخ / لصق ثم تحرير رسائل التزام من التكرارات السابقة لمجموعة التصحيح التي تقوم بمراجعتها. أو ربما يمكنك التطعيم بالالتزامات القديمة (اختيار كرز بلغة git) ، ثم تعديلها واحدة تلو الأخرى ، للحصول على رسائل الالتزام القديمة كنقطة بداية لعملية التحرير.





rebase