सबरपो

गिट-सब्रेपो परियोजना लंबे समय से अस्तित्व में है, हालांकि, इसके कुछ संदर्भ हैं। Git-subrepo के लेखक Ingy döt Net हैं ।

यदि आप परियोजना के मास्टर ब्रांच के कमिट्स के इतिहास को देखते हैं, तो ऐसा लग सकता है कि प्रोजेक्ट 2 साल पहले विकास में रुक गया था। हालांकि, परियोजना पर काम चल रहा है और मुझे उम्मीद है कि संस्करण 0.4.0 जल्द ही जारी किया जाएगा।

इस टूल की एक महत्वपूर्ण संपत्ति यह है कि उपयोगकर्ता को गिट-सबरेपो को स्थापित करने के लिए आवश्यक नहीं है जब तक कि उपयोगकर्ता उपप्रोजेक्ट के अपस्ट्रीम रिपॉजिटरी में कमिट करने का निर्णय नहीं लेता है। इसके अलावा, उपयोगकर्ता मानक गिट-क्लोन (1) कमांड का उपयोग करके मुख्य रिपॉजिटरी की प्रतिलिपि बनाते समय पूरी तरह से तैयार और कॉन्फ़िगर किए गए स्रोत ट्री प्राप्त करता है।

जब मुख्य कंटेनर रिपॉजिटरी के सबमॉड्यूल्स / सबट्रेसेस / सबप्रोजेक्ट्स को सपोर्ट करने का माध्यम चुनते हैं, तो सबसे पहले डेवलपर संभावनाओं की सीमा निर्धारित करता है कि यह या वह तंत्र क्या प्रदान करता है और निम्नलिखित सवालों के जवाब देता है:

• क्या मुख्य रिपॉजिटरी या पर्याप्त स्क्वॉड कमिट में सबप्रोजेक्ट का पूरा इतिहास रखना आवश्यक है;
• क्या उपप्रोजेक्ट से उपप्रकार के अपस्ट्रीम रिपॉजिटरी में परिवर्तन देने की क्षमता की आवश्यकता है;
• क्या उपप्रकार के अपस्ट्रीम रिपॉजिटरी के निश्चित टैग को जोड़ने की आवश्यकता है या शाखाओं को जोड़ना संभव है;
• क्या यह दोनों उपप्रकारों को स्वयं हटाने के लिए आवश्यक होगा और, जो कि अनावश्यक हो गया है, इन उपप्रकारों के इतिहास का हिस्सा है;
• क्या उपयोगकर्ता को मुख्य परियोजना के भंडार को क्लोन करने के बाद मैन्युअल रूप से सबप्रोजेक्ट को कॉन्फ़िगर करने के लिए कोई कार्रवाई करनी होगी;
• उपप्रोजेक्ट और विशिष्ट संशोधनों से उपप्रोजेक्ट को जोड़ने के इतिहास का विश्लेषण करने का सवाल कितना श्रमसाध्य होगा;
• यह या यह उपकरण स्रोत कॉन्फ़िगरेशन प्रबंधन नीति को कैसे प्रभावित करेगा और यह उपकरण इंजीनियरों के रोजमर्रा के काम को कितना जटिल करेगा।

बेशक, प्रश्नों की यह सूची सही विकल्प के लिए आवश्यक इनपुट मापदंडों की पूर्णता को प्रतिबिंबित नहीं कर सकती है, लेकिन मौजूदा उपकरणों की प्रारंभिक समीक्षा के लिए, यह काफी पर्याप्त है और, गिट-सब्रेपो परियोजना की बात करते हुए , हम पाठक से इन पदों से इस परियोजना पर विचार करने का आग्रह करते हैं।

Git-subrepo स्थापना

Git-subrepo पैकेज , डेवलपर की ओर से, स्थानीय स्तर पर, अपने होम निर्देशिका में और सिस्टम स्तर पर दोनों को स्थापित किया जा सकता है।

पहले मामले में, गिट-सब्रेपो रिपॉजिटरी को वांछित निर्देशिका में क्लोन करने के लिए पर्याप्त है, उदाहरण के लिए, ~ / कोर :

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 

यह पता लगाना आसान है कि सिस्टम स्तर पर, गिट-सब्रेपो उस निर्देशिका में स्थापित किया गया है जहां गिट स्थित है:

 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 चर की उपस्थिति अतिरिक्त प्रयासों के बिना अनुमति देता है (निश्चित रूप से, यदि हम एक क्रॉस-एनवायरनमेंट में नहीं हैं) किसी भी लिनक्स वितरण के लिए एक पैकेज बनाने के लिए, जो 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$ 

गिट-सब्रेपो की क्षमताओं का विश्लेषण करने के लिए , हमें एक सरल परीक्षण वातावरण की आवश्यकता है जहां हम मानक ऑपरेटिंग परिदृश्यों को पुन: पेश कर सकते हैं।

पर्यावरण का परीक्षण करें

हम तीन निर्देशिका स्वामी , दूरस्थ , उपयोगकर्ता बनाते हैं, जिसमें हम डेवलपर और उपयोगकर्ता के अपस्ट्रीम और स्थानीय रिपॉजिटरी के मॉडल रखते हैं।

 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 सब्रेपो क्लोन कमांड का उपयोग करें, जो इसके उद्देश्य में git-clone (1) कमांड के समान है। कमांड के लिए आवश्यक पैरामीटर रिमोट रिपॉजिटरी का URL है। आप उस निर्देशिका को भी निर्दिष्ट कर सकते हैं जिसमें उपप्रोजेक्ट और दूरस्थ रिपॉजिटरी शाखा स्थित होगी। हम मास्टर शाखाओं के साथ काम करेंगे, इसलिए, हमारे उदाहरण में, हम अनावश्यक कमांड मापदंडों को छोड़ देते हैं।

