جيت سوبريبو

مشروع git-subrepo موجود منذ فترة طويلة ، ومع ذلك ، هناك القليل من الإشارات إليه. مؤلف git-subrepo هو Ingy döt Net .

إذا نظرت إلى تاريخ التزامات الفرع الرئيسي للمشروع ، فقد يبدو أن المشروع توقف عن التطوير قبل عامين. ومع ذلك ، يجري العمل على المشروع وآمل أن يتم إصدار الإصدار 0.4.0 قريبًا.

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

عند اختيار وسائل دعم الوحدات الفرعية / الشرائط الفرعية / المشاريع الفرعية لمستودع الحاوية الرئيسي ، يحدد المطور أولاً نطاق الاحتمالات التي توفرها هذه الآلية أو تلك ويقدم إجابات على الأسئلة التالية:

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

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

تركيب Git-subrepo

يمكن تثبيت حزمة git-subrepo ، من جانب المطور ، محليًا ، في دليلها الرئيسي ، وعلى مستوى النظام.

في الحالة الأولى ، يكفي استنساخ مستودع git-subrepo في الدليل المطلوب ، على سبيل المثال ، ~ / bin :

bash-4.4$ cd ~/bin bash-4.4$ git clone https://github.com/ingydotnet/git-subrepo.git 

وإعداد متغيرات البيئة

 bash-4.4$ vim subrepo-env.sh #!/bin/sh export GIT_SUBREPO_ROOT="/home/username/bin/git-subrepo" export PATH="/home/username/bin/git-subrepo/lib:$PATH" export MANPATH="/home/username/bin/git-subrepo/man:$MANPATH" :wq bash-4.4$ source ./subrepo-env.sh 

إذا نظرت إلى المتغيرات المحددة في ملف git-subrepo Makefile :

 # Install variables: PREFIX ?= /usr/local INSTALL_LIB ?= $(DESTDIR)$(shell git --exec-path) INSTALL_EXT ?= $(INSTALL_LIB)/$(NAME).d INSTALL_MAN1 ?= $(DESTDIR)$(PREFIX)/share/man/man1 

من السهل معرفة أنه على مستوى النظام ، يتم تثبيت git-subrepo في الدليل حيث يوجد Git :

 bash-4.4$ bash-4.4$ git --exec-path /usr/libexec/git-core bash-4.4$ 

وبالتالي ، قد يبدو أمر تثبيت git-subrepo ، على سبيل المثال ، كما يلي:

 bash-4.4$ make PREFIX=/usr install 

يسمح وجود متغير DESTDIR بدون بذل جهود إضافية (بالطبع ، إذا لم نكن في بيئة مشتركة) لعمل حزمة لأي توزيع Linux ، والتي يمكن أن تكون مفيدة لمهندسي DevOps.

تثبيت git-subrepo كجذر:

 bash-4.4$ bash-4.4$ cd git-subrepo/ bash-4.4$ make PREFIX=/usr install install -C -d -m 0755 /usr/libexec/git-core/ install -C -m 0755 lib/git-subrepo /usr/libexec/git-core/ install -C -d -m 0755 /usr/libexec/git-core/git-subrepo.d/ install -C -m 0755 lib/git-subrepo.d/help-functions.bash lib/git-subrepo.d/bash+.bash /usr/libexec/git-core/git-subrepo.d/ install -C -d -m 0755 /usr/share/man/man1/ install -C -m 0644 man/man1/git-subrepo.1 /usr/share/man/man1/ bash-4.4$ 

لتحليل قدرات git-subrepo ، نحتاج إلى بيئة اختبار بسيطة حيث يمكننا إعادة إنتاج سيناريوهات التشغيل القياسية.

