पुल अनुरोध

के लिए विकास शाखा को डिफ़ॉल्ट के रूप में सेट करें, मैं डिफ़ॉल्ट रूप से सुविधा शाखा से पुल अनुरोध को विकसित करना चाहता हूं।पुल अनुरोध

मैं Git प्रवाह के उपयोग की वकालत कर रहा हूँ, इसलिए जब एक पुल अनुरोध एक सुविधा के लिए प्रस्तुत किया जाता है, पुल अनुरोध का विकास में विलय करने के लिए जरूरत है, और गुरु नहीं।

प्रबंधकों में से कुछ टिप्पणी की मानव जा रहा है, संभावना है कि टीम की ओर जाता है कि इस तथ्य को नजरअंदाज और मास्टर में गलती से पुल अनुरोध मर्ज कर सकते हैं, पर बाद में रिलीज के साथ समस्याएं उत्पन्न कर रहा है।

हम नरक मर्ज करने के जोखिमों को कम करना चाहते हैं, इसलिए यह इस लक्ष्य को प्राप्त करने में एक लंबा रास्ता तय करेगा।

संपादित करें: मैं gitflow बुलाया hubflow (http://datasift.github.com/gitflow/) के एक कांटा का उपयोग कर रहा हूँ। डिफ़ॉल्ट रूप से, जब एक फीचर शाखा बनाई जाती है git hf feature start [tik-123] फीचर शाखा प्रति spec बनाई जाती है लेकिन मूल तक भी धक्का दी जाती है। हम इसे सहयोग के लिए चाहते हैं। एक बार सुविधा पूरी होने के बाद, देव github में फीचर शाखा में जायेगा और पुल अनुरोध जारी करेगा। टीम लीड तब पुल अनुरोध की समीक्षा करेगी और स्प्रिंट में रिहाई के लिए फीचर स्लेटेड होने पर फीचर को देव में विलय कर देगा।

स्रोत

2013-02-13 ton.yeung

कृपया वर्तमान में उपयोग की जा रही कमांड दिखाएं। मैं वास्तव में नहीं देखता कि कैसे एक सुविधा शाखा और एक पुल एक साथ आते हैं। आमतौर पर, फीचर शाखा डेवलपर्स रिपोजिटरी के लिए स्थानीय होती है। इसे प्रकाशित किया जा सकता है लेकिन फिर इसे मूल/विशेषताओं/ पर प्रकाशित किया जाएगा। मैं नहीं देखता कि एक पुल मास्टर में कैसे विलय करेगा। –

संभवतः डुप्लिकेट [ग्रिथब में डिफ़ॉल्ट रूप से एक अलग शाखा में पुल अनुरोध मर्ज करें] (http://stackoverflow.com/questions/9135913/merge-pull-request-to-a- अलग-branch-than-default-in -github) – CharlesB

@ चार्ल्सबी यह मणि तथ्य के बाद है। मैं यह सुनिश्चित करना चाहता हूं कि जब भी वे पुल अनुरोध जारी करते हैं तो मेरे देवताओं को बेस शाखा बदलने के बारे में चिंता करने की ज़रूरत नहीं है। –

वैकल्पिक रूप से develop डिफ़ॉल्ट शाखा है कि हर कोई देखता है परियोजना का दौरा जब बनाते हैं। नकारात्मकता यह है कि जो भी इसे क्लोन करता है वह डिफ़ॉल्ट रूप से एक अस्थिर शाखा प्राप्त करेगा लेकिन सभी पुल अनुरोध डिफ़ॉल्ट रूप से विकास शाखा में भी जाएंगे।

स्रोत

2013-02-13 16:35:17

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

ऐसा लगता है कि यह काम करता है, उत्तर –

@ ton.yeung के रूप में चिह्नित किया गया है, मुझे लगता है कि आपने इसे समझ लिया है, लेकिन दूसरों के लिए, यदि आप अपने भंडार को देखते हुए सेटिंग टैब पर जाते हैं, तो आप इसे दिखाए गए पहले पृष्ठ पर बदल सकते हैं। चीयर्स। –

जिथब का अपना स्वयं का सुझाया गया वर्कफ़्लो github flow है, सम्मेलन द्वारा सभी पुल अनुरोध master पर डिफ़ॉल्ट हैं लेकिन अब आप इसे अपनी पसंद की किसी भी शाखा में संपादित कर सकते हैं।

स्रोत

2013-02-13 16:27:13 xero

अच्छी तरह से बेकार है। यह उनकी प्रणाली है, इसलिए मुझे लगता है कि वे इसे कैसे काम कर सकते हैं। हालांकि, गिट प्रवाह कितना लोकप्रिय है, मुझे लगता है कि वे इसका समर्थन करने पर विचार करेंगे, भले ही वे इसे स्वयं उपयोग नहीं करना चाहते हैं। –

सहमत हुए। काश वे उपयोगकर्ताओं को अधिक "प्रति-रेपो" कॉन्फ़िगरेशन और नियंत्रण रखने की अनुमति देंगे। लेकिन यह अभी भी एक शानदार * मुफ्त * सेवा है, इसलिए मैं बहुत ज्यादा शिकायत नहीं कर सकता; डी – xero

हमारे लिए वास्तव में मुफ्त नहीं है, क्योंकि हम एक वाणिज्यिक दुकान –

master और develop शाखाओं का उपयोग करने के बजाय, stable और master का उपयोग करें।

तो यह आम तौर पर एक नया संस्करण टैग करने से पहले उन्हें एक करना अच्छा है, इसलिए कोई भी या केवल थोड़ा मोड़ है। मैं इस स्कीमा का उपयोग करता हूं और आमतौर पर stable छोटे विलंब के साथ master का पालन करता है और विलय अधिकतर तेज़-आगे होते हैं।

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

स्रोत

2013-02-13 16:33:33

उत्तर

संबंधित मुद्दे