फ्लैश विकास में गिट का उपयोग करना

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

सबसे पहले, मैं परिवर्धन और सुधार के साथ खुश रहूंगा। और निश्चित रूप से मुद्दों।

Git क्या है

git एक वितरित संस्करण नियंत्रण प्रणाली है। यह केंद्रीय भंडार (जो अभी भी रखने के लिए अच्छा होगा) और शाखाओं के साथ काम करने में आसानी के अभाव में एसवीएन से भिन्न होता है। प्रारंभ में, मैंने इस लेख को पढ़ने के बाद अपने काम में इसे आज़माने का फैसला किया, जिसकी मैं सभी को सलाह देता हूँ।

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

क्यों git

हम सभी समझते हैं कि एक संस्करण नियंत्रण प्रणाली का उपयोग करना महत्वपूर्ण है। रोजमर्रा के उपयोग में गिट बहुत अच्छी साबित हुई और कई समस्याओं को हल करने की अनुमति दी गई। मैं मुख्य लाभ और "चिप्स" दूंगा।

1. वितरित
   आप केवल लिखकर एक स्थानीय फ़ोल्डर में एक रिपॉजिटरी बना सकते हैं
2. स्थिर ग्राहक होना
   ब्रांचिंग के बिना विकास की प्रक्रिया कुछ इस तरह दिखती है: संस्करण ... विकास ... संस्करण ... विकास ...
   यह देखा जा सकता है कि हर समय एक स्थिर संस्करण की उपलब्धता जिस पर आप बग को ठीक कर सकते हैं और रिलीज की गारंटी नहीं है। अधिक सटीक रूप से, यह पता चला है कि आप वर्तमान संस्करण के विकास को पूरा करने के बाद ही एक निश्चित पकड़ा बग को ठीक कर सकते हैं। जीआईटी में सरल शाखाएं आपको किसी भी समय किसी भी पिछले रिलीज के संस्करण को प्राप्त करने की अनुमति देती हैं और चल रहे विकास में हस्तक्षेप किए बिना इसके साथ काम करती हैं। एक अलग शाखा में कीड़े को ठीक करें, उन्हें पिछले रिलीज में और वर्तमान विकास में रखें।
3. उपयोग की सरलता
   git अपना सारा डेटा एक डायरेक्टरी में स्टोर करता है, और हर जगह .svn फोल्डर को स्पॉन नहीं करता है। आप केवल एक टीम या क्लाइंट में कुछ क्लिक के साथ एक परियोजना को दूसरी शाखा में बदल सकते हैं। इस स्थिति में, प्रोजेक्ट फ़ोल्डर की सामग्री को एक नए के साथ बदल दिया जाता है जो चयनित शाखा से मेल खाती है। विभिन्न शाखाओं के लिए, आपको नए फ़ोल्डर या प्रोजेक्ट बनाने की आवश्यकता नहीं है। ज्यादातर मामलों में, फ्लैश बिल्डर सभी वर्गों को अपडेट करेगा और निर्भरता को फिर से बढ़ाएगा।
4. केंद्रीय भंडारण के लिए कोई स्थायी कनेक्शन की जरूरत नहीं है
   जैसा कि मैंने कहा, सभी कमिट स्थानीय रूप से सहेजे जाते हैं और सामान्य रिपॉजिटरी का हिस्सा बन जाते हैं, जब वे सीधे इसमें धकेल दिए जाते हैं। यह कल्पना करना मुश्किल है, लेकिन कभी-कभी यह पता चलता है कि इंटरनेट एक्सेस नहीं है, लेकिन आपको काम करने की आवश्यकता है। या, हमेशा की तरह, आप वीपीएन को काम करने वाले भंडार में कॉन्फ़िगर करना भूल गए। आवागमन की गति और स्थानीय प्रति पर पूर्ण नियंत्रण की भावना उत्साहजनक है।
5. सुविधाजनक आंशिक कमिट
   सीधे तौर पर कमिट से पहले, git add का उपयोग करके इसमें दर्ज की गई फाइलों को चिह्नित किया जाएगा। इसी समय, पूरी फ़ाइल के बजाय फ़ाइल में परिवर्तनों का हिस्सा अलग-अलग प्रतिबद्ध में करना संभव है।
