هل تستخدم التحكم في الإصدار الموزع؟

https://stackoverflow.com/questions/26845

09-06-2019
|

سؤال

أود أن أسمع من الأشخاص الذين يستخدمون التحكم في الإصدار الموزع (المعروف أيضًا باسم التحكم في المراجعة الموزعة، والتحكم في الإصدار اللامركزي) وكيف يجدون ذلك.ما الذي تستخدمه، Mercurial، Darcs، Git، Bazaar؟هل ما زلت تستخدمه؟إذا كنت قد استخدمت RCS للعميل/الخادم في الماضي، فهل تجده أفضل أم أسوأ أم مختلفًا تمامًا؟ما الذي يمكن أن تخبرني به والذي سيجعلني أقفز على العربة؟أو القفز في هذا الشأن، سأكون مهتمًا بالاستماع إلى الأشخاص الذين لديهم تجارب سلبية أيضًا.

أنا أتطلع حاليًا إلى استبدال نظام التحكم بالمصدر الحالي لدينا (Subversion) وهو الدافع لهذا السؤال.

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

إذا لم تكن متأكدًا من التحكم في الإصدار الموزع، فإليك بعض المقالات:

مقدمة للتحكم في الإصدار الموزع

دخول ويكيبيديا

المحلول

لقد كنت أستخدم Mercurial في العمل وفي مشاريعي الشخصية، وأنا سعيد جدًا به.المزايا التي أراها هي:

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

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

نصائح أخرى

في المكان الذي أعمل فيه، قررنا الانتقال من SVN إلى Bazaar (بعد تقييم git وmercurial).كان من السهل البدء في تطبيق Bazaar، باستخدام أوامر بسيطة (ليست مثل الأوامر الـ 140 الموجودة في git)

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

أحد الأوامر التي أحبها في bzr هو ملحق الرف.إذا بدأت العمل على قطعتين مختلفتين منطقيًا من التعليمات البرمجية في ملف واحد وأردت الالتزام بجزء واحد فقط، فيمكنك استخدام ملحق shelve لوضع التغييرات الأخرى على الرف لاحقًا.في Git، يمكنك فعل الشيء نفسه من خلال اللعب في الفهرس (منطقة التدريج) ولكن bzr لديه واجهة مستخدم أفضل له.

كان معظم الأشخاص مترددين في الانتقال حيث يتعين عليهم كتابة أمرين للالتزام والدفع (bzr ci + bzr Push).كما كان من الصعب عليهم فهم مفهوم الفروع والدمج (لا أحد يستخدم الفروع أو يدمجها في svn).

بمجرد أن تفهم ذلك، فإنه سيزيد من إنتاجية المطور.وإلى أن يفهم الجميع ذلك، سيكون هناك سلوك غير متناسق بين الجميع.

في مكان عملي، قمنا بالتبديل إلى Git من CVS منذ حوالي شهرين (معظم تجربتي كانت مع Subversion).على الرغم من وجود منحنى تعليمي يتعلق بالتعرف على النظام الموزع، فقد وجدت أن Git متفوق في مجالين رئيسيين:مرونة بيئة العمل والاندماج.

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

ونظرًا لأن عمليات الدمج يتم إجراؤها من جانب العميل، فهي أسرع بكثير وأقل عرضة للخطأ من بدء عملية الدمج من جانب الخادم.

تستخدم شركتي حاليًا Subversion وCVS وMercurial وgit.

عندما بدأنا قبل خمس سنوات، اخترنا CVS، وما زلنا نستخدم ذلك في قسمي لفرعنا الرئيسي للتطوير وصيانة الإصدار.ومع ذلك، يستخدم العديد من المطورين لدينا Mercurial بشكل فردي كوسيلة للحصول على نقاط تفتيش خاصة دون معاناة فروع CVS (وخاصة دمجها)، وقد بدأنا في استخدام Mercurial لبعض الفروع التي تضم ما يصل إلى 5 أشخاص تقريبًا.هناك فرصة جيدة لأن نتخلص أخيرًا من نظام CVS في عام آخر.لقد نما استخدامنا لـ Mercurial بشكل عضوي؛لا يزال بعض الأشخاص يلمسونها أبدًا، لأنهم سعداء بـ CVS.كل من جرب Mercurial انتهى به الأمر إلى أن يكون سعيدًا به، دون الكثير من منحنى التعلم.

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

