मैं विभिन्न सर्वरों से कोड आधारों के लिए Git का उपयोग कैसे शुरू करूं?

Question

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

इसलिए अब मुझे तीन सर्वर प्रोजेक्ट (डेवलपमेंट, स्टेजिंग, प्रोडक्शन) के लायक मिल गए हैं, जिनमें ज्यादातर वेबसाइट्स और एप्लिकेशन और टूल हैं, जो कि हम SQL स्क्रिप्ट और अन्य चीजों के स्टोर के लिए इस्तेमाल किए जाने वाले थर्ड पार्टी ऐप्स और एपीआई के लिए बनाए गए हैं। मेरा पहला विचार यह था कि परिवर्तन और सुधार किए जाने से पहले Git में यह सब प्राप्त करना है, लेकिन मुझे यह करने का सबसे अच्छा तरीका समझ में आ रहा है।

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

प्रश्न: इनको गिट में व्यवस्थित करने और स्थानांतरित करने के लिए मेरे लिए सबसे अच्छा तरीका क्या होगा? कोड में अंतर को समायोजित करने के लिए मैं अपनी रेपो / शाखाओं को कैसे तैयार करूंगा?

मैंने उत्पादन सर्वर कोड के क्लोन से विकास जारी रखने और ऐतिहासिक संदर्भ के रूप में विकास / मचान कोड आधार रखने पर विचार किया है। यह संभावित रूप से शुरू करने के लिए एक बिंदु होगा, यह देखते हुए कि मैं वैसे भी देव / मंचन कोड के बारे में कुछ नहीं जानता हूं? मैं बस प्रत्येक वेबसाइट, टूल, स्क्रिप्ट सेट इत्यादि के लिए उत्पादन सर्वर का रिपोज बना सकता हूं, मौजूदा देव / मंचन कोड के लिए शाखाएं बना सकता हूं, और कोई भी नया विकास उत्पादन सर्वर के कोड बेस से शाखा करेगा। इसका कोई मतलब भी है क्या?

Comments

ताकि आप शुरू करने से पहले सभी डेवलपर्स को छोड़ दें?

— इवान

हाँ; परियोजनाओं के इस विशेष सेट पर केवल तीन डेवलपर्स थे, हालांकि वे इस सामान पर काफी सालों से काम कर रहे थे। मुझे बताया गया था कि वे अचानक चले गए थे और मुझे उनके पीछे आने वाले टुकड़ों को उठाने के लिए लाया गया था।

— user9268966

" Nvie.com/posts/a-successful-git-branching-model " पर एक नज़र डालें, यह अक्सर इस्तेमाल किया जाने वाला मॉडल है।

— पैट्रिक मेव्ज़ेक

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

— पैट्रिक मेव्ज़ेक

जैसा कि मैंने कहा था @RobertHarvey: अक्सर उपयोग किया जाता है , जाहिर है 100% उपयोग के मामलों के लिए समाधान नहीं है, लेकिन यह कम से कम पढ़ने के लिए उपयोगी है कि किस मॉडल का उपयोग करना है। और पिछले डेवलपर्स थे, इसलिए अकेला आदमी हमेशा अकेला नहीं हो सकता ... :-)

— पैट्रिक मेव्ज़ेक

Answer 1

उत्पादन सामग्री को masterएक नए रेपो की शाखा में धकेलें । developउस से एक शाखा बनाएँ , और फिर मचान सर्वर को इसमें मर्ज करें। आप उन विवादों को हवा दे सकते हैं जिन्हें हल करने की आवश्यकता है। एक बार जब वे हल हो जाते हैं, तो दूसरे feature_branchको बनाएं और developउसमें विकास सर्वर को मर्ज करें। उठने वाले किसी भी विवाद का समाधान करें।

यह आपको 3 शाखाओं के साथ छोड़ता है, जो आपके उत्पादन, मंचन और विकास के वातावरण का प्रतिनिधित्व करते हैं। उत्पादन -> master, मंचन -> develop, विकास -> feature_branch। सभी विकास इस प्रकार किया जाता है feature_branchesऔर केवल developशाखा में विलय हो जाता है जब सुविधा की जाती है, परीक्षण किया जाता है, और स्थिर होता है। चूंकि यह स्थिर है, इसलिए इसे मंचन के रूप में इस्तेमाल किया जा सकता है। जब आप रिलीज़ होने के लिए तैयार हों, तब किसी releaseशाखा को काटें develop, किसी भी ढीले सिरे को बाँधें, उसे मर्ज करें master, और फिर आपके पास अपना नया निर्माण होगा।

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