6. परिवर्तन को छिपाने की क्षमता।
   गिट में एक दिलचस्प अवसर है - अप्रकाशित फ़ाइलों को छिपाने (छिपाने) के लिए और फिर उन्हें फिर से प्राप्त करें। कभी-कभी इस तरह से परिवर्तनों को स्थानांतरित करना या अस्थायी रूप से वापस करना उपयोगी होता है, उदाहरण के लिए, मैं अक्सर शाखाओं को स्विच करना भूल जाता हूं।
7. चित्रमय ग्राहकों की उपलब्धता।
   गिट के लिए ग्राफिकल क्लाइंट का इतना बड़ा चयन नहीं है। मुझे SmartGit GUI क्लाइंट सबसे ज्यादा पसंद आया। यह क्रॉस-प्लेटफॉर्म है और गैर-व्यावसायिक उपयोग के लिए नि: शुल्क उपलब्ध है। इसमें सभी आवश्यक कार्य हैं, लेकिन फिर भी कभी-कभी आपको टर्मिनल में जाने और कुछ जोड़े आदेशों को निष्पादित करने की आवश्यकता होती है। उन्हें छांटना अच्छा होगा। विंडोज के लिए टोर्टोइजीगिट है , मैक पर मैंने कुछ समय के लिए GitX का इस्तेमाल किया था, लेकिन तब यह Smartitit से बहुत खराब था। ग्रहण के लिए (अर्थात फ़्लैश बिल्डर के लिए) एक ईजीट प्लगइन है जिसे मैं लंबे समय तक पसंद नहीं करता। इसे फिर से वापस करने के लिए आवश्यक होगा, खासकर जब से यह अभी अपडेट किया गया है। शायद यह एक ग्राहक सुविधा नहीं है, लेकिन गिट वितरण का हिस्सा है, लेकिन फिर भी, मैं शाखाओं के एक और शांत प्रदर्शन का उल्लेख करना चाहता हूं। एक जटिल परियोजना में, यह न्यूयॉर्क मेट्रो के नक्शे जैसा दिखता है। मुझे ऐसी अमूर्त तस्वीरें बहुत पसंद हैं।

TODO या और क्या जाँच करें

मैंने कभी भी git-svn को स्थापित करने और git रिपॉजिटरी को अपनी svn प्रतियों के साथ संयोजित करने की जहमत नहीं उठाई, क्योंकि हमारी कंपनी आधिकारिक तौर पर svn का उपयोग करती है, लेकिन हम इसे अब और नहीं खड़ा कर सकते। मुझे उम्मीद है कि हर कोई आखिरकार गिट में बदल जाएगा और इसकी आवश्यकता नहीं होगी।

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

स्थापना और सेटअप

Git। मैक / लिनक्स


सबसे पहले आपको खुद को गिट स्थापित करने की आवश्यकता है। लिनक्सइड्स को इसमें कोई संदेह नहीं होगा कि वे खुद इसे समझेंगे, लेकिन सबसे अधिक संभावना है कि वे पहले से ही इसे स्थापित कर चुके हों। Macware आधिकारिक वेबसाइट से वितरण किट डाउनलोड कर सकता है या MacPorts के माध्यम से स्थापित कर सकता है। MacPorts कैसे स्थापित करें यह भी पता लगाना मुश्किल नहीं है।

MacPorts में, टर्मिनल खोलें और दर्ज करें।

sudo port

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

list git*

स्क्रीन पर कुछ इस तरह दिखाई देगा।

git-core @1.7.2.1 devel/git-core
GitX @0.7.1 devel/GitX

GitX एक GUI क्लाइंट है जिसके बारे में मैंने पहले ही लिखा था। हम गिट-कोर में रुचि रखते हैं। इसे स्थापित करने के लिए, आपको लिखना होगा

install git-core

आप कंसोल में git --version लिखकर इंस्टॉलेशन को सत्यापित कर सकते हैं।

दूरस्थ रिपॉजिटरी तक पहुंचने के लिए आपको एसएसएच कुंजी की आवश्यकता होगी। मैक पर इसे उत्पन्न करना कोई समस्या नहीं है।

Git। विंडोज

