بوابة - هل هو سحب أو rebase عند العمل على الفروع مع أشخاص آخرين

لذلك ، إذا كنت أستخدم الفروع التي هي فروع (مجنزرة) عن بعد ، وأريد الحصول على أحدث ، ما زلت غير واضح ما إذا كان ينبغي علي القيام git pull أو git rebase </> كود>. اعتقدت أنني قرأت أن تفعل git rebase عند العمل على فرع مع مستخدمين آخرين ، يمكن أن يفسد لهم عندما سحب أو rebase. هل هذا صحيح؟ هل يجب علينا جميعا استخدام git pull ؟

0
وأضاف تحرير
الآراء: 1

5 إجابة

إذا كنت ترغب في سحب المصدر دون التأثير على الفروع عن بعد ودون أي تغييرات في نسختك المحلية ، فمن الأفضل استخدام سحب بوابة.

أعتقد أنه إذا كان لديك فرع عمل قمت بإجراء تغييرات عليه ، فاستخدم git rebase لتغيير قاعدة هذا الفرع ليكون أحدث إصدار عن بعد ، وسوف تحتفظ بكل التغييرات في الفرع الخاص بك ، ومع ذلك سيتفرع الآن من الرئيسي الموقع ، بدلا من حيث كان متفرع من قبل.

0
وأضاف

Git rebase هو إعادة كتابة التاريخ. يجب ألا تفعل ذلك أبدًا في الفروع "العامة" (مثل الفروع التي تشاركها مع الآخرين). إذا قام شخص ما باستنساخ الفرع الخاص بك ثم قمت بتمرير هذا الفرع - فلن يتمكن بعد ذلك من سحب/دمج التغييرات من الفرع الخاص بك - سيتعين عليهم التخلص من فرعهم القديم وإعادة سحبه.

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

باختصار ، كلاهما لهما مكانه ولكنك تحتاجين إلى أن تجرحن الفرق.

0
وأضاف
باختصار ، لا تقم بتمزيق أي تعهدات تعيش في مستودعات أخرى.
وأضاف المؤلف Ikke, مصدر
المشكلة هي إذا قام شخص آخر بسحبه من فرع ثم قمت بتمزيقه. لا بأس إذا قمت بسحب من A إلى المحلية ثم rebase local ، وسحب شخص آخر من A . لا بأس إذا قمت بالانسحاب من A ، أي شخص آخر يسحب من محلي ، ثم أقوم بتثبيت محلي .
وأضاف المؤلف Cameron Skinner, مصدر
هل هذا صحيح ، @ بات؟ في حالة السحب - أو تركه ، ألا تقوم فقط بإعادة ترتيب الالتزامات المحلية الخاصة بك لتكون فوق ما قمت بسحبه؟ بما أن هذه الالتزامات كانت محلية ولم يتم نشرها بعد ، فكيف سيكسرون شخصًا يحاول سحبه بعد pull --rebase 'ed؟
وأضاف المؤلف Gabe Hollombe, مصدر

git pull does a merge if you've got commits that aren't in the remote branch. git rebase rewrites any existing commits you have to be relative to the tip of the remote branch. They're similar in that they can both cause conflicts, but I think using git rebase if you can allows for smoother collaboration. During the rebase operation you can refine your commits so they look like they were newly applied to the latest revision of the remote branch. A merge is perhaps more appropriate for longer development cycles on a branch that have more history.

مثل معظم الأشياء الأخرى في بوابة ، هناك الكثير من الوظائف المتداخلة لاستيعاب أنماط مختلفة من العمل.

0
وأضاف

سحب جيت هو مزيج من 2 الأوامر

  • git fetch (يقوم بمزامنة الريبو المحلي مع أحدث الأشياء الموجودة على جهاز التحكم عن بعد)
  • git merge (يدمج التغييرات من الفرع البعيد ، إن وجدت ، في فرع التتبع المحلي)

git rebase هو مجرد ما يعادل الخام لدمج git. لا تجلب أي شيء عن بُعد. في الواقع ، لا تقوم بعملية دمج مناسبة ، فهي تعيد إلتزامات الفرع الذي تتواجد فيه بعد الإلتزامات الجديدة من الفرع الثاني.

الغرض منه هو أساسا لتتيح لك تاريخ أنظف. لا يأخذ الكثير من الناس من قبل الكثير من الناس قبل التاريخ الماضي في gitk يحصل على غرار السباغيتي بشكل رهيب.

يمكن رؤية أفضل تفسير رسومي في أول رسومات 2 هنا . لكن دعني أشرح لك مثالاً.

لدي فرعين: سيد و mybranch. عندما يقف على mybranch يمكنني تشغيل

git rebase master

وسأحصل على أي شيء جديد في الرئيسية أدرج قبل ألتقيتي الأخيرة في mybranch. هذا مثالي ، لأنني إذا قمت الآن بدمج أو تخليص الأشياء من mybranch in master ، فإن عملياتي الجديدة تتم إضافتها خطياً مباشرة بعد آخر التزام.

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

git rebase mybranch

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

حسنا ، إنه من الصعب بعض الشيء أن أشرح بالكلمات ... أمل هذا يجعل قليلاً من المعنى :-)

على أي حال ، سير العمل الخاص بي هو:

  • "سحب git" تغييرات جديدة من بعيد
  • بدّل إلى mybranch
  • "git rebase master" لإحضار تغييرات رئيسية جديدة في سجل التزاماتي
  • بدِّل إلى الصفحة الرئيسية
  • "git merge mybranch" ، والتي لا تعدو أن تكون سريعًا إلى الأمام عندما يكون كل شيء في الصفحة الرئيسية أيضًا في mybranch (وبالتالي تجنب مشكلة إعادة ترتيب الالتزام على فرع عام)
  • "git push"

كلمة أخيرة أوصي بشدة باستخدام rebase عندما تكون الاختلافات بسيطة (على سبيل المثال ، الأشخاص الذين يعملون على ملفات مختلفة أو على الأقل في خطوط مختلفة). كان لديه مسكتك حاولت أن أشرح فقط هناك ، لكنه يجعل لتاريخ أنظف بكثير.

وبمجرد حدوث تعارض كبير (على سبيل المثال ، أعاد زميل العمل تسمية شيء ما في مجموعة من الملفات) ، أوصيك بشدة بالدمج. في هذه الحالة ، سيُطلب منك حل التعارض ثم الالتزام بالحل. على الجانب الإيجابي ، يكون الحل أسهل بكثير عند وجود تعارضات. الجانب السلبي هو أن التاريخ الخاص بك قد يصعب متابعته إذا كان الكثير من الناس يدمجون طوال الوقت :-)

حظا طيبا وفقك الله!

0
وأضاف
يبدو لي أنه كان يجب عليك أن تقول: "git دمج" mybranch "، التي لا تعدو أن تكون سريعًا إلى الأمام عندما يكون كل شيء في الصفحة الرئيسية أيضًا في mybranch (وبالتالي تجنب مشكلة إعادة الترتيب على فرع عام)
وأضاف المؤلف Bruno Bronosky, مصدر
"git rebase mybranch" يجب أن تقرأ "git merge mybranch".
وأضاف المؤلف James H, مصدر

اطلع على Gitcasts الممتاز على الفروع ودمج كـ وكذلك rebasing .

0
وأضاف