أكبر عقبة هي أنك تحتاج إلى إعادة توصيل أدمغة المطورين والمديرين لديك حتى يبتعدوا عن نموذج الفرع الخطي الفردي.أفضل دواء لهذا هو جرعة من لينوس تورفالدس تخبرك بأنك غبي وقبيح إذا كنت تستخدم SCM مركزية.قد تساعد أدوات تصور التاريخ الجيدة ولكنني لست راضيًا بعد عما هو متاح.

يعمل كل من Mercurial وCVS بشكل جيد بالنسبة لنا مع المطورين الذين يستخدمون مزيجًا من أنظمة التشغيل Windows وLinux وSolaris، ولم ألاحظ أي مشاكل مع المناطق الزمنية.(حقًا، هذا ليس بالأمر الصعب جدًا؛ما عليك سوى استخدام الثواني الزمنية داخليًا، وأتوقع أن تحصل جميع أنظمة SCM الرئيسية على هذا الأمر بشكل صحيح).

كان من الممكن، مع قدر لا بأس به من الجهد، استيراد تاريخ CVS الرئيسي الخاص بنا إلى Mercurial.كان من الممكن أن يكون الأمر أسهل لو لم يتعمد الأشخاص إدخال حالات ركنية في سجل CVS الرئيسي الخاص بنا كوسيلة لاختبار أدوات ترحيل التاريخ.وتضمن ذلك دمج بعض فروع Mercurial في سجل CVS، بحيث يبدو المشروع وكأنه كان يستخدمه منذ اليوم الأول.

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

نحن نستخدم git للعمل مع Linux kernel.سيكون Git أكثر ملاءمة لنا بمجرد نضوج إصدار Windows الأصلي، لكنني أعتقد أن تصميم Mercurial بسيط جدًا وأنيق لدرجة أننا سنلتزم به.

لا أستخدم التحكم بالمصادر الموزعة بنفسي، ولكن ربما تمنحك هذه الأسئلة والإجابات ذات الصلة بعض الأفكار:

أنا شخصيا أستخدم نظام التحكم بالمصدر Mercurial.لقد تم استخدامه لأكثر من عام بقليل في الوقت الحالي.لقد كانت في الواقع تجربتي الأولى مع VSC.

لقد جربت Git، لكنني لم أدفعه أبدًا لأنني وجدت أنه أكثر من اللازم بالنسبة لما أحتاجه.من السهل حقًا اختيار Mercurial إذا كنت من مستخدمي Subversion نظرًا لأنه يشارك معه الكثير من الأوامر.بالإضافة إلى أنني أجد أن إدارة مستودعاتي سهلة حقًا.

لدي طريقتان لمشاركة الكود الخاص بي مع الأشخاص:

أشارك خادمًا مع زميل في العمل ونحتفظ بمستودع رئيسي لمشروعنا.
بالنسبة لبعض مشروعات OSS التي أعمل عليها، نقوم بإنشاء تصحيحات لعملنا باستخدام Mercurial (hgexport) ويقوم مشرف المشروع فقط بتطبيقها على المستودع (hg import)

من السهل حقًا العمل معه، ولكنه قوي جدًا.لكن بشكل عام، يعتمد اختيار VSC حقًا على احتياجات مشروعنا...

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

