गितुब विकास चक्र

डिज़ाइन

मैं गितुब के माध्यम से विकास चक्र के बारे में बात करूंगा, जिसका मैं उपयोग करता हूं। यह विभिन्न आकारों की टीमों पर वर्ष के दौरान परीक्षण किया गया था: 3 से 14 लोग।

2 मुख्य शाखाएँ हैं: गुरु और देव ।

मास्टर एक स्थिर शाखा है, जो किसी भी समय उत्पादन सर्वर के लिए तैयार होने के लिए तैयार है।

देव वह शाखा है जिस पर वर्तमान में टीम काम कर रही है।

इसलिए, विकास की शुरुआत में, मास्टर और देव शाखाएं समान हैं।



1. जब प्रोग्रामर एक नए दोष / कार्य पर काम करना शुरू करता है, तो उसे देव शाखा में स्विच करना चाहिए और उसका नवीनतम संस्करण प्राप्त करना चाहिए।

git checkout dev git pull origin dev 

2. उदाहरण के लिए, एक डेवलपर प्रमाणीकरण पृष्ठ दोष को ठीक करना शुरू करना चाहता है। गितुब पर त्रुटि संख्या 1234 है। डेवलपर को देव से एक नई शाखा बनानी चाहिए

 git checkout -b 1234-bug-login 

1234-बग-लॉगिन केवल एक उदाहरण है। पहला शब्द दोष की संख्या, दूसरा बग / फीचर होना चाहिए, और फिर समस्या का वर्णन होना चाहिए।

3. इसके अलावा, डेवलपर स्थानीय रूप से काम करना जारी रखता है: परिवर्तन करता है, कमिट करता है, आदि। प्रतिबद्ध संदेशों में त्रुटि संख्या और तकनीकी विवरण होना चाहिए

 git add ...list of files... git commit -m "#1234 changing backbone model url" 

4. इसलिए, विकास समाप्त हो गया है, और अब आपको गितुब में परिवर्तन प्रस्तुत करने की आवश्यकता है

 git push origin 1234-bug-login 

सभी परिवर्तन अब रिपॉजिटरी में हैं। उसके बाद, डेवलपर को संघर्ष के बिना विलय करने में सक्षम होने के लिए देव से अपनी शाखा को अपडेट करने की आवश्यकता है।
सबसे पहले आपको नवीनतम देव शाखा प्राप्त करने की आवश्यकता है

 git checkout dev git pull origin dev 

और फिर देव शाखा में होने वाले सभी परिवर्तनों को अपनी शाखा में डालें (1234-बग-लॉगिन)

 git checkout 1234-bug-login git rebase dev git push -f origin 1234-bug-login 

5. महान! रिपॉजिटरी में सुलझे हुए संघर्षों वाली एक शाखा। अब डेवलपर 1234-बग-लॉगिन से क्रिएट पुल रिक्वेस्ट को जीथब का उपयोग करके देव शाखा में करता है। पुल अनुरोध विवरण में कार्य (# 1234) के लिए एक लिंक रखना भी आवश्यक है।

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

7. कभी-कभी, सुधार में कुछ समय लगता है, और अन्य डेवलपर्स ने पहले ही देव के साथ अपनी शाखाओं का विलय कर दिया है। इस मामले में, 2 विकल्प हैं:

- जीथब पर मर्ज पुल अनुरोध बटन सक्रिय है। इसका मतलब है कि अन्य डेवलपर्स के परिवर्तन वर्तमान परिवर्तनों के साथ संघर्ष नहीं करते हैं, और कुछ भी करने की आवश्यकता नहीं है।

- मर्ज पुल अनुरोध बटन निष्क्रिय है। आपको चरण 4 पर वापस लौटना होगा) और देव शाखा से 1234-बग-लॉगिन में फिर से विलय और परिवर्तन जमा करना होगा।

 git checkout dev git pull origin dev git checkout 1234-bug-login git rebase dev git push -f origin 1234-bug-login 

8. महान! सभी परिवर्तन किए गए हैं, और किसी ने एक टिप्पणी "इसे मर्ज करें" को पुल अनुरोध में लिखा है। देव शाखा में 1234-बग-लॉगिन परिवर्तनों को पुश करने के लिए मर्ज पुल अनुरोध बटन पर क्लिक करने का समय आ गया है।

परीक्षण

9. जैसे ही 1234-बग-लॉगिन देव में हो जाता है, जेनकिंस (निरंतर एकीकरण प्रणाली) स्वचालित रूप से देव शाखा से देव सर्वर को अपडेट करता है। क्यूए परीक्षण करना शुरू कर सकता है और परिणामस्वरूप, कार्य की पुष्टि या पुन: खोज करता है।

10. यदि पुल अनुरोध बहुत सारे बदलाव करता है, तो डेवलपर परीक्षक के लिए परीक्षण के लिए अपनी शाखा को क्यूए सर्वर पर अपलोड करने के लिए जेनकिंस का उपयोग कर सकता है।

रिलीज की तारीख

11. उत्पादन सर्वर को अपग्रेड करने से पहले, आपको मास्टर में देव शाखा को जोड़ना होगा। ऐसा करने के लिए, हम गितुब का उपयोग करते हुए देव से मास्टर तक एक पुल अनुरोध बनाते हैं और मर्ज पुल अनुरोध पर क्लिक करते हैं , बस। पिछले पैराग्राफ के कार्यान्वयन में, कोई संघर्ष नहीं होगा।

12. यदि प्रतिगमन परीक्षण सफलतापूर्वक पूरा हो गया है, तो अंतिम पैकेज (जिस पर परीक्षण हुआ था) लेते समय, आप उत्पादन सर्वर को अपडेट कर सकते हैं, और यह वह है जो उत्पादन सर्वर पर स्थापित है।

13. कभी-कभी QAs प्रतिगमन परीक्षण के दौरान त्रुटियों का पता लगाते हैं। इस मामले में, मानक योजना के अनुसार सुधार किए जाते हैं, सिवाय इसके कि शाखा बनाई गई है और देव से नहीं, बल्कि मास्टर से विलय की गई है। रिलीज के बाद, आपको मास्टर से देव में सुधार जोड़ने की आवश्यकता है।

 git checkout master git pull origin master git checkout dev git pull origin dev git merge master git push origin dev