Development/Git For LibreOffice Developers/ar

گِت Git هو نظام إدارة الاصدارات الموزعة (DVCS). هو نظام قوي جداً وبسيط في نفس الوقت، ولكن إذا لم تكن معتاداً على أنظمة إدارة الاصدارات، فإنه قد يكون مربكاً. ولكن لحسن الحظ يوجد على شبكة الانترنت العديد من المصادر الجيدة لتعلّم گِت Git مثل http://git-scm.com/. إذا لم تكن على معرفة بـ گِت Git، فينبغي أن تزور: بقية هذه المقالة ستفترض وجود معرفة تشغيل أساسية بـ گِت Git.
 * الموقع https://learngitbranching.js.org/ المتاز للتعلم بالممارسة بصرياً.
 * الموقع https://git-scm.com/book/ وهو كتاب Git احترافي لمؤلفيه Scott Chacon و Ben Straub.
 * گِت Git هو ترسيم غير دوري مُدار Directed Acyclic Graph (الذي أرشفه ) -- إذا كنت على معرفة بـ DAG فهذا أسرع شرح للنظرية.
 * الموقع https://www.youtube.com/watch?v=1ffBJ4sVUb4 لشرح سهل بصري.
 * الموقع https://who-t.blogspot.com/2009/12/on-commit-messages.html كيفية كتابة رسائل إيداعات جيدة.
 * الموقع https://github.com/k88hudson/git-flight-rules مرشد لممارسي گِت Git عمّا يفعلوه عندما لا تسير الأمور على ما يرام.

معظم الشفرات المصدرية للـLibreOffice موجودة في مستودَع  لـ گِت git، ولكن بعض الوحدات توجد في مستودَعات أخرى منفصلة، الترجمات   والمساعدة   والقواميس. في أغلب الأحوال لن تحتاج على الأرجح إلى تعديل هذه المستودَعات.

إدارة فروع گِت Git

 * انظر: Development/Branches

./g
مخزن 'core' يحتوي على برنامج خدمي صغير يُدعى g، موجود في ، عباره عن شفرة نصية تسمح لك بتشغيل نفس أمر git على 'core' وجميع المخازن الأخرى في.

عند معالجة الفروع (انشاء فروع، التبديل بينهم .. الخ) فمن الأفضل استخدام  للحفاظ على جميع المخازن في نفس الحالة.

أغلب الأوامر التي تكتب مثل ، يمكن كتابتها بهذا الشكل   وذلك يعني شغل   في كل مخزن موجود في.

إدارة فروع git
هناك صفحة مخصصة (باللغة الانجليزية) للفروع التي لدينا في git، الرجاء القاء نظرة على Development/Branches.

تحقق من الفروع الحالية
لمعرفة في أي فرع توجد مخازنك حالياً، نفذ:

~/loroot $ ./g branch

هذا سوف يسرد الفرع المحلي لكل مخزن، ويضع '*' عند الفروع النشطة حالياً. حالة الفروع يجب أن تكون موحدة في كل المخازن.

وضع " " بعد الأمر  سوف يظهر لك الفروع المتاحة في المخازن البعيدة (مثل لائحة بأهم الفروع المتاحة).

التحويل إلى فرع ميزة
دعونا ننشأ فرع ميزة جديد 'feature/slicebread'على جميع مخازن git على أساس origin/master، مما يسمح لك بتطوير ميزة جديدة بأمان:

~/loroot $ ./g checkout -b feature/slicebread origin/master

إذا قمت بعرض الفروع النشطة مرة أخرى، كل المخازن سوف تُظهر 'feature/slicebread'.

إذا أردت التحويل إلى فرع ميزة " feature branch" حالي، عوضاً عن انشاء واحد جديد، قم بالتالي:

~/loroot $ ./g -f checkout -b feature/slicebread origin/feature/slicebread

هذا سوف ينشأ فرع محلي 'feature/slicebread' يتبع الفرع البعيد feature/slicebread. يجبر  للذهاب من خلال جميع المخازن بدون توقف، حتى وإن كانت بعض المخازن لاتمتلك الفرع.

العودة: إذا أردت العودة إلى الفرع الرئيسي "master" وحذف الفرع المحلي الخاص بك، تأكد من أنه ليست لديك أي تغييرات غير محفوظة " uncommitted" في المخازن الخاصة بك ، ثم اذهب أولا إلى "master"، وبعدها قم بحذف فرعك المحلي feature/slicebread. ~/loroot $ ./g checkout master ~/loroot $ ./g -f branch -D feature/slicebread

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

الآن وقد نفذت ميزة جديدة أو أحرزت بعض التقدّم وترغب في الحصول على بعض ردود الفعل.

أولا، بما أن الفرع الرئيسي يُحتمل أن يكون قد تغير منذ انشائك فرع الميزة الخاص بك، يجب عليك عمل rebase للتغيراتك، بحيث تنطبق على أحدث نسخة من الفرع الرئيسي " master's HEAD"

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

~/loroot $ ./g checkout master

حدث الفرع الرئيسي

~/loroot $ ./g pull –r

إذا كنت تتسائل مامعنى هذا الأمر ، هو اختصار لـ

عُد إلى فرع الميزة الخاص بك