بعد التبديل إلى Windows لمنصة التطوير الخاصة بنا، انتهى بنا الأمر بالتبديل إلى أكيوريف.في حين أن AccuRev، نظرًا لأنه يعتمد على خادم مركزي، لا يعد حلاً موزعًا حقًا، فمن المنطقي أن يكون نموذج سير العمل قريبًا جدًا.حيث كان برنامج TeamWare يمتلك نسخًا منفصلة تمامًا من كل شيء لدى كل عميل، بما في ذلك جميع مراجعات جميع الملفات، بموجب AccuRev، يتم الاحتفاظ بهذا في قاعدة البيانات المركزية ولا تحتوي أجهزة العميل المحلية إلا على الإصدار الحالي من الملف الثابت للأشياء للتحرير محليًا.ومع ذلك، يمكن إصدار هذه النسخ المحلية من خلال اتصال العميل بالخادم وتتبعها بشكل منفصل تمامًا عن أي تغييرات أخرى (على سبيل المثال:الفروع) تم إنشاؤها ضمنيًا بواسطة مطورين آخرين

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

لقد استخدمت داركس في مشروع كبير (GHC) وفي الكثير من المشاريع الصغيرة.لدي علاقة حب/كراهية مع داركس.

الإيجابيات:من السهل جدًا إعداد المستودع.من السهل جدًا نقل التغييرات بين المستودعات.من السهل جدًا استنساخها وتجربة "الفروع" في مستودعات منفصلة.من السهل جدًا القيام "بالالتزامات" في مجموعات صغيرة متماسكة وهذا أمر منطقي.من السهل جدًا إعادة تسمية الملفات والمعرفات.

السلبيات:لا يوجد أي فكرة عن التاريخ --- لا يمكنك استعادة "حالة الأشياء في 5 أغسطس".لم أكتشف أبدًا كيفية استخدام darcs للعودة إلى إصدار سابق.

ملغي الصفقة:darcks لا مقياس.لقد واجهت أنا (والكثيرين غيري) مشكلة كبيرة مع GHC باستخدام darcs.لقد تعلق مع استخدام وحدة المعالجة المركزية بنسبة 100 ٪ لمدة 9 أيام في محاولة لسحب 3 أشهر من التغييرات.لقد مررت بتجربة سيئة في الصيف الماضي حيث فقدت أسبوعين في محاولة لجعل وظيفة Darcs ولجأت في النهاية إلى إعادة تشغيل جميع التغييرات التي يدوي في مستودع بدائي.

خاتمة:يعد Darcs رائعًا إذا كنت تريد طريقة بسيطة وخفيفة الوزن لمنع نفسك من إطلاق النار على نفسك في مشاريع هوايتك.ولكن حتى مع بعض مشكلات الأداء التي تم تناولها في Darcs 2، فإن الأمر لا يتعلق بالقوة الصناعية.لن أؤمن حقًا بـ Darcs حتى تصبح "نظرية الرقع" المتبجحة أكثر قليلاً من مجرد بضع معادلات وبعض الصور الجميلة؛أريد أن أرى نظرية حقيقية منشورة في مكان محكم.لقد فات الوقت.

أنا حقا أحب Git، وخاصة مع GitHub.من الجميل جدًا أن تكون قادرًا على الالتزام والتراجع محليًا.وعلى الرغم من أن عمليات الدمج الانتقائية ليست تافهة، إلا أنها ليست صعبة للغاية، وهي أكثر تقدمًا بكثير من أي شيء يمكن أن يفعله Svn أو CVS.

تستخدم مجموعتي في العمل Git، وقد أحدث ذلك فرقًا كبيرًا في العالم.كنا نستخدم SCCS وكومة كبيرة من نصوص csh لإدارة المشاريع الكبيرة والمعقدة التي تتقاسم التعليمات البرمجية فيما بينها (تمت محاولة ذلك على أي حال).

مع Git، يجعل دعم الوحدة الفرعية الكثير من هذه الأشياء أمرًا سهلاً، ولا يلزم سوى الحد الأدنى من البرمجة النصية.لقد تراجعت جهودنا الهندسية في مجال الإصدار كثيرًا نظرًا لسهولة صيانة الفروع وتتبعها.إن القدرة على التفرع والدمج بتكلفة زهيدة تجعل من السهل إلى حد معقول الحفاظ على مجموعة واحدة من المصادر عبر عدة مشاريع (عقود)، بينما في السابق، كان أي تعطيل للتدفق النموذجي للأشياء مكلفًا للغاية.لقد وجدنا أيضًا أن قابلية البرمجة النصية لـ Git هي ملف ضخم بالإضافة إلى ذلك، لأنه يمكننا تخصيص سلوكه من خلال الخطافات أو من خلال البرامج النصية التي تقوم بذلك . git-sh-setup, ، ولا يبدو الأمر وكأنه كومة من الأخطاء كما كان من قبل.

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