विंडोज के लिए एक msysgit port है। नवीनतम संस्करण डाउनलोड करें और इंस्टॉल करें।
Git शुरू में विंडोज के लिए विदेशी है। इससे कुछ समस्याएं हो सकती हैं। उदाहरण के लिए, कुछ समय के लिए हम दूरस्थ रिपॉजिटरी के साथ काम करने के लिए इसे प्राप्त नहीं कर सके। SSH कुंजी पर शपथ लें। इस समस्या को हल करने के लिए GitHub का धन्यवाद। तो, पोटीन का उपयोग करके कुंजी उत्पन्न करने का प्रयास न करें। आपको आवश्यक सही कुंजी उत्पन्न करने के लिए:

1. लॉन्च बैश कंसोल को स्टार्ट -> प्रोग्राम्स -> गिट से लॉन्च करें
2. कुंजी जेनरेट करने के लिए ssh-keygen -t rsa -C "your@email.com" चलाएं

जीयूआई ग्राहक

अब मेरे पसंदीदा स्मार्टगिट को रखो । यह बहुत अच्छा है कि यह क्रॉस-प्लेटफॉर्म है।

स्मार्टगिट की स्थापना के दौरान, अगर इसे .gitconfig फ़ाइल नहीं मिलती है, तो यह एक नाम और ई-मेल के लिए पूछेगा, जिसका उपयोग कमिट के बारे में जानकारी में किया जाएगा।

लाइन टूट गई

विभिन्न ऑपरेटिंग सिस्टमों से गिट रिपॉजिटरी के साथ काम करते समय, जल्दी या बाद में (बेहतर जल्दी) आप लाइन ब्रेक की समस्या का सामना करते हैं। समुदाय में आम सहमति नहीं है, लेकिन GitHub निम्नलिखित सेटिंग्स की सिफारिश करता है :

1. एक रिपॉजिटरी बनाना बेहतर है विंडोज मशीन से नहीं
2. लिनक्स और मैक पर, core.autocrlf को इनपुट पर सेट करें
3. विंडोज पर, core.autocrlf को true पर सेट करें

यह या तो git config --global core.autocrlf true या edit .ITconfig द्वारा किया जाता है। वहां आपको जोड़ना होगा

[core]
autocrlf = true

इन सेटिंग्स के साथ, मैक उपयोगकर्ता LF लाइन ब्रेक के साथ काम करेंगे और रिपॉजिटरी के लिए LF प्रतिबद्ध करेंगे, जबकि Windows उपयोगकर्ता सामान्य CRLF के साथ काम करेंगे, लेकिन LF।

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

किसी मौजूदा परियोजना का अनुवाद

यह विधि SVN इतिहास का एक पूर्ण नुकसान मानती है। शुरुआत, खरोंच से बोलने के लिए।

.Svn फ़ोल्डर्स से छुटकारा पाने के लिए svn export प्रोजेक्ट बनाएं। या, प्रोजेक्ट के रूट पर, find ./ -name ".svn" | xargs rm -Rf चलाएं find ./ -name ".svn" | xargs rm -Rf

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

भावी गिट रिपॉजिटरी के साथ एक निर्देशिका में, मैं तुरंत निम्नलिखित सामग्री के साथ एक .gitignore फ़ाइल बनाने की सलाह देता हूं:

bin
bin-debug
bin-release

यह बताता है कि संकलित प्रोजेक्ट बायनेरिज़ को रिपॉजिटरी में शामिल नहीं करना है।

अगला, स्मार्टगिट लॉन्च करें, एक मौजूदा खोलें चुनें या एक नया स्थानीय गिट वर्किंग ट्री बनाएं और प्रोजेक्ट के साथ फ़ोल्डर निर्दिष्ट करें। स्मार्टगिट इसमें एक नया भंडार बनाएगा।