بيئة الاختبار

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

 bash-4.4$ vim _init.sh #!/bin/sh CWD=`pwd` mkdir remote owner user cd remote git init --bare build-system.git git init --bare platform.git cd ../owner git clone $CWD/remote/build-system.git git clone $CWD/remote/platform.git cd build-system echo -e "\n[master] build-system 1.0.0\n" >README git add README git commit -m "init build-system master 1.0.0" git push cd ../platform echo -e "\n[master] platform 1.0.0\n" >README git add README git commit -m "init platform master 1.0.0" git push cd ../../user git clone $CWD/remote/build-system.git git clone $CWD/remote/platform.git cd $CWD :wq bash-4.4$ bash-4.4$ ./_init.sh bash-4.4$ 

هنا

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

تتمثل مهمة المؤلف في تضمين الميزات التالية في الشجرة الرئيسية للنظام الأساسي من خلال تضمين المشروع الفرعي لنظام builld في الشجرة الرئيسية:

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

ضع في اعتبارك تصرفات المؤلف التي يجب عليه تنفيذها لتنفيذ هذه المتطلبات.

اتصال المشروع الفرعي

لتوصيل شجرة فرعية جديدة ، استخدم الأمر git subrepo clone ، الذي يشبه في غرضه الأمر git-clone (1) . المعلمة المطلوبة للأمر هي عنوان URL للمستودع البعيد. يمكنك أيضًا تحديد الدليل الذي سيوجد فيه المشروع الفرعي وفرع المستودع البعيد. سنعمل مع الفروع الرئيسية ، وبالتالي ، في مثالنا ، نحذف معلمات الأوامر غير الضرورية.

لذا ، يمكن لمؤلف المشروع ، على جهاز عمله ، توصيل المشروع الفرعي لنظام البناء باستخدام git subrepo clone ../../remote/build-system.git/ build-system command :

 bash-4.4$ bash-4.4$ cd owner/platform/ bash-4.4$ git subrepo clone ../../remote/build-system.git/ build-system Subrepo '../../remote/build-system.git' (master) cloned into 'build-system'. bash-4.4$ 

ضع في اعتبارك التغييرات التي حدثت في مستودع النظام الأساسي المحلي:

 bash-4.4$ bash-4.4$ git status On branch master Your branch is ahead of 'origin/master' by 1 commit. (use "git push" to publish your local commits) nothing to commit, working tree clean bash-4.4$ bash-4.4$ bash-4.4$ git subrepo status 1 subrepo: Git subrepo 'build-system': Remote URL: ../../remote/build-system.git Upstream Ref: b2f5079 Tracking Branch: master Pulled Commit: b2f5079 Pull Parent: b5e76a7 bash-4.4$ 

لا يتم تسليم تاريخ المشروع الفرعي لنظام البناء إلى الشجرة الرئيسية ؛ لدينا التزام واحد مضغوط ، مصحوبًا بمعلومات أساسية. تأتي هذه المعلومات تحت التحكم في الإصدار في الملف ./build-system/.gitrepo/config :

 [subrepo] remote = ../../remote/build-system.git branch = master commit = b2f507918f2821cb7dd90c33223ed5cc3c9922a2 parent = b5e76a713f895565b06ee3ccfa29f19131ba06dd method = merge cmdver = 0.4.1 

يمكن الحصول على معلومات حول المشاريع الفرعية باستخدام الأمر git subrepo config ، على سبيل المثال ، لمعرفة مراجعة مشروع المنبع البعيد / build-system.git ، الذي وصل للتو إلى المستودع الرئيسي ، باستخدام الأمر:

 bash-4.4$ bash-4.4$ git subrepo config build-system commit Subrepo 'build-system' option 'commit' has value 'b2f507918f2821cb7dd90c33223ed5cc3c9922a2'. bash-4.4$ 

وتجدر الإشارة إلى أن حزمة git-subrepo الأصلية لا تحفظ معلومات حول المشاريع الفرعية في ملف .gitrepo / config ، ولكن في ملف .gitrepo .

لذلك ، حصلنا على أحدث إصدار من الفرع الرئيسي لمستودع المنبع البعيد / build-system.git ووضعناه في الدليل الفرعي لنظام البناء لمشروع المنصة الرئيسية.