بعض هذا هو مجرد خروجنا من أوائل الثمانينيات واعتماد بعض آليات التحكم الحديثة في الإصدار، لكن Git "فعل الأمر بشكل صحيح" في معظم المجالات.

لست متأكدًا من مدى الإجابة التي تبحث عنها، ولكن تجربتنا مع Git كانت إيجابية للغاية.

استخدام Subversion مع SourceForge والخوادم الأخرى عبر عدد من الاتصالات المختلفة مع فرق متوسطة الحجم وهو يعمل بشكل جيد للغاية.

أنا من أشد المؤيدين للتحكم المركزي بالمصادر لعدة أسباب، لكنني قمت بتجربة BitKeeper في أحد المشاريع لفترة وجيزة.ربما بعد سنوات من استخدام نموذج مركزي بتنسيق أو بآخر (Perforce، Subversion، CVS) وجدت صعوبة في استخدام التحكم بالمصدر الموزع.

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

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

يدعم bzr عددًا لا بأس به من الميزات المختلفة سير العمل بدءًا من العمل المنفرد، مرورًا بالعمل كمستودع مركزي وحتى التوزيع الكامل.مع إمكانية دمج كل فرع (لمطور أو ميزة) بشكل مستقل، يمكن إجراء مراجعات التعليمات البرمجية على أساس كل فرع.

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

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

أنا ألعب مع Mercurial لمشاريعي المنزلية.ما يعجبني فيه حتى الآن هو أنه يمكنني الحصول على مستودعات متعددة.إذا أخذت جهاز الكمبيوتر المحمول الخاص بي إلى المقصورة، فلا يزال لدي التحكم في الإصدار، على عكس ما حدث عندما قمت بتشغيل نظام CVS في المنزل.المتفرعة سهلة مثل hg clone والعمل على الاستنساخ.

استخدام التخريب

لا يتم توزيع التخريب، مما يجعلني أعتقد أنني بحاجة إلى رابط ويكيبيديا في حالة عدم التأكد من ما أتحدث عنه :)

تم استخدام darcs 2.1.0 وهو رائع لمشاريعي.سهل الاستخدام.أحب قطف الكرز التغييرات.

أستخدم Git في العمل مع أحد زملائي في العمل.المستودع الرئيسي هو SVN، بالرغم من ذلك.غالبًا ما يتعين علينا تبديل محطات العمل ويجعل Git من السهل جدًا سحب التغييرات من مستودع محلي على جهاز آخر.عندما نعمل كفريق على نفس الميزة، يكون دمج عملنا أمرًا سهلاً.

يعد جسر git-svn متزعزعًا بعض الشيء، لأنه عند تسجيل الدخول إلى SVN، فإنه يعيد كتابة جميع الالتزامات لإضافة تعليق git-svn-id الخاص به.هذا يدمر التاريخ الجميل لعمليات الدمج بين منجم زميلي في العمل.أتوقع أننا لن نستخدم مستودعًا مركزيًا على الإطلاق إذا كان كل عضو في الفريق يستخدم Git.

لم تذكر ما هو نظام التشغيل الذي تقوم بتطويره، ولكن هناك عيبًا في Git وهو أنه يتعين عليك استخدام سطر الأوامر للحصول على جميع الميزات.Gitk عبارة عن واجهة مستخدم رائعة لتصور سجل الدمج، ولكن الدمج نفسه يجب أن يتم يدويًا.لم يتم صقل المكونات الإضافية لـ Git-Gui وVisual Studio بعد.

نحن نستخدم التحكم في الإصدار الموزع (البلاستيك SCM) لكل من السيناريوهات متعددة المواقع وغير المتصلة.

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

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

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow