एक बहु-डेवलपर गिट वर्कफ़्लो, एक स्वच्छ इतिहास बनाए रखने

Question

सैंडोफस्की advocates आपके 'मुख्य' रेपो के इतिहास के बारे में बहुत सख्त होने के कारण, इसे शाखाओं और चेकपॉइंट के साथ छेड़छाड़ किए बिना साफ रखता है।

आपको कभी भी एक निजी शाखा को वेनिला विलय के साथ सार्वजनिक शाखा में विलय नहीं करना चाहिए। सबसे पहले, अपनी शाखा को रीसेट, रीबेस, स्क्वैश विलय, और संशोधित करने जैसे टूल के साथ साफ़ करें।

सार्वजनिक इतिहास को अपरिवर्तनीय, परमाणु और अनुसरण करने में आसान के रूप में व्यवहार करें। निजी इतिहास को डिस्पोजेबल और लचीला मानें।

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

मुझे लगता है कि इस दृष्टिकोण का अर्थ है कि धन्य रेपो में the master and develop branch के अलावा कोई शाखा नहीं होगी। फ़ीचर शाखाएं केवल आपके स्थानीय भंडार में मौजूद होंगी - यदि शाखा पर सहयोग की आवश्यकता है, तो यह शाखा को सहयोगी कर्मचारियों में से एक के रिमोट रिपोजिटरी में धकेलकर हो सकता है।

हालांकि, Pro Git book "सार्वजनिक छोटी परियोजनाओं के लिए" एक कार्यप्रवाह के रूप में इस का वर्णन है। क्या इसका मतलब यह है कि हमारे मामले में एक अलग वर्कफ़्लो का उपयोग करना बेहतर है, जैसे कि समाप्त शाखाओं को व्यक्तिगत रिपोजिटरी के बजाय धन्य रेपो में धक्का देना?

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

---

संपादित: जाहिरा प्रश्न पूछा स्पष्ट नहीं था, इसलिए मैं यह संक्षेप में प्रस्तुत करने की कोशिश करेंगे: (अपने सहयोगियों हमारे धन्य भंडार के लिए सीधे अपने शाखाओं धक्का होने में

एक नुकसान होगा उदाहरण के लिए यह किसी भी तरह से अपने इतिहास को 'प्रदूषित' करेगा?

Answer 1

disadvatages के एक जोड़े:

धन्य रेपो अपेक्षाकृत जल्दी ही होगा (पर कितने डेवलपर्स और सुविधाओं निर्भर करता है) कई शाखाओं से भरा हुआ हो। यह अधिक साफ है अगर इसमें केवल उदा। मास्टर और विकसित करने, मास्टर की तुलना में, विकसित करने, featureA, featureB, featureC .. आदि हालांकि आप हमेशा रिमोट पर उन्हें हटाने के द्वारा रेपो साफ कर सकते हैं (Git धक्का मूल: featureA) लेकिन यह अतिरिक्त साफ काम कहते हैं।

साथ ही, जब लोग धन्य रेपो से प्राप्त होते हैं तो उनके प्रतिनिधि में उन सभी शाखाओं के दूरस्थ संदर्भ होंगे और जब आप रिमोट शाखाओं को हटा देंगे, तो उन्हें रिमोट प्रिंस उत्पत्ति को "गिट रिमोट प्रिंस उत्पत्ति" बंद करना होगा और उन संदर्भों को साफ करना होगा अब मान्य नहीं है, जो अतिरिक्त काम भी जोड़ता है।

Answer 2

मैं कोई कारण नहीं क्यों इस वर्कफ़्लो आपके लिए काम नहीं करेगा देखें: सार्वजनिक पर जोर देने के कारण एक सार्वजनिक परियोजना के लिए हो सकता है, यह एक साफ, अपरिवर्तनीय इतिहास बनाए रखने के लिए और अधिक महत्वपूर्ण है।

Answer 3

मेरा मानना ​​है कि Gitolite के "personal" branches अपनी आवश्यकताओं को बहुत अच्छी तरह से पूर्ति करेगा। यह एक व्यक्तिगत क्षेत्र होने की तरह है (यानीनेमस्पेस) जहां प्रत्येक डेवलपर (जबरन) धक्का दे सकता है। इसके विपरीत, master केवल सभी डेवलपर के लिए पढ़ा जाता है लेकिन एक इंटीग्रेटर है।

तो ऐलिस .git/config निम्नलिखित विन्यास शामिल हैं:

[remote "origin"] 
     url = git@server:project 
     push = +refs/heads/*:refs/heads/personal/alice/* 
     fetch = +refs/heads/master:refs/remotes/origin/master 
     fetch = refs/heads/personal/alice/*:refs/remotes/origin/me/* 
     fetch = +refs/heads/personal/bob/*:refs/remotes/origin/bob/* 

तो ऐलिस origin/me/branch के रूप में सर्वर पर

• उसकी शाखाओं देखना होगा, और
• origin/bob/branch के रूप में बॉब की शाखाओं।

इस तरह, ऐलिस कर सकते हैं:

• उसकी शाखाओं पर काम और पुल/उन्हें सर्वर से धक्का
एक नई शाखा शुरू
• की master
• बॉब के बंद एक नई शाखा शुरू शाखाएं
• बस सर्वर पर धक्का देकर अपने काम का बैकअप लें।

Gitolite विन्यस्त किया जा सकता है कि इस तरह के ऐलिस बॉब निजी स्थान और उपाध्यक्ष प्रतिकूल पर नहीं लिख सकता:

@users = alice bob 
@integrators = john 
@repos = repo1 repo2 

repo @repos 
    RW+       = @integrators 
    RW+  personal/USER/  = @users