तुरंत आपको सूची में .gitignore फ़ाइल खोजने की आवश्यकता है, इसे चुनें, स्टेज और कमिट बटन पर क्लिक करें। पहले प्रतिबद्ध संदेश को "प्रारंभिक प्रतिबद्ध" जैसा कुछ होने दें। अब, यदि आप निर्देशिका की वर्तमान स्थिति को ओवरराइड करते हैं, तो .ITignore में उल्लिखित सभी फाइलें गायब हो जाती हैं। आपको उनकी जरूरत नहीं है। अन्य सभी फ़ाइलों का चयन करें, स्टेज, कमिट करें, कमिट विंडो में बॉक्स को चेक करें। पूर्वगामी कमिट करें ..., जिससे नई कमिट के बजाय, आप वर्तमान परिवर्तन को पिछले एक में जोड़ देंगे (आपको बहुत सारे संदेश दिखाई दे सकते हैं CRLF को LF से बदल दिया जाएगा ... - इसका मतलब है सेटिंग्स के बाद git उन फ़ाइलों के लाइन सिरों को बदल देता है जिन्हें रिपॉजिटरी में सही LF में जोड़ा जाता है)।

बधाई हो, अब आपके पास अपनी खुद की गिट रिपॉजिटरी है।

यदि आपने अचानक सही लाइन ब्रेक सेटिंग सेट करने से पहले एक रिपॉजिटरी बनाई है, तो GitHub निर्देशों का पालन करें और निम्न स्क्रिप्ट चलाएँ:

# Remove everything from the index
$ git rm --cached -r .

# हटाए गए सभी फ़ाइलों को इंडेक्स में पुनः जोड़ें
# आपको बहुत सारे संदेश प्राप्त होने चाहिए जैसे: "चेतावनी: CRLF को LF द्वारा <file> में बदल दिया जाएगा।"
$ git diff --cached --name-only -z | xargs -0 गिट जोड़

# कमेटी
$ git कमिट-मी "CRLF फिक्स"

# यदि आप एक यूनिक्स / मैक ओएसएक्स क्लोन पर ऐसा कर रहे हैं तो वैकल्पिक रूप से हटा दें
# काम करने वाले पेड़ और सही लाइन एंडिंग के साथ सब कुछ फिर से जांचें।
$ git ls-files -z | xargs -0 rm
$ गिट चेकआउट।

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

प्रोजेक्ट के साथ काम करें

यदि आपने इस लेख को नहीं पढ़ा है, तो मैं इसे अभी करने की सलाह देता हूं, क्योंकि नीचे वर्णित गिट में एक परियोजना के साथ काम करने की प्रक्रिया लगभग पूरी तरह से वहां से ली गई है। इस लेखन के समय, मैं अभी भी Mail.ru पर काम कर रहा हूं और फ्लैश पर सामाजिक गेमिंग क्लाइंट लिख रहा हूं। इसलिए कुछ विशेष।

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

• मास्टर - मुख्य शाखा में केवल रिलीज़ संस्करण हैं जो अब ऑनलाइन हैं। उन्हें एक भरने की तारीख के साथ टैग किया गया है। मैंने कुछ सूचनात्मक संस्करण संख्याओं को अस्वीकार कर दिया है। यदि अचानक युद्धक सर्वर पर कुछ टूट जाता है, तो हम बिना किसी समस्या के मास्टर पर स्विच करते हैं, उससे एक शाखा बनाते हैं, बग को ठीक करते हैं और इसे वापस पकड़ते हैं (प्लस दूसरी शाखा, ताकि बाद में हम उसी बग को ठीक न करें)
• विकास मुख्य विकास शाखा है। विकास की स्थिर स्थिति को दर्शाता है, जो भविष्य में कुछ समय के लिए जारी हो जाएगा और मास्टर में आयोजित किया जाएगा।
• देव- * - व्यक्तिगत विशेषताओं के लिए शाखाएँ। उनमें से कई स्थानीय हैं और मुख्य भंडार में नहीं आते हैं। वे खेल की विशिष्ट नई विशेषताओं को विकसित कर रहे हैं। यह एक या दो कमिट के लिए बहुत छोटे बदलाव हो सकते हैं, या यह एक बड़ा पैच हो सकता है जो एक या अधिक महीने तक बढ़ता है।
• fix- * - अत्यावश्यक सुधारों की स्थानीय शाखाएँ। आमतौर पर मास्टर से दिखाई देते हैं, कम अक्सर विकास से। एकदम सही जगहों पर चले जाओ।
• रिलीज एक अस्थायी रिलीज शाखा है जो मास्टर में विलीन हो जाएगी और हटा दी जाएगी। सही समय पर, यह विकसित होने के साथ ब्रंच करता है, और भरने से पहले इसमें आवश्यक बदलाव किए जाते हैं।