~/loroot $ ./g checkout feature/slicebread

قم بعمل rebase

~/loroot $ ./g rebase origin/master

إذا كان هناك تعارضات، فأنت تحتاج إلى حلهم بشكل يدوي ثم اعادة عمل rebase حتى تنتهي. والآن، حان الوقت للنشر. هناك حالتين.

إذا لم يكن لديك مجموعة من مخازن git تستطيع دفع هذه التغييرات إليها، يجب عليك إعداد مجموعة من ملفات الإصلاح لتستطيع ارسالهم الى المجموعة البريدية " Dev-List " للمراجعة.

~/loroot $ ./g format-patch --suffix=-@REPO@.patch --output-dir= master..HEAD

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

إذا كانت لديك القدرة للدفع إلى مجموعة من مخازن git:

~/loroot $ ./g push origin feature/slicebread

هناك الكثير من الدروس الممتازة والكتب والفيديو التي تشرح استعمال git. بيئة تطوير LibreOffice لديها 20 مخزن git التي هي منطقيا واحدة ولكن تحتاج إلى العناية بشكل منفصل.

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


 * يُسمح بأي تغييرات في الترجمات 'translations'.
 * يُسمح بأي اصلاحات للعلة.
 * يُسمح بالميزات المتأخرة التي تمت الموافقة عليها من قبل اللجنة التوجيهية

هناك قواعد أكثر صرامة خلال مرحلة الإصدار المرشح (RC)


 * يسمح بالإصلاح الآمن الذي تمت مراجعته من قبل شخص آخر، انظر أدناه
 * يُسمح بأي تغييرات في الترجمات 'translations'، من المستحسن أن تطلب مراجعة التغييرات من خلال القائمة البريدية l10n.

رجاء، لا تقم باعتماد الإصلاحات مباشرة خلال مرحلة الإصدار المرشح (RC). يُرجى بدلاً من ذلك، طلب المراجعة من مطور آخر من خلال القائمة البريدية [mailto:libreoffice@lists.freedesktop.org libreoffice@lists.freedesktop.org]، المراسلة الشخصية، برنامج المحادثة (IRC) أو من خلال صفحة بلاغ العلة. الإصلاح يجب أن يُودع " committed" عن طريق المُراجع باستخدام:

git commit -s --author='Author name '

ماذا تفعل عندما لا يعمل الأمر git pull -r
عادة يكون بسبب التغييرات الحاصلة في المخزن الخاص بك. وبالطبع تستطيع التخلص منها عن طريق استخدام:

git checkout -f ; git pull –r

أو اخفاؤها مؤقتاً، ويمكنك الحصول عليها لاحقاً باستخدام الأمر :

git stash ; git pull -r ; git stash pop

إعادة المخزن المعدل الخاص بك إلى المخزن الأصلي "vanilla"
~/loroot $ bin/g reset --hard origin/master

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

إعادة ترتيب أو بشكل عام تعديل التاريخ المحلي git rebase -i :
هي أداة قوية تسمح لك بإعادة كتابة 'rewrite' التاريخ المحلي الخاص بك. وهذا يجب أن يتم فقط على الاعتمادات التي لم تدفع "pushed" بعد !

دعنا نقول أنك في الفرع الرئيسي "master" وآخر 3 اعتمادات هي A,B,C=HEAD ولكن في الحقيقة C هو تصحيح للاعتماد A و نسيت أن تقوم به قبل اعتماد B. الآن ما تريد فعله هو دمج الفرعين A و C ليصبح التاريخ بهذا الشكل A,B

لفعل ذلك، نفذ

git branch safehead HEAD في حالة حدوث خطأ كبير وتريد التراجع عن كل شيء والعودة إلى الحالة الأولية

git rebase -i HEAD~3

بالتالي سوف تحصل على مثل هذه الرسالة في المحرر الخاص بك ( يتم السرد من الأقدم إلى الأحدث، وبالتالي C سوف يكون في آخر القائمة): pick 726fe9c enable localization of extension descriptions in mysqlc pick 9ab6ecf fix en-US only build pick a18bfb0 Revert "enable localization of extension descriptions in sdext" # # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # #
 * 1) Rebase 1846533..a18bfb0 onto 1846533
 * 1) Commands:
 * 1)  x, exec = Run a shell command , and stop if it fails
 * 1) If you remove a line here THAT COMMIT WILL BE LOST.
 * 2) However, if you remove everything, the rebase will be aborted.

قم بالتعديل ونقل الاعتماد C إلى الأعلى وتغيير النشاط "action" إلى "squash": pick 726fe9c enable localization of extension descriptions in mysqlc squash a18bfb0 Revert "enable localization of extension descriptions in sdext" pick 9ab6ecf fix en-US only build

قم بعمل حفظ ومن ثم انهاء المحرر.

إذا تم كل شيء كما يجب سوف تكون في الفرع الرئيسي "master" و HEAD على B.. و A+C سوف تكون قبل B. اما إذا ساءت الأمور، نفذ:

git rebase –abort

إذا لم يتم إعادة الأمور كما يجب، يمكنك تنفيذ git reset --hard safehead

والتظاهر بأن شيئاً لم يحدث على الإطلاق : )

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