كيف أتأكد من أن رمز git repo الخاص بي آمن؟

Question

إذا كانت مؤسستنا ستتحول من VCS للخادم المركزي مثل Subversion إلى VCS موزعة مثل git، فكيف يمكنني التأكد من أن جميع التعليمات البرمجية الخاصة بي آمنة من فشل الأجهزة؟

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

لاحظ أنني لا أعتبره خيارًا جيدًا "لجعل المطورين يدفعون الفروع إلى الخادم" - هذا هو مضجر وسينتهي الأمر بالمطورين بعدم القيام بذلك.

هل هناك طريقة مشتركة للتغلب على هذه المشكلة؟

بعض التوضيح:

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

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

إذن الفرق الذي أراه (صححني إذا كنت مخطئًا!):من المحتمل ألا تكون الميزات وإصلاحات الأخطاء التي تم تنفيذها جزئيًا متاحة للنسخ الاحتياطي على الخادم المركزي إذا كنا نستخدم DVCS، ولكننا نستخدم VCS عاديًا.كيف أحافظ على هذا الرمز آمنًا؟

Answer 1

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

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

بمجرد قيامك بإعداد مستودع مركزي، يمكنك استخدام سير عمل نمط cvs/svn للتحقق والتحديث.يصبح تحديث السيرة الذاتية git fetch and rebase إذا كانت لديك تغييرات محلية أو مجرد git pull إذا لم يكن لديك تغييرات.التزام السيرة الذاتية يصبح git Commit و git Push.

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

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

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

من ناحية أخرى، يمكن استخدام استخدام الالتزامات المحلية كميزة.لا ينبغي أن يكون دفع جميع الالتزامات المحلية إلى مكان آمن في المستودع المركزي أمرًا صعبًا للغاية.يمكن تخزين الفروع المحلية في مساحة اسم علامة خاصة بالمطور.

على سبيل المثال، بالنسبة لـ Joe Bloggs، يمكن إنشاء اسم مستعار في مستودعه المحلي لتنفيذ شيء مثل ما يلي ردًا على (على سبيل المثال) git mybackup.

git push origin +refs/heads/*:refs/jbloggs/*

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

وهذا يساعد في جميع أنواع الكوارث.تنفجر آلة Joe ويمكنه استخدام جهاز آخر وجلب الالتزامات المحفوظة والمتابعة من حيث توقف.جو مريض؟يمكن لفريد إحضار فروع جو للحصول على الإصلاح "الضروري" الذي قام به بالأمس ولكن لم تتح له الفرصة للاختبار ضد المعلم.

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

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

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

Answer 2

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

مع وجود عدد غير قليل من المطورين الذين يعملون في مشروع ما، سيكون الأمر شاقًا جدًا أن تتذكر سحب التغييرات من أي شخص آخر.ماذا كنت ستفعل لو كنت لم يفعل ذلك هل لديك مستودع مركزي؟

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

Answer 3

ليس من غير المألوف استخدام خادم "مركزي" كمرجع في DVCS، والذي يوفر لك أيضًا المكان المناسب لإجراء النسخ الاحتياطية.

Answer 4

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

باستخدام التحكم في الإصدار الموزع، تكون المستودعات الموجودة على خوادم المطورين قيد التقدم.هل تريد عمل نسخة احتياطية منه؟ثم قم بعمل نسخة احتياطية منه!إنها بهذه السهولة.

لدينا نظام نسخ احتياطي آلي يلتقط أي أدلة نحددها من أجهزتنا، لذلك أقوم بإضافة أي مستودعات ونسخ عمل على جهازي إلى ذلك الأخير، بما في ذلك مستودعات git وCVS.

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

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

Answer 5

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

Answer 6

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

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

كملاحظة جانبية، عند الحديث عن أمان الريبو، على الخادم الخاص بك، يمكنك إعداد خطاف ما بعد الالتزام الذي يقوم باستنساخ git بسيط أو دفع git إلى جهاز آخر...يمكنك الحصول على نسخة احتياطية محدثة بعد كل التزام!

Answer 7

نحن نستخدم rsync لعمل نسخة احتياطية من أدلة .git للمطورين الفرديين إلى دليل على الخادم.يتم هذا الإعداد باستخدام البرامج النصية المجمعة حول git clone والالتزام اللاحق وما إلى ذلك.خطافات.

نظرًا لأنه يتم تنفيذه في خطاف ما بعد *، لا يحتاج المطورون إلى تذكر القيام بذلك يدويًا.ولأننا نستخدم rsync مع انتهاء المهلة، إذا تعطل الخادم أو كان المستخدم يعمل عن بعد، فلا يزال بإمكانه العمل.