git-flow और github के साथ कोड की समीक्षा

Question

नियमित रूप से गिट और जीथब के साथ मैं मास्टर शाखा में काम कर रही सुविधा शाखा के केवल एक पुल अनुरोध बनाकर एक कोड समीक्षा कर सकता हूं। मैं git-flow के साथ कोड समीक्षाएं कैसे करूंगा? "Git flow फीचर फिनिश 'जैसे वर्कफ़्लो के साथ मैं इस उलझन में हूँ कि कोड समीक्षा वास्तव में कहाँ होती है और git-flow या git इस समीक्षा को कैसे सुविधाजनक बना सकता है।

Comments

आप इस पर गौर कर सकते हैं Gerrit हालांकि मुझे यकीन है कि यह कैसे Git-प्रवाह के साथ अच्छी तरह से एकीकृत करता नहीं हूँ। वैसे भी, आपकी टीम वर्कफ़्लो क्या है?

— OnesimusUnbound

Answer 1

हमने हाल ही में इस सटीक समस्या पर ठोकर खाई। हम वास्तव में git flow को पसंद करते हैं, क्योंकि यह शब्दार्थ के एक अच्छे स्तर का उपयोग करता है (उसी स्तर का उपयोग जो आप टीम चर्चा में उपयोग करते हैं: "मैं फ़ीचर A" से अधिक शुरू करूंगा "मैं एक शाखा बनाऊंगा, इसे चेकआउट करूँगा"), जबकि git बहुत "कार्यान्वयन" स्तर है (जो अच्छा है और उपयोगी भी है, लेकिन अलग है)।

हमारे पास जो समस्या है git feature finish, क्योंकि यह शाखा को विकसित करने में विलय करती है, जबकि हम चाहते हैं कि एक पुल अनुरोध भेजा जाए और (यह महत्वपूर्ण है) समीक्षक द्वारा विलय किया जाए , न कि कमिटेटर द्वारा, टीम के स्वामित्व पर जोर देने के लिए।

हमारा वर्तमान समाधान:

1. कोई एक सुविधा शाखा बनाने के लिए git flow का उपयोग करता है
2. जब किया जाता है, तो वह एक पुल अनुरोध (गीथूब का उपयोग करके) बनाता है
3. संभावित अतिरिक्त कमिट के साथ समीक्षा होती है
4. पुल अनुरोध को समीक्षक द्वारा GitHub का उपयोग करके विलय कर दिया जाता है ।
5. गिट फ्लो फीचर फिनिश नहीं है (क्योंकि शाखा पहले से ही मर्ज है)

यह हमारे अभ्यास के अनुरूप है, शाखा को स्वयं हटाने की आवश्यकता के साथ (जैसा कि हम प्रवाह खत्म नहीं करते हैं)। हमारा अगला कदम संभवतः जीआईटी प्रवाह के कुछ हिस्सों को फिर से लागू करना होगा (जैसा कि मुख्य रूप से गिट कमांड के बारे में है) इसे ध्यान में रखना (मर्ज के बिना, खत्म होने की "सफाई" वाला भाग)।

Comments

रिलीज शाखा बनाने के बारे में कैसे? टैग्स के साथ क्या होता है?

— ई-रिद्दी

Answer 2

इसके लिए मैं जिस टीम के साथ काम करता हूं वह इस प्रकार है:

1. एक सुविधा शाखा बनाएँ: git flow feature start module_1
2. कोड को सुविधा शाखा पर अपडेट किया गया है
3. जैसे ही बदलाव किए जाते हैं, उन्हें GitHub में धकेल दिया जाता है (या यदि पसंद हो तो एक बार अंत में)
4. जब सुविधा पूरी हो जाती है तो गिटहब तुलना developऔर सुविधा शाखा में एक पुल अनुरोध खोला जाता हैmodule_1
5. टीम पुल अनुरोध की समीक्षा करती है और टिप्पणी करती है
6. पुल अनुरोध से कोई भी परिवर्तन सुविधा शाखा में किए जाते हैं
7. एक बार सभी परिवर्तन सुविधा शाखा पर शामिल हो जाने के बाद सुविधा शाखा समाप्त हो जाती है: git flow feature finish module_1
8. developशाखा GitHub को धक्का दे (GitHub स्वचालित रूप से जब ऐसा होता है बंद / विलय कर के रूप में पुल अनुरोध का प्रतीक होगा)

आम तौर पर यह सारी प्रक्रिया मूल लेखक द्वारा की जाती है लेकिन इसकी आवश्यकता नहीं होती है। हमारी टीम में कोई भी किसी भी बिंदु पर इस प्रक्रिया को आगे बढ़ा सकता है। उन्हें बस इतना करना है कि सुविधा शाखा की जांच करें और प्रक्रिया जारी रखें। जो कभी भी चलाता git flow feature finish module_1है, उसकी स्थानीय सुविधा शाखा की विलासिता नष्ट हो जाएगी, लेकिन किसी अन्य व्यक्ति ने शाखा की जांच की, यदि ऐसा कुछ उपयोग करना चाहते हैं, तो इसे मैन्युअल रूप से करना होगा git branch -D feature/module_1।

हॉटफ़िक्स के लिए हम एक एप्रोच दृष्टिकोण का उपयोग करते हैं और इससे पहले कि हम हॉटफ़िक्स को पूरा करें, GitHub में पुल अनुरोध बनाएँ।

Comments

इस उत्तर के लिए धन्यवाद। मुझे एहसास नहीं था कि एक विलय के बाद पीआर बंद हो जाएगा।

— vicTROLLA

Answer 3

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

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

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

केंद्रीय रिपॉजिटरी का उपयोग करते समय, अन्य डेवलपर्स चरण 2 के बाद प्रस्तुत परिवर्तनों को देख सकते हैं। गेरिट कोड समीक्षा वर्कफ़्लो का परिचय देता है, और इसलिए अन्य डेवलपर्स केवल चरण 5 के बाद प्रस्तुत परिवर्तन देखते हैं।

यह git-flow (या किसी अन्य ब्रांचिंग स्कीम) के साथ अच्छी तरह से काम करता है क्योंकि Gerrit किसी भी शाखा में किए गए परिवर्तनों की समीक्षा का समर्थन करता है।

Answer 4

यहाँ एक और सुझाव है।

1. एक सुविधा बनाने के लिए नियमित रूप से प्रवाह प्रक्रिया करें , लेकिन इसे खत्म या मर्ज न करें।
2. पुल अनुरोध बनाएं , लेकिन इसे मर्ज न करें। टिप्पणी छोड़ने के लिए अनुमोदन की प्रतीक्षा करें। टिप्पणी अनुमोदन का चिह्न है।
3. गित प्रवाह खत्म करो । (या तो अनुमोदनकर्ता या डेवलपर ऐसा कर सकते हैं, यह इस बात पर निर्भर करता है कि टीम किस आधार पर सहमत हुई है।) पुल अनुरोध को जीथब पर विलय के रूप में चिह्नित किया जाएगा। आपको अभी भी मूल पर शाखा को हटाने की आवश्यकता है।