इसलिए, परियोजना के लेखक, अपने काम करने वाली मशीन पर, गिट उपरेपो क्लोन का उपयोग करके बिल्ड-सिस्टम सबप्रोजेक्ट को कनेक्ट कर सकते हैं ../../remote/build-system.git/ बिल्ड-सिस्टम कमांड :

 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 कमांड का उपयोग करके प्राप्त की जा सकती है, उदाहरण के लिए, अपस्ट्रीम प्रोजेक्ट रिमोट / बिल्ड-सिस्टम.जिती के संशोधन का पता लगाने के लिए, जो अभी कमांड का उपयोग करके मुख्य रिपॉजिटरी में आया है:

 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 पैकेज .prorepo / config फ़ाइल में सबप्रोजेक्ट के बारे में जानकारी को सहेजता नहीं है , लेकिन .gitrepo फ़ाइल में है।

इसलिए, हमें अपस्ट्रीम रिपॉजिटरी रिमोट / बिल्ड-सिस्टम.गिट की मास्टर ब्रांच का नवीनतम संस्करण मिला और इसे मुख्य प्लेटफॉर्म प्रोजेक्ट के बिल्ड-सिस्टम सबडायरेक्ट में रखा।

अपस्ट्रीम रिपॉजिटरी रिमोट / प्लेटफॉर्म.गिट में इन बदलावों को देने के लिए, लेखक को गिट पुश कमांड को चलाने की जरूरत है:

 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$ 

गिट सब्रेपो कमांड के बारे में अधिक जानकारी ReadMe.pod फ़ाइल या कमांड लाइन से प्राप्त की जा सकती है

 bash-4.4$ git subrepo help <command> 

उदाहरण के लिए:

 bash-4.4$ git subrepo help clone 

अब सब कुछ पर विचार करें जो उपयोगकर्ता के हिस्से में होता है।

उपयोगकर्ताओं द्वारा कोड प्राप्त करना

फिलहाल, जब उपयोगकर्ता को अभी तक अपस्ट्रीम रिपॉजिटरी प्लेटफ़ॉर्म.गिट का अपडेट नहीं मिला है , तो उसकी कॉपी में एक READMP फ़ाइल है

 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$ 

उपयोगकर्ता को अपने निपटान में बिल के संशोधन के बिल्ड-सिस्टम सबप्रोजेक्ट का कोड होगा जो परियोजना के लेखक द्वारा निर्धारित किया गया है। उपयोगकर्ता किसी भी समय चालू कमांड को कॉन्फ़िगर कमांड का उपयोग करके अपडेट कर सकता है:

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

यह उल्लेखनीय है कि उपयोगकर्ता को अतिरिक्त सेटिंग्स करने की आवश्यकता नहीं है और वह इस तथ्य पर भरोसा कर सकता है कि परियोजना के लेखक ने उसे बिल्ट -सिस्टम रिवीजन दिया था जो काम करने के लिए मंच के वर्तमान संस्करण के लिए आवश्यक है।

यह वही है जो परियोजना के लेखक ने मांगी है।

एक अपस्ट्रीम प्रोजेक्ट में परिवर्तन करें

अब मान लीजिए कि हमारा उपयोगकर्ता परियोजना का सदस्य है और उसे न केवल अपस्ट्रीम रिपॉजिटरी रिमोट / प्लेटफॉर्म.गिट में बदलाव करने की अनुमति है, बल्कि रिमोट / बिल्ड-सिस्टम.जाइट सबप्रोजेक्ट के अपस्ट्रीम रिपॉजिटरी को भी।

तब यदि उपयोगकर्ता परिवर्तन करता है:

 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$ 

अपस्ट्रीम रिपॉजिटरी के साथ सीधा काम

अब विचार करें कि अपस्ट्रीम रिपॉजिटरी रिमोट / बिल्ड-सिस्टम.जीट में क्या हुआ

 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$ 

और सभी प्रतिभागियों, साथ ही मुख्य परियोजना के उपयोगकर्ता, गिट सब्रेपो कमांड का उपयोग करके इन परिवर्तनों को प्राप्त करने में सक्षम होंगे

 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$ 

निष्कर्ष

अगर डेवलपर को मुख्य रिपॉजिटरी में उपप्रोजेक्ट के इतिहास को संग्रहीत करने की आवश्यकता नहीं है और, कोड को वितरित करते समय, वह निश्चित टैग के बजाय शाखाओं के साथ संचालित होता है, तो रोजमर्रा के काम को व्यवस्थित करने के लिए गिट-सब्रेपो काफी उपयुक्त है।

सशर्त रूप से, गिट-सब्रेपो के नुकसान में से एक तथ्य यह है कि गिट सब्रेपो क्लोन ऑपरेशन उपप्रोजेक्ट शाखाओं के संबंध में ही संभव है। दूसरे शब्दों में, उपयोगकर्ता अपने निश्चित टैग या एक विशिष्ट संशोधन, जैसे कमांड, का उल्लेख करते हुए उपप्रोजेक्ट को कनेक्ट नहीं कर सकता है

 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 

मान्य नहीं है।

संदर्भ:

• गिट - सबट्री मर्जिंग
• मास्टरींग गिट उपटैब्स
• मैटरिंग गिट सबमॉडल्स
• सबरपो
• एक बड़ी परियोजना के लिए शाखा और गिट मॉड्यूल प्रबंधन मॉडल