گِت Git لمطوري ليبر أوفيس
TDF ليبر اوفيس Document Liberation Project Community Blogs Weblate Nextcloud Redmine اسأل ليبر اوفيس Donate
گِت Git هو نظام إدارة الاصدارات الموزعة (DVCS). هو نظام قوي جداً وبسيط في نفس الوقت، ولكن إذا لم تكن معتاداً على أنظمة إدارة الاصدارات، فإنه قد يكون مربكاً. ولكن لحسن الحظ يوجد على شبكة الانترنت العديد من المصادر الجيدة لتعلّم گِت Git مثل http://git-scm.com/. إذا لم تكن على معرفة بـ گِت Git، فينبغي أن تزور:
- الموقع https://learngitbranching.js.org/ المتاز للتعلم بالممارسة بصرياً.
- الموقع https://git-scm.com/book/ وهو كتاب Git احترافي لمؤلفيه Scott Chacon و Ben Straub.
- گِت Git هو ترسيم غير دوري مُدار Directed Acyclic Graph (الذي أرشفه Wayback Machine) -- إذا كنت على معرفة بـ 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 عمّا يفعلوه عندما لا تسير الأمور على ما يرام.
بقية هذه المقالة ستفترض وجود معرفة تشغيل أساسية بـ گِت Git.
معظم الشفرات المصدرية للـLibreOffice موجودة في مستودَع core
لـ گِت git، ولكن بعض الوحدات توجد في مستودَعات أخرى منفصلة، الترجمات translations
والمساعدة help
والقواميس dictionaries
. في أغلب الأحوال لن تحتاج على الأرجح إلى تعديل هذه المستودَعات.
إدارة فروع گِت Git
- انظر: Development/Branches
./g
مخزن 'core' يحتوي على برنامج خدمي صغير يُدعى g، موجود في ./g
، عباره عن شفرة نصية تسمح لك بتشغيل نفس أمر git على 'core' وجميع المخازن الأخرى في clone/
.
عند معالجة الفروع (انشاء فروع، التبديل بينهم .. الخ) فمن الأفضل استخدام ./g
للحفاظ على جميع المخازن في نفس الحالة.
أغلب الأوامر التي تكتب مثل git xxxx
، يمكن كتابتها بهذا الشكل ./g xxxx
وذلك يعني شغل git xxxx
في كل مخزن موجود في ./clone/'
.
إدارة فروع git
هناك صفحة مخصصة (باللغة الانجليزية) للفروع التي لدينا في git، الرجاء القاء نظرة على Development/Branches.
تحقق من الفروع الحالية
لمعرفة في أي فرع توجد مخازنك حالياً، نفذ:
~/loroot $ ./g branch
هذا سوف يسرد الفرع المحلي لكل مخزن، ويضع '*' عند الفروع النشطة حالياً. حالة الفروع يجب أن تكون موحدة في كل المخازن.
وضع "-r
" بعد الأمر 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. -f
يجبر bin/g
للذهاب من خلال جميع المخازن بدون توقف، حتى وإن كانت بعض المخازن لاتمتلك الفرع.
العودة: إذا أردت العودة إلى الفرع الرئيسي "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
إذا كنت تتسائل مامعنى هذا الأمر "git pull –r"
، هو اختصار لـ "git pull --rebase"
عُد إلى فرع الميزة الخاص بك
~/loroot $ ./g checkout feature/slicebread
قم بعمل rebase
~/loroot $ ./g rebase origin/master
إذا كان هناك تعارضات، فأنت تحتاج إلى حلهم بشكل يدوي ثم اعادة عمل rebase حتى تنتهي.
والآن، حان الوقت للنشر. هناك حالتين.
إذا لم يكن لديك مجموعة من مخازن git تستطيع دفع هذه التغييرات إليها، يجب عليك إعداد مجموعة من ملفات الإصلاح لتستطيع ارسالهم الى المجموعة البريدية " Dev-List " للمراجعة.
~/loroot $ ./g format-patch --suffix=-@REPO@.patch --output-dir=<where_you_want> master..HEAD
هذا سوف ينشئ ملف لكل اعتماد متبوعاً باسم المخزن، في الدليل الذي قمت بتحديده. وبعد ذلك يمكنك إرفاق الملفات برسالة الكترونية وإرسالها إلى القائمة البريدية.
إذا كانت لديك القدرة للدفع إلى مجموعة من مخازن git:
~/loroot $ ./g push origin feature/slicebread
هناك الكثير من الدروس الممتازة والكتب والفيديو التي تشرح استعمال git. بيئة تطوير LibreOffice لديها 20 مخزن git التي هي منطقيا واحدة ولكن تحتاج إلى العناية بشكل منفصل.
التعديل والاعتماد في فرع مستقر
يتم إنشاء الفروع المستقرة من الفرع الرئيسي "master" أو الفروع المستقرة الأخرى وذلك لتحقيق الاستقرار في قاعدة الشفرة للإصدار وكذلك صيانة التحديثات. هناك بعض القواعد خلال مرحة الإصدار التجريبي:
- يُسمح بأي تغييرات في الترجمات 'translations'.
- يُسمح بأي اصلاحات للعلة.
- يُسمح بالميزات المتأخرة التي تمت الموافقة عليها من قبل اللجنة التوجيهية
هناك قواعد أكثر صرامة خلال مرحلة الإصدار المرشح (RC)
- يسمح بالإصلاح الآمن الذي تمت مراجعته من قبل شخص آخر، انظر أدناه
- يُسمح بأي تغييرات في الترجمات 'translations'، من المستحسن أن تطلب مراجعة التغييرات من خلال القائمة البريدية l10n.
رجاء، لا تقم باعتماد الإصلاحات مباشرة خلال مرحلة الإصدار المرشح (RC). يُرجى بدلاً من ذلك، طلب المراجعة من مطور آخر من خلال القائمة البريدية libreoffice@lists.freedesktop.org، المراسلة الشخصية، برنامج المحادثة (IRC) أو من خلال صفحة بلاغ العلة. الإصلاح يجب أن يُودع " committed" عن طريق المُراجع باستخدام:
git commit -s --author='Author name <author@mail.address>'
ماذا تفعل عندما لا يعمل الأمر git pull -r
عادة يكون بسبب التغييرات الحاصلة في المخزن الخاص بك. وبالطبع تستطيع التخلص منها عن طريق استخدام:
git checkout -f ; git pull –r
أو اخفاؤها مؤقتاً، ويمكنك الحصول عليها لاحقاً باستخدام الأمر git pull -r
:
git stash ; git pull -r ; git stash pop
إعادة المخزن المعدل الخاص بك إلى المخزن الأصلي "vanilla"
~/loroot $ bin/g reset --hard origin/master
سيتم تجاهل كافة التغييرات المحلية ( سواء تم اعتمادها " committed" أو لا) وإعادة الفرع الحالي الذي تعمل عليه إلى الموجود في المخزن البعيد.
إعادة ترتيب أو بشكل عام تعديل التاريخ المحلي git rebase -i:
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" # Rebase 1846533..a18bfb0 onto 1846533 # # Commands: # 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 # x <cmd>, exec <cmd> = Run a shell command <cmd>, and stop if it fails # # If you remove a line here THAT COMMIT WILL BE LOST. # 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
والتظاهر بأن شيئاً لم يحدث على الإطلاق : )
الحصول على صلاحيات الاعتماد واستخدامها
من أجل الحصول على صلاحيات الاعتماد تحتاج إلى أن تكون "تحت رعاية". بمجرد أن ترسل ملفات الإصلاح وتصبح معروفاً لن يشكل لك هذا عائقاً، ولكن يفضل أن تنتظر حتى يطلب منك ذلك. إذا طلب منك ذلك ( أو طلبت من أحد رعايتك)، سوف تحتاج أن تحصل على حساب
مرجع سريع لـ git / ./g
task | command |
---|---|
إعداد المخزن للدفع | ./g config remote.origin.pushurl ssh://git.freedesktop.org/git/libreoffice/@REPO@
|
إضافة مجموعة أخرى من المخازن البعيدة، مثل مجموعة المخازن staging | ./g remote add staging ssh://git.freedesktop.org/git/libreoffice/staging/@REPO@
|
انشاء فرع ميزة | ./g checkout -b feature/foo
|
نشرع فرع ميزة | ./g push origin feature/foo
|
نشر فرع باسم مختلف | ./g push origin my_local_branch_name:feature/the_good_name
|
حذف فرع ميزة من git البعيدة | ./g push origin :feature/foo
|
البحث في جميع المخازن | ./g grep "<regular_expression>"
|