ऑपरेशन एल्गोरिथ्म इस प्रकार है:

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

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

जिन समस्याओं का मुझे सामना करना पड़ा

बेशक, सब कुछ उतना सही नहीं है जितना आप सोच सकते हैं। आत्मज्ञान के रास्ते पर, मुझे अभी भी रेक को छूना था, जिसे मैं नीचे लिखूंगा। शायद यह जानकारी किसी के लिए उपयोगी हो।

1. व्यवस्थापन प्रतिरोध
   कई बार मैंने यह समझाने की कोशिश की कि हमें एक और संस्करण नियंत्रण प्रणाली की आवश्यकता क्यों है, क्योंकि एक उत्कृष्ट एसवीएन प्रतीत होता है। Admins ने शिकायत की कि git नेटवर्क पर संसाधनों के अधिकारों और अभिगम नियंत्रण के मौजूदा सिस्टम को एकीकृत करना मुश्किल है। यह व्यवसाय नहीं हिलता था, मुझे "स्थानीय रूप से केंद्रीय भंडार रखना" था।
2. सहकर्मियों का प्रशिक्षण
   सहकर्मियों को एक नया संस्करण नियंत्रण प्रणाली पर स्विच करने के लिए मजबूर करना पड़ा, यह समझने के लिए कि यह सामान्य एसवीएन से कैसे भिन्न होता है, और यह जानने के लिए कि नए सॉफ़्टवेयर का उपयोग कैसे किया जाए। वास्तव में कुछ भी जटिल नहीं है, लेकिन आपको बाद में चल रहे मुद्दों के लिए तैयार रहने की आवश्यकता है।
3. लाइन लपेटें समस्या
   मैंने पहले ही समस्या और इसके समाधान के बारे में ऊपर लिखा था, लेकिन चूंकि इसने विशेष रूप से कुछ समय के लिए मेरे मस्तिष्क को बाहर किया, इसलिए मैं इसके बारे में "समस्याओं" खंड में नहीं लिख सका। केवल एक शाखा होने पर परियोजना की शुरुआत में लाइन ब्रेक को ठीक करना बहुत महत्वपूर्ण है । फिर यह एक ठोस सिरदर्द में बदल जाएगा।
4. हाथ से w ...
   यूनिक्स जैसी प्रणालियों और कमांड लाइन के लिए, यहां मेरे हाथ गलत जगह से स्पष्ट रूप से बढ़ते हैं। मैक पर कुछ समय के लिए केंद्रीय रिपॉजिटरी होने के नाते, मुझे लगातार इस तथ्य से संबंधित निम्न समस्याओं का सामना करना पड़ा कि शुरुआत से ही मैंने सब कुछ सही ढंग से कॉन्फ़िगर नहीं किया है: लॉक की गई फाइलें और फ़ाइल के मालिक। किसी तरह गिट रिपॉजिटरी फाइलें लॉक हो गईं। वे खुद भी जड़ से उखड़ना नहीं चाहते थे। Google ने एक ऐसी स्क्रिप्ट के लिए संकेत दिया, जो एक निर्देशिका में फ़ाइलों को पुनर्संयोजित करता है। साथी डेवलपर्स से मुझे धकेलने के बाद, कुछ फाइलें बिना किसी स्वामित्व के पारित हो गईं, जिसके कारण भंडार का पूर्ण रूप से निष्क्रिय हो गया। मुझे हर बार निर्देशिका को पुन: सेट करना था, टाइप करें, sudo chmod -R 777 /users/valyard/Work/work/Panda/.git/
sudo chmod -R 777 /users/valyard/Work/work/Panda/.git/

   अंत में, मैंने एक स्क्रिप्ट लिखी, जिसने सभी परियोजनाओं पर इन दो चीजों को किया, और समय-समय पर इसे चलाया।
