जब मैंने इस पुराने पोस्ट को संपादित करने की कोशिश की, तो सभी प्रारूपण उड़ गए। शायद किसी दिन मैं इसे ठीक कर दूंगा।मैंने कई महीने Git-svn glitches से लड़ने में बिताए और विभिन्न विकल्पों के बारे में सोचने से पहले एक वेबसाइट के साथ वर्कफ़्लो के आयोजन के इस तरीके पर आया - सरल, लचीला और उपयोग करने में आसान।
मुख्य लाभ:
- रिमोट कॉपी से एक धक्का देकर हम स्वचालित रूप से साइट की लाइव कॉपी को अपडेट करते हैं
- सर्वर पर फ़ाइलों को संपादित करने से कमिट का इतिहास नष्ट नहीं होगा
- सादगी, कोई विशेष प्रतिबद्ध नियमों की जरूरत नहीं है
- फ़ाइलों को फिर से तैनात या स्थानांतरित किए बिना, पहले से ही चल रही साइट पर लागू किया जा सकता है
सिंहावलोकन
सिस्टम का मुख्य विचार सर्वर पर दो रिपॉजिटरी बनाना है: एक खाली नंगे रिपॉजिटरी और साइट की एक कामकाजी प्रति के साथ एक नियमित रिपॉजिटरी। यह जोड़ी सरल हुक की एक जोड़ी से जुड़ी है जो पुश और स्वचालित परिवर्तनों को स्वचालित करती है।
तो, दो रिपॉजिटरी:
- हब एक नंगे भंडार है। सभी डेवलपर रिपॉजिटरी से उसका क्लोन तैयार किया जाता है।
- प्राइम एक नियमित भंडार है। साइट को इस रिपॉजिटरी की वर्किंग डायरेक्टरी से लॉन्च किया गया है।
दो रिपॉजिटरी के साथ काम करना सरल और बहुत लचीला है। एसएच एक्सेस के साथ रिमोट कॉपी आसानी से
हब रिपॉजिटरी पर
पुश करके साइट के लाइव संस्करण को अपडेट कर सकते हैं। सर्वर पर लाइव संस्करण में किए गए किसी भी बदलाव को तुरंत कमिट करते समय हब में प्रवाहित किया जाता है। सामान्य तौर पर, सब कुछ बहुत सरलता से काम करता है - और कोई फर्क नहीं पड़ता कि परिवर्तन कहां किए गए हैं।
लॉन्च से पहले छोटी तैयारी
स्वाभाविक रूप से, सबसे पहले, आपको सर्वर पर और सभी विकास कंप्यूटरों पर Git स्थापित करने की आवश्यकता है। यदि आपके साझा होस्टिंग पर Git स्थापित नहीं है, तो आप
इसे आसानी से
ठीक कर सकते हैं (en)।
यदि यह आपके सर्वर पर पहली बार Git के साथ काम कर रहा है, तो
वैश्विक सेटिंग निर्दिष्ट करना सुनिश्चित करें। मैं प्रोजेक्ट इतिहास में सर्वर पर किए गए परिवर्तनों को देखने के लिए
user.name के लिए विशेष मान निर्दिष्ट करता हूं:
$ git config --global user.name ", "
चलो चलते हैं!
सबसे पहले, हमारी साइट की लाइव डायरेक्टरी में एक नया git रिपॉजिटरी बनाएं, और फिर सभी साइट फाइल्स को जोड़ें और कमिट करें। यह
प्राइम रिपॉजिटरी और वर्किंग कॉपी होगी। यहां तक कि अगर अन्य स्थानों में पहले से ही परियोजना का इतिहास है, तो साइट की सामग्री आधार बिंदु होगी, जिसमें फिर अन्य सभी प्रतियां विलय कर दी जाएंगी।
$ cd ~/www
$ git init
$ git add .
$ git commit -m " "
चूंकि हमने रिपॉजिटरी की प्रारंभिक गणना एक काम की प्रतिलिपि में की है - इसलिए रखरखाव के लिए साइट को बंद करने और सभी फाइलों को फिर से अपलोड करने की कोई आवश्यकता नहीं है, Git बस मौजूदा फाइलों से रिपॉजिटरी की रचना करेगा।
अब जब हमारी साइट पहले से ही Git में है, तो साइट की वर्किंग डायरेक्टरी के बाहर कहीं नंगे रिपॉजिटरी बनाएं।
$ cd
$ mkdir site_hub.git
$ cd site_hub.git
$ git --bare init
Initialized empty Git repository in /home/joe/site_hub.git
हुर्रे! आइए साइट की कार्यशील निर्देशिका पर वापस जाएं और
हब को दूरस्थ रिपॉजिटरी के रूप में जोड़ें, और फिर
हब में मास्टर रिपॉजिटरी से मास्टर शाखा की सामग्री डालें।
$ cd ~/www
$ git remote add hub ~/site_hub.git
$ git remote show hub
* remote hub
URL: /home/joe/site_hub.git
$ git push hub master
hooky
जैसा कि मैंने शुरुआत में बताया, हब और प्राइम दो सरल लिपियों का उपयोग करके एक-दूसरे के साथ सिंक्रनाइज़ होते हैं।
Git के साथ काम करते समय मूल नियमों में से एक एक रिपॉजिटरी के लिए कभी भी धकेलना नहीं है जिसमें एक कार्यशील प्रति है। हम इस नियम का पालन करते हैं और "हब" रिपॉजिटरी बनाते हैं। हब से एक धक्का करने के बजाय, जो किसी भी तरह से काम की नकल को प्रभावित नहीं करता है, हम एक हुक का उपयोग करेंगे जो प्राइम को हब भंडार से खींचने के लिए मजबूर करेगा।
पोस्ट-अपडेट - हब रिपॉजिटरी में
जैसे ही हब में परिवर्तन का एक नया बैच आएगा, इस स्क्रिप्ट को तुरंत निष्पादित किया जाएगा। हम प्राइम रिपॉजिटरी की वर्किंग डायरेक्टरी में जाते हैं, और हब से परिवर्तन खींचते हैं। पुशिंग परिवर्तन (पुश) रिपॉजिटरी की वर्किंग डायरेक्टरी की स्थिति को नहीं बदलता है, यही कारण है कि वर्किंग डायरेक्टरी में रहते हुए पुल करना चाहिए।
#!/bin/sh
echo
echo "**** Prime [Hub's post-update hook]"
echo
cd $HOME/www || exit
unset GIT_DIR
git pull hub master
exec git update-server-info
पोस्ट-कमिट - प्राइम रिपॉजिटरी में
यह स्क्रिप्ट प्राइम रिपॉजिटरी में प्रत्येक कमिटमेंट के बाद चलती है और हब में बदलाव को आगे बढ़ाती है। एक आदर्श दुनिया में, निश्चित रूप से, हम कभी भी सर्वर पर सीधे कुछ भी नहीं करेंगे। लेकिन हमारी अपूर्ण दुनिया में कुछ भी संभव है, तो चलिए परिवर्तनों को आगे बढ़ाने की प्रक्रिया को स्वचालित करें ताकि परियोजना के इतिहास को नष्ट न करें और संभावित संघर्षों से बचें।
#!/bin/sh
echo
echo "**** pushing changes to Hub [Prime's post-commit hook]"
echo
git push hub
तो, इस हुक का उपयोग करते हुए, हम तुरंत हब रिपॉजिटरी में प्राइम रिपॉजिटरी की मास्टर शाखा में किए गए सभी परिवर्तनों को प्राप्त करते हैं। अन्य शाखाओं को भी क्लोन किया जा सकता है, लेकिन वे साइट को प्रभावित नहीं करेंगे। चूंकि सभी दूरस्थ प्रतियां एसएसएच पते के माध्यम से हब तक पहुंच प्राप्त करती हैं, केवल शेल तक सीधे पहुंच वाले उपयोगकर्ता एक धक्का दे सकते हैं और सीधे साइट को अपडेट करना शुरू कर सकते हैं।
संघर्ष
दो रिपॉजिटरी को सिंक्रनाइज़ करने के लिए इस तरह की प्रणाली के साथ एक साइट "लेट" करना बहुत मुश्किल है। प्राइम में किए गए प्रत्येक परिवर्तन स्वचालित रूप से हब में हो जाते हैं और सभी संघर्ष तुरंत दिखाई देंगे जब रिपॉजिटरी क्लोन से धक्का देने की कोशिश की जाएगी।
लेकिन अभी भी कई स्थितियां हैं जिनमें प्रधान मंत्री हब से अलग हो सकते हैं, और स्थिति को ठीक करने के लिए, आपको कई अतिरिक्त इशारों को करने की आवश्यकता होगी। यदि हम प्राइम पर कुछ सही कर रहे हैं और बदलाव नहीं किए हैं, और इस समय हब में
पोस्ट-अपडेट काम करेगा, तो "एंट्री 'फू' न अपटूडेट संदेश के साथ एक त्रुटि के साथ सब कुछ समाप्त हो जाएगा। विलय नहीं किया जा सकता है। " प्राइम वर्किंग डायरेक्टरी में बदलाव करने से इसकी स्थिति साफ हो जाएगी और
पोस्ट-अपडेट हुक सभी असंतुलित परिवर्तनों को मर्ज करने में सक्षम होगा।
मैंने यह भी पाया कि यदि कोई विरोध उत्पन्न होता है क्योंकि प्राइम में परिवर्तन हब के साथ विलय नहीं किया जा सकता है, तो सबसे अच्छा समाधान यह होगा कि हब पर एक नई शाखा में प्राइम की वर्तमान स्थिति को धक्का दिया जाए। प्राइम वर्किंग डाइरेक्टरी से निष्पादित यह कमांड, प्राइम रिपॉजिटरी की वर्तमान स्थिति के आधार पर एक रिमोट फिक्समे ब्रांच बनाएगी।
$ git push hub master:refs/heads/fixme
जैसे ही परिवर्तन हब में होते हैं, हम किसी भी क्लोन में एक शाखा प्राप्त कर सकते हैं, संघर्ष को हल कर सकते हैं और शाखाओं को पकड़ सकते हैं। सर्वर पर सीधे संघर्ष को हल करने का प्रयास निश्चित रूप से साइट में संघर्ष मार्करों की उपस्थिति के कारण समस्याओं को जन्म देगा।
सब कुछ साफ रखें
.It प्राइम रिपॉजिटरी डायरेक्टरी साइट की रूट डायरेक्टरी में स्थित है, और पब्लिक एक्सेस के लिए उपलब्ध है। ताकि कोई भी अपनी नाक न चिपका सके जहाँ उन्हें नहीं करना चाहिए, इन पंक्तियों को शीर्ष-स्तर
.htaccess फ़ाइल में जोड़ें:
# deny access to the top-level git repository:
RewriteEngine On
RewriteRule \.git - [F,L]
लगभग। अनुवादक: सर्वर पर निर्देशिका तक पहुंच को अवरुद्ध करने के अन्य तरीके हैं।अन्य समस्याएं
यदि आप सर्वर पर रिपॉजिटरी को पुश करने की कोशिश करते हैं, तो आपको यह त्रुटि दिखाई देती है:
git-receive-pack: command not found
fatal: The remote end hung up unexpectedly
इस स्थिति में, बस अपने
export PATH=${PATH}:~/bin को अपने
.bashrc फ़ाइल में जोड़ें जो सर्वर पर है।