لتسليم هذه التغييرات إلى مستودع التحكم عن بعد / platform.git ، يحتاج المؤلف إلى تشغيل الأمر git push :

 bash-4.4$ bash-4.4$ git push Enumerating objects: 7, done. Counting objects: 100% (7/7), done. Delta compression using up to 4 threads Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 849 bytes | 849.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0) To /home/prog/0.4.1/remote/platform.git <font color="#8b0000">b5e76a7..6b831e4</font> master -> master bash-4.4$ 

يمكن الحصول على مزيد من المعلومات حول أوامر git subrepo من ملف ReadMe.pod أو من سطر الأوامر

 bash-4.4$ git subrepo help <command> 

على سبيل المثال:

 bash-4.4$ git subrepo help clone 

ضع في اعتبارك الآن كل ما يحدث من جانب المستخدم.

الحصول على رمز من قبل المستخدمين

في الوقت الحالي ، عندما لا يتلقى المستخدم تحديثًا لمنصة التخزين الرئيسية المنصة. git ، تحتوي نسخته على ملف README واحد

 bash-4.4$ bash-4.4$ cd user/platform/ bash-4.4$ ls README bash-4.4$ 

تحتوي على سطر واحد:

 bash-4.4$ bash-4.4$ cat README [master] platform 1.0.0 bash-4.4$ 

بعد كسر تغييرات مستودع المنبع

 bash-4.4$ bash-4.4$ git pull remote: Enumerating objects: 7, done. remote: Counting objects: 100% (7/7), done. remote: Compressing objects: 100% (4/4), done. remote: Total 6 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (6/6), done. From /home/prog/0.4.1/remote/platform b5e76a7..6b831e4 master -> origin/master Updating <font color="#8b0000">b5e76a7..6b831e4</font> Fast-forward build-system/.gitrepo/config | 12 ++++++++++++ build-system/README | 3 +++ 2 files changed, 15 insertions(+) create mode 100644 build-system/.gitrepo/config create mode 100644 build-system/README bash-4.4$ 

سيكون لدى المستخدم تحت تصرفه كود المشروع الفرعي لنظام البناء للمراجعة التي حددها مؤلف المشروع بالضبط. يمكن للمستخدم تحديث المراجعة الحالية في أي وقت باستخدام الأمر config :

 bash-4.4$ bash-4.4$ git subrepo config build-system/ commit Subrepo 'build-system' option 'commit' has value 'b2f507918f2821cb7dd90c33223ed5cc3c9922a2'. bash-4.4$ 

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

هذا هو بالضبط ما سعى مؤلف المشروع.

أدخل التغييرات على مشروع المنبع

لنفترض الآن أن مستخدمنا عضو في المشروع ويسمح له بتقديم تغييرات ليس فقط على مستودع المنبع البعيد / platform.git ، ولكن أيضًا على مستودع المنبع للمشروع الفرعي عن بعد / build-system.git .

ثم إذا أجرى المستخدم التغييرات:

 bash-4.4$ bash-4.4$ cd build-system/ bash-4.4$ vim README bash-4.4$ cat README [master] build-system 1.0.1 bash-4.4$ bash-4.4$ git commit -a -m "update BS version to 1.0.1" [master d30b001] update BS version to 1.0.1 1 file changed, 1 insertion(+), 1 deletion(-) bash-4.4$ bash-4.4$ cd .. bash-4.4$ git log commit d30b001286b08708f5c30c1f5346a90e4339f969 (HEAD -> master) Author: user <___@_____> Date: Tue Oct 30 10:49:32 2018 +0300 update BS version to 1.0.1 . . . bash-4.4$ 

سيكون قادراً على وضعها في مستودعات المنبع على النحو التالي:

 bash-4.4$ bash-4.4$ git subrepo push build-system/ Subrepo 'build-system' pushed to '../../remote/build-system.git' (master). bash-4.4$ 

 bash-4.4$ bash-4.4$ git status On branch master Your branch is ahead of 'origin/master' by 2 commits. (use "git push" to publish your local commits) nothing to commit, working tree clean bash-4.4$ bash-4.4$ git push Enumerating objects: 14, done. Counting objects: 100% (14/14), done. Delta compression using up to 4 threads Compressing objects: 100% (7/7), done. Writing objects: 100% (9/9), 992 bytes | 992.00 KiB/s, done. Total 9 (delta 1), reused 0 (delta 0) To /home/prog/0.4.1/remote/platform.git d00be9f..deccb66 master -> master bash-4.4$ 