5. एक नज़र डालें कि रिपॉजिटरी में क्या जाता है और क्या नहीं
   बेशक, संकलित बायनेरिज़ और ग्राफिकल परिसंपत्तियों को तुरंत .gitignore में जोड़ने की आवश्यकता है। जंक को असेंबल करने के लिए हमारे प्रोजेक्ट में एक एंटी स्क्रिप्ट है और यह विभिन्न मशीनों पर थोड़ा अलग है। शायद यह भी इसे जोड़ने के लायक था, लेकिन मैंने सिर्फ दो अलग-अलग स्क्रिप्ट बनाईं: विंडोज के लिए और खसखस ​​के लिए।
6. कष्टप्रद परियोजना फ़ाइलें
   किसी कारण के लिए, प्रोजेक्ट मेटाडेटा में समय-समय पर फ्लैश बिल्डर इसे ऊपर से नीचे की ओर आधे लाइनों को स्थानांतरित करने के लिए अपना कर्तव्य मानता है, इससे कुछ भी उपयोगी नहीं होता है, लेकिन परिवर्तन प्रदर्शित करते समय कष्टप्रद। लेकिन, फिर भी, मैं परियोजना फाइलों को एक बुरा विचार नहीं मानता।
7. WIndows पर SSH कुंजी उत्पन्न करने की समस्या
8. कंसोल को फ़्लैशर्स का अनुवाद
   जैसा कि यह निकला, फ्लैशर्स कंसोल में काम करना पसंद नहीं करते हैं। और GUI क्लाइंट केवल गिट कार्यक्षमता का एक छोटा सा हिस्सा प्रदान करते हैं। कभी-कभी आपको किसी प्रकार के ऑपरेशन को और अधिक जटिल करने के लिए कमांड लाइन में चढ़ना पड़ता है।

उपयोगी टिप्स

अंत में कुछ शब्द।

1. सुनिश्चित करें कि आप git और svn के बीच अंतर को समझते हैं।
2. इसे अधिकारियों तक पहुंचाने की कोशिश करें।
3. एक व्यक्ति को ढूंढें जो मुख्य गिट रिपॉजिटरी को सही ढंग से कॉन्फ़िगर कर सकता है।
4. फिर भी, टीम में एक ही आईडीई का उपयोग करने का प्रयास करें, फिर आप प्रोजेक्ट फ़ाइलों को प्रतिबद्ध कर सकते हैं।
5. प्रोजेक्ट को कई रिपॉजिटरी में विभाजित करें।
6. कमिट करें और अधिक बार मर्ज करें, फिर भी गिट जैसे शांत उपकरण स्वचालित रूप से कमिट के दो महीने के इतिहास के साथ दो शाखाओं को मर्ज नहीं कर सकते हैं। मैन्युअल रूप से पोक बटन बैठना होगा।
7. मेरी गलतियों को मत दोहराओ।
8. जो गालियां बकते हैं, उनकी बात मत सुनो।

उपयोगी लिंक

• मैक ओएस पर गिट पब्लिक सर्वर स्थापित करें
• हम जिस डिज़ाइन मॉडल पर काम कर रहे हैं
• उपयोगी संसाधन
• ग्रेट प्रो गिट बुक
• स्मार्टगिट मेरा पसंदीदा जीयूआई क्लाइंट है
• हैबे पर सुपर लेख और वहां से एक उत्कृष्ट गाइड

परिणाम

लेकिन फिर भी, सभी विपक्ष विशाल प्लसस द्वारा अवरुद्ध कर दिए गए थे। वहाँ क्षणों जब मैं क्या अभी भी Git परियोजना के लिए अनुवाद किया है के लिए उसे गधे को चूमने के लिए तैयार हो गया था रहे थे, और आप क्या चाहते हैं (बेशक, मेरे गधे को चूम नहीं है, और Git में परियोजना का अनुवाद)!

पुनश्च प्रश्न।

1. मुख्य शाखा (मास्टर) के साथ विलय को कैसे और कौन नियंत्रित करता है और क्या इस तरह के संचालन के लिए शक्तियों के परिसीमन के लिए एक तंत्र है?
   परियोजना पर मुख्य फ्लैशर को नियंत्रित करता है। अपनी परियोजनाओं में मैं इसे करता हूं। जीआईटी स्तर पर, मुझे पता नहीं है कि उपलब्ध कार्यों के बीच कोई अंतर है या नहीं।