2009-05-17 12 views
8

का उपयोग कर डीजेगो परियोजनाओं का विकास करना मुझे आश्चर्य है कि क्या किसी को गिट स्रोत नियंत्रण प्रबंधन का उपयोग करके एक छोटी टीम (मेरे मामले में 3) में Django परियोजनाओं पर काम करने का अनुभव है।गिट

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

हम इस परियोजना पर काम करते समय एक-दूसरे के पैर की उंगलियों पर चलना शुरू कर रहे हैं, इसलिए किसी प्रकार का संस्करण नियंत्रण आवश्यक है - लेकिन मैं बस एक समाधान नहीं समझ सकता।

यदि किसी ने भी इसी तरह की समस्या को पार कर लिया है तो मुझे यह सुनना अच्छा लगेगा कि यह कैसे किया जा सकता है।

उत्तर

12

रिमोट रिपोजिटरी को दबाते समय, सर्वोत्तम परिणाम तब होते हैं जब रिमोट रिपोजिटरी कोई "नंगे" भंडार नहीं है जिसमें कोई कार्यशील निर्देशिका नहीं है। ऐसा लगता है कि आपके पास रिमोट रिपोजिटरी पर एक कार्यशील निर्देशिका है, जिसे पुश करते समय गिट द्वारा अपडेट नहीं किया जाएगा।

आपकी स्थिति के लिए, मैं अनुशंसा करता हूं कि डेवलपर्स का अपना परीक्षण वातावरण होगा कि वे कहीं भी अपने कोड को धक्का देने से पहले स्थानीय रूप से परीक्षण कर सकते हैं। एक केंद्रीय स्थान होने पर जहां सभी को से भी पहले अपने काम को धक्का देने की आवश्यकता है, इससे बहुत दर्द और पीड़ा हो जाएगी।

परिनियोजन के लिए, मैं एक केंद्रीय "नंगे" भंडार को धक्का देने की अनुशंसा करता हूं, फिर एक प्रक्रिया है जहां परिनियोजन सर्वर केंद्रीय भंडार से नवीनतम कार्य कोड को खींचता है।

+3

+1 गिट-अपडेट-रिमोट-वर्किंग-पेड़ एक साइड इश्यू नहीं है। डेवलपर्स को बस एक स्थानीय कामकाजी परीक्षण सेटअप होना चाहिए (ईमानदारी से, SQLite के साथ और django dev सर्वर यह कठिन नहीं है)। –

+0

क्या आप संभावित रूप से मेरे जैसे Django newbies के लिए अनुशंसित विकास वर्कफ़्लो सेट अप करने के संसाधनों से लिंक कर सकते हैं? –

3

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

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

हालांकि, मैं कहूंगा कि मुझे लगता है कि आपकी प्रक्रिया में सुधार किया जा सकता है। डेवलपर्स को आम तौर पर व्यक्तिगत सर्वर की आवश्यकता होती है कि वे एक साझा बिंदु पर धक्का देने से पहले परीक्षण कर सकते हैं: अन्यथा साझा रेपो को अविश्वसनीय रूप से अविश्वसनीय होने की संभावना है। गौर करें, अगर मैं इसमें बदलाव डालता हूं और यह काम नहीं करता है, तो क्या यह मेरा परिवर्तन है जो इसे तोड़ देता है या किसी और का दुष्प्रभाव है?

ठीक है, मैं एक के बाद अद्यतन हुक के रूप में इस का उपयोग करें:

#!/bin/sh 
# Should be run from a Git repository, with a set of refs to update from on the command line. 
# This is the post-update hook convention. 

info() { 
    echo "post-update: [email protected]" 
} 

die() { 
    echo "post-update: [email protected]" >&2 
    exit 1 
} 

output_dir=.. 
for refname in "[email protected]"; do 
    case $refname in 
     refs/heads/master) 
      new_tree_id=$(git rev-parse $refname:ui) 
      new_dir="$output_dir/tree-$new_tree_id" 
      if [ ! -d "$new_dir" ]; then 
       info "Checking out UI" 
       mkdir "$new_dir" 
       git archive --format=tar $new_tree_id | (cd $new_dir && tar xf -) 
      fi 
      prev_link_target=$(readlink $output_dir/current) 
      if [ -n "$prev_link_target" -a "$prev_link_target" = "tree-$new_tree_id" ]; then 
       info "UI unchanged" 
      else 
       rm -f $output_dir/current 
       ln -snf "tree-$new_tree_id" "$output_dir/current" 
       info "UI updated" 
       title=$(git show --quiet --pretty="format:%s" "$refname" | \ 
        sed -e 's/[^A-Za-z][^A-Za-z]*/_/g') 
       date=$(git show --quiet --pretty="format:%ci" "$refname" | \ 
        sed -e 's/\([0-9]*\)-\([0-9]*\)-\([0-9]*\) \([0-9]*\):\([0-9]*\):\([0-9]*\) +0000/\1\2\3T\4\5\6Z/') 
       ln -s "tree-$new_tree_id" "$output_dir/${date}__${title}" 
      fi 
      ;; 
    esac 
done 

के रूप में उल्लेख किया है, यह सिर्फ "ui" उपनिर्देशिका बाहर की जाँच करता है। यह ": ui" बिट सेटिंग new_tree_id है। सबकुछ जांचने के लिए बस ": ui" बाहर निकालें (या "^ {tree}" में बदलें)।

चेकआउट गिट रेपो युक्त निर्देशिका में जाते हैं, output_dir द्वारा नियंत्रित। स्क्रिप्ट को गिट रेपो के अंदर दौड़ने की उम्मीद है (जो बदले में नंगे होने की उम्मीद है): यह बहुत साफ नहीं है।

चेकआउट को "पेड़-XXXX" निर्देशिकाओं में रखा गया है और "वर्तमान" सिम्लिंक सबसे हाल ही में इंगित करने में कामयाब रहा है। यह एक से दूसरे परमाणु में परिवर्तन करता है, हालांकि यह इतना लंबा समय लगता है कि यह महत्वपूर्ण है।इसका मतलब यह भी है कि पुरानी फाइलों का पुन: उपयोग करें। और इसका मतलब यह भी है कि यह डिस्क स्पेस को चबाता है क्योंकि आप संशोधन को दबाते रहते हैं ...

0

एक ही समस्या थी, जो django के साथ भी काम कर रही थी।

तैनाती से पहले स्थानीय रूप से परीक्षण करने के लिए सहमत हैं, जैसा कि पहले से ही उल्लेख किया गया है।

फिर आप स्थानीय संस्करण को सर्वर पर एक नई शाखा में धक्का दे सकते हैं। फिर आप इस शाखा और मास्टर के साथ विलय करते हैं। इसके बाद आप अपडेट की गई फाइलें देखेंगे।

यदि आप गलती से मास्टर शाखा में धकेल गए हैं, तो आप एक गिट रीसेट कर सकते हैं - हार्ड। हालांकि वर्तमान कार्यशील शाखा में आने वाले सभी परिवर्तन खो जाएंगे। तो अपना ख्याल रखना।