इस मॉडल में, प्रत्येक परियोजना अपने ही रेपो में होगी, और किसी भी कार्य के लिए रेपो की शाखा masterऔर developशाखा होगी feature_branches।

EDIT, टिप्पणियों को संबोधित करने के लिए: हाँ, यह Gitflow है।

यह रणनीति (या सामान्य रूप से Gitflow) मौजूदा 3-स्तरीय प्रणाली (उत्पादन, मंचन, विकास) को विकास से उत्पादन तक एक स्पष्ट मर्ज पथ के साथ रखती है। इस तरह से कोडबेस को आयात करने से उत्पादन में यथास्थिति बनाए रखते हुए शाखाओं को समकालित करने की अनुमति मिलती है - कम से कम, जब तक कि मर्ज का परीक्षण नहीं किया जा सकता है। यह कुछ लक्ष्यों को पूरा करता है: स्रोत नियंत्रण में कोड प्राप्त करता है, अलग-अलग कोडबेस को सिंक और मर्ज किया जाता है (इसलिए उत्पादन में अब बगफिक्स नहीं हैं, लेकिन विकास नहीं है), और आगे बढ़ने के लिए एक अच्छी प्रक्रिया प्रदान करता है (एक प्रक्रिया जो अच्छी तरह से परिभाषित है। और बहुत से लोगों / टीमों / कंपनियों द्वारा उपयोग किया जाता है)। यदि ओपी को पता चलता है कि Gitflow अपनी परियोजनाओं / टीमों / कंपनी के लिए अच्छी तरह से अनुकूल नहीं है क्योंकि वह इसका उपयोग करता है / कंपनी बढ़ती है, तो यह '

---

* आप किसी अन्य सुविधा शाखा को काटने और किसी भी स्पष्ट नई सुविधाओं को निकालने की इच्छा कर सकते हैं, और उस शाखा को develop(और फिर master) में विलय कर सकते हैं । यह आपको उन सभी अन्य परीक्षणों के शीर्ष पर नई विशेषताओं का परीक्षण करने से रोकता है जो आप कर रहे हैं।

Comments

GitFlow की तरह लगता है।

— रॉबर्ट हार्वे

यह एक कार्गो पंथ का उत्तर है। प्रश्न में बताई गई समस्या को हल करने में gitflow कैसे विशेष रूप से मदद करेगी?

— श्री कोच

@ मेकॉच मेरा संपादन देखें

— एमएमथिस

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

— user9268966

Answer 2

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

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

तो, अपने stagingकोड को एक stagingशाखा में जांचें , फिर git checkout -b master stagingअपनी masterशाखा बनाने के लिए एक करें , और वहां अपना उत्पादन कोड जांचें। फिर git checkout -b development stagingअपनी developmentशाखा बनाने के लिए , और वहां अपने विकास कोड की जांच करें।

अब आप अपने की जाँच developmentशाखा और विलय master में यह। यह आपको मर्ज संघर्षों की संभावित बड़ी मात्रा को हल करने देगा जबकि अभी भी masterउत्पादन में वास्तव में क्या है, के रिकॉर्ड के रूप में बनाए रखेगा । developmentअब हर वातावरण से सभी परिवर्तन शामिल हैं। अब आप जो भी ब्रांचिंग मॉडल आपको सबसे अच्छा लगता है उस पर स्विच कर सकते हैं।

Answer 3

इतिहास रखना अच्छा है। मैं सबसे स्थिर वातावरण से रिपॉजिटरी (या प्रत्येक उत्पाद के लिए एक) बनाऊंगा। दूसरों के लिए शाखाएँ बनाएँ या अलग करें।

उच्च स्तर पर:

1. एक नया रेपो बनाएं
2. उत्पादन-आधारित कार्य प्रतिलिपि से: सभी को जोड़ें, कमिट करें, और पुश करें
3. एक नई निर्देशिका के लिए चेकआउट मास्टर
4. प्रत्येक अतिरिक्त वातावरण के लिए XYZ
   1. शाखा बनाएँ Archive-XYZ
   2. XYZस्रोत के साथ सब कुछ बदलें (.it को छोड़कर)
   3. सभी को जोड़ें, कमिट करें, और पुश करें

वैकल्पिक रूप से, यदि आप git diff > XYZ.diffवास्तव में कमिट और पुश करने के बजाय इसके मूल्य के बारे में संदेह करते हैं , और फ़र्क को अलग करते हैं।

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