العمل المباشر مع مستودع المنبع

ضع في اعتبارك الآن ما حدث في مستودع المنبع البعيد / build-system.git

 bash-4.4$ bash-4.4$ cd owner/build-system/ bash-4.4$ bash-4.4$ git pull remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From /home/prog/0.4.1/remote/build-system b2f5079..d229920 master -> origin/master Updating b2f5079..d229920 Fast-forward README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) bash-4.4$ bash-4.4$ git log commit d229920c7de34405bc7b8d47f36d420987687908 (HEAD -> master, origin/master) Author: user <___@_____> Date: Tue Oct 30 10:49:32 2018 +0300 update BS version to 1.0.1 commit b2f507918f2821cb7dd90c33223ed5cc3c9922a2 Author: user <___@_____> Date: Tue Oct 30 10:05:30 2018 +0300 init build-system master 1.0.0 bash-4.4$ 

أي أن مؤلف المشروع تلقى التغييرات التي أجراها المشارك في المشروع.

بالطبع ، يمكن للمؤلف إجراء تغييرات مباشرة على مستودع المنبع لمشروع نظام البناء :

 bash-4.4$ bash-4.4$ cd owner/build-system/ bash-4.4$ bash-4.4$ vim README bash-4.4$ cat README [master] build-system 1.0.2 bash-4.4$ git commit -a -m "update build-system version to 1.0.2" [master 8255f59] update build-system version to 1.0.2 1 file changed, 1 insertion(+), 1 deletion(-) bash-4.4$ git push Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Writing objects: 100% (3/3), 281 bytes | 281.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To /home/prog/0.4.1/remote/build-system.git d229920..8255f59 master -> master bash-4.4$ 

وسيتمكن جميع المشاركين ، بالإضافة إلى مستخدمي المشروع الرئيسي ، من تلقي هذه التغييرات باستخدام الأمر git subrepo pull

 bash-4.4$ bash-4.4$ cd owner/platform/ bash-4.4$ bash-4.4$ git subrepo pull build-system/ Subrepo 'build-system' pulled from '../../remote/build-system.git' (master). bash-4.4$ git status On branch master Your branch is ahead of 'origin/master' by 1 commit. (use "git push" to publish your local commits) nothing to commit, working tree clean bash-4.4$ git push Enumerating objects: 11, done. Counting objects: 100% (11/11), done. Delta compression using up to 4 threads Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 670 bytes | 670.00 KiB/s, done. Total 6 (delta 1), reused 0 (delta 0) To /home/prog/0.4.1/remote/platform.git 6b831e4..b6f4a7b master -> master bash-4.4$ 

الاستنتاجات

إذا لم يكن المطور بحاجة إلى تخزين تاريخ المشاريع الفرعية في المستودع الرئيسي ، وعند تسليم الكود ، فإنه يعمل مع الفروع بدلاً من العلامات الثابتة ، فإن git-subrepo مناسب تمامًا لتنظيم العمل اليومي.

بشكل مشروط ، أحد عيوب git-subrepo هو حقيقة أن عملية استنساخ git subrepo ممكنة فقط فيما يتعلق بفروع المشروع الفرعي. بمعنى آخر ، لا يمكن للمستخدم ربط المشروع الفرعي بالإشارة إلى علامته الثابتة أو مراجعة محددة ، أي أوامر مثل

 bash-4.4$ git subrepo clone ../../remote/build-system.git build-system -t 1.0.1 bash-4.4$ git subrepo clone ../../remote/build-system.git build-system 7f5d1113eb0bc6 

غير صالح.

الأدب:

• دمج الشجرة الفرعية
• اتقان git الفرعية
• إتقان الوحدات الفرعية git
• جيت سوبريبو
• نموذج إدارة وحدة التفرع و git لمشروع كبير