قم بالنسخ الاحتياطي بكفاءة للعديد من إصدارات git repo مع مسافة اسم الفرع

Question

في العمل، نستخدم Perforce للتحكم في الإصدار.هناك مشاكل في هذا:1) مع هذا النموذج المركزي، لا يمكننا التحقق من التغييرات حتى تصبح جاهزة للانحدار.هذا يعني أنه ليس لدينا أي سيطرة على المراجعة أثناء عملية التطوير.2) نحن لا نقوم بعمل نسخة احتياطية لرؤية عملائنا للمستودع، لذا فإن عملنا غير آمن حتى نتمكن من التحقق منه.3) نواجه مشكلات في مشاركة الكود الخاص بنا مع كل منا ما لم نطلب إعداد فرع التكامل.أحاول إعداد سير عمل git اختياري للمطورين الذين يرغبون في استخدام git للتغلب على هذه المشكلات.

تتمثل الخطة في استخدام git-p4 للتفاعل مع الخادم بالضرورة وإنشاء git repo خاص.وهذا يعتني 1).أخطط لاستخدام سير عمل مدير التكامل الموضح في Git Pro (http://progit.org/book/ch5-1.html) لجعل مطورينا ينشرون اتفاقات إعادة الشراء العامة، مع الاهتمام بـ 3).

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

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

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

الآن ما أريد حدوثه بشكل مثالي هو أنه عندما يدفع بوب فرع الميزات الخاص به، ستتم إعادة تسمية الفرع إلى bob-feature على ال omni-backup بعيد.وعندما يسحب الميزة من omni-backup, ، يعود bob-feature.

لا يبدو أن هذا سهل التنفيذ في git.يبدو أنه يمكنني استخدام خطافات الدفع الموثقة في http://www.kernel.org/pub/software/scm/git/docs/git-receive-pack.html خطاف ما بعد الاستلام لإعادة كتابة اسم المرجع مباشرة بعد كتابته، ثم شئ ما يمكن القيام بذلك لعكس العملية في طريق العودة، لكنها تبدو هشة.أي شخص لديه فكرة أفضل؟

---

يحرر:بالنسبة لـ Vonc (لأن الكود تمتص التعليقات) ، يبدو طريقك واعداً ، فونك ، لكنني لا أرى كيف أن حقيقة أنه سيغلب على مشكلات تسوية الأسماء.هل تقترح وظيفة cronjob تعرف كيفية إعادة تسمية الفرع؟

مثل (قذرة حقًا):

foreach my $user (@users) {
    my @branches = split(/s/,cat `$LDAPSERVER/$USER/$REPO/.git/refs/heads`);
    foreach my $branch (@branches) {
        system "git fetch $LDAPSERVER/$USER/$REPO/$BRANCH:+$USER$BRANCH"
    }
}

Answer 1

لماذا تحتاج إلى أن يدفع المطور إلى omni-backup الريبو؟

لأغراض النسخ الاحتياطي، أفضل تسجيل مستودع المطورين المختلفين كمستودع بعيد، والقيام بذلك git fetch كل ليلة (من omni-backup الخادم) على جميع عمليات إعادة الشراء عن بعد.
وبهذه الطريقة، لا يوجد تواطؤ محتمل لاسم الفرع.وعملية أكثر آلية (لا يتعين على المطور أن يدفع بشكل صريح أي شيء على الريبو الذي لا يعمل معه بشكل مباشر، ولكنه سيفكر فقط في النسخ الاحتياطي)

ثم سأنتج القليل اللطيف git archive بعيدا عن المكان omni-backup وتخزينها بعيدا.

Answer 2

إذا كان بإمكانك جعل المطورين يتبعون إرشادات معينة، git push يمكن أن تفعل ذلك بشكل صحيح.

إذا قمت بتشغيل هذا الأمر:

git push omni-backup feature:bob-feature

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