मैं एक दूसरे डेवलपर के साथ एक परियोजना पर कुछ महीनों के लिए Git का उपयोग कर रहा हूं। मुझे एसवीएन के साथ कई वर्षों का अनुभव है , इसलिए मुझे लगता है कि मैं रिश्ते में बहुत सारे सामान लाता हूं।
मैंने सुना है कि गिट ब्रांचिंग और मर्जिंग के लिए उत्कृष्ट है, और अब तक, मैं इसे नहीं देखता। निश्चित रूप से, शाखायुक्त मृत सरल है, लेकिन जब मैं विलय करने की कोशिश करता हूं, तो सब कुछ नरक में जाता है। अब, मुझे एसवीएन से इसकी आदत है, लेकिन मुझे ऐसा लगता है कि मैंने एक के लिए एक सब-बराबर वर्जनिंग सिस्टम का कारोबार किया है।
मेरा साथी मुझसे कहता है कि मेरी समस्याएं विली-नीली को मर्ज करने की मेरी इच्छा से उपजी हैं, और मुझे कई स्थितियों में मर्ज के बजाय रिबास का उपयोग करना चाहिए। उदाहरण के लिए, यहां वह वर्कफ़्लो है जिसे उसने नीचे रखा है:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature
git checkout master
git merge my_new_feature
अनिवार्य रूप से, एक सुविधा शाखा बनाएं, हमेशा मास्टर से शाखा में छूट दें, और शाखा से वापस मास्टर में विलय करें। ध्यान रखना महत्वपूर्ण है कि शाखा हमेशा स्थानीय रहती है।
यहाँ कार्यप्रवाह है कि मैं के साथ शुरू कर दिया है
clone remote repository
create my_new_feature branch on remote repository
git checkout -b --track my_new_feature origin/my_new_feature
..work, commit, push to origin/my_new_feature
git merge master (to get some changes that my partner added)
..work, commit, push to origin/my_new_feature
git merge master
..finish my_new_feature, push to origin/my_new_feature
git checkout master
git merge my_new_feature
delete remote branch
delete local branch
दो आवश्यक अंतर हैं (मुझे लगता है): मैं मर्ज का उपयोग हमेशा रिबासिंग के बजाय करता हूं, और मैं अपनी सुविधा शाखा (और मेरी सुविधा शाखा) को दूरस्थ रिपॉजिटरी में धकेलता हूं।
दूरस्थ शाखा के लिए मेरा तर्क यह है कि मैं चाहता हूं कि मेरा काम वापस आ जाए क्योंकि मैं काम कर रहा हूं। हमारी रिपॉजिटरी स्वचालित रूप से समर्थित है और अगर कुछ गलत हो जाता है तो उसे पुनर्स्थापित किया जा सकता है। मेरा लैपटॉप पूरी तरह से नहीं है या नहीं है। इसलिए, मुझे अपने लैपटॉप पर कोड रखने से नफरत है जो कहीं और नहीं दिखाई देता है।
रिबेस के बजाय मर्ज के लिए मेरा तर्क यह है कि मर्ज मानक प्रतीत हो रहा है और रिबेस को एक उन्नत सुविधा लगती है। मेरी आंत की भावना यह है कि मैं जो करने की कोशिश कर रहा हूं वह उन्नत सेटअप नहीं है, इसलिए रिबास अनावश्यक होना चाहिए। मैंने Git पर नई व्यावहारिक प्रोग्रामिंग पुस्तक का भी उपयोग किया है, और वे बड़े पैमाने पर मर्ज को कवर करते हैं और बमुश्किल रिबेस का उल्लेख करते हैं।
वैसे भी, मैं हाल ही में एक शाखा पर अपने वर्कफ़्लो का पालन कर रहा था, और जब मैंने इसे वापस मास्टर में विलय करने की कोशिश की, तो यह सब नरक में चला गया। उन चीजों के साथ कई टकराव हुए, जिन्हें कोई फर्क नहीं पड़ना चाहिए था। संघर्षों से मुझे कोई मतलब नहीं था। मुझे सब कुछ हल करने में एक दिन लग गया, और आखिरकार रिमोट मास्टर को एक मजबूर धक्का दिया गया, क्योंकि मेरे स्थानीय मास्टर ने सभी संघर्षों को हल कर दिया है, लेकिन रिमोट अभी भी खुश नहीं था।
इस तरह से कुछ के लिए "सही" वर्कफ़्लो क्या है? जीआईटी को ब्रांचिंग और मर्जिंग को सुपर-आसान बनाना है, और मैं इसे नहीं देख रहा हूं।
अपडेट 2011-04-15
यह एक बहुत ही लोकप्रिय प्रश्न लगता है, इसलिए मैंने सोचा कि मैं अपने दो साल के अनुभव के साथ अपडेट करूंगा क्योंकि मैंने पहली बार पूछा था।
यह पता चला है कि मूल वर्कफ़्लो सही है, कम से कम हमारे मामले में। दूसरे शब्दों में, यह वही है जो हम करते हैं और यह काम करता है:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git checkout master
git merge my_new_feature
वास्तव में, हमारा वर्कफ़्लो थोड़ा अलग है, क्योंकि हम कच्चे मर्ज के बजाय स्क्वैश मर्ज करते हैं । ( नोट: यह विवादास्पद है, नीचे देखें। ) यह हमें हमारी संपूर्ण सुविधा शाखा को मास्टर पर एक सिंगल कमिट में बदलने की अनुमति देता है। फिर हम अपनी सुविधा शाखा को हटाते हैं। यह हमें तार्किक रूप से मास्टर पर हमारे कमिट की संरचना करने की अनुमति देता है, भले ही वे हमारी शाखाओं पर थोड़ा गड़बड़ हों। तो, हम यही करते हैं:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git checkout master
git merge --squash my_new_feature
git commit -m "added my_new_feature"
git branch -D my_new_feature
स्क्वैश मर्ज विवाद - जैसा कि कई टिप्पणीकारों ने कहा है, स्क्वैश मर्ज आपकी सुविधा शाखा पर सभी इतिहास को फेंक देगा। जैसा कि नाम से ही स्पष्ट है कि यह एक ही बार में सभी कमिट्स को नष्ट कर देता है। छोटी सुविधाओं के लिए, यह समझ में आता है क्योंकि यह एक एकल पैकेज में इसे संघनित करता है। बड़ी सुविधाओं के लिए, यह शायद एक महान विचार नहीं है, खासकर अगर आपका व्यक्तिगत रूप से पहले से ही परमाणु है। यह वास्तव में व्यक्तिगत प्राथमिकता के लिए आता है।
Github और Bitbucket (अन्य?) खींच अनुरोध - मामले में आप सोच रहे हैं कि कैसे मर्ज / रिबास पुल अनुरोधों से संबंधित है, मैं उपरोक्त सभी चरणों का पालन करने की सलाह देता हूं जब तक कि आप मास्टर में वापस विलय करने के लिए तैयार न हों। मैन्युअल रूप से गिट के साथ विलय करने के बजाय, आप बस पीआर स्वीकार करते हैं। ध्यान दें कि यह स्क्वैश मर्ज नहीं करेगा (कम से कम डिफ़ॉल्ट रूप से नहीं), लेकिन गैर-स्क्वैश, नॉन-फास्ट-फॉरवर्ड पुल अनुरोध समुदाय में स्वीकृत मर्ज सम्मेलन है (जहां तक मुझे पता है)। विशेष रूप से, यह इस तरह काम करता है:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git push # May need to force push
...submit PR, wait for a review, make any changes requested for the PR
git rebase master
git push # Will probably need to force push (-f), due to previous rebases from master
...accept the PR, most likely also deleting the feature branch in the process
git checkout master
git branch -d my_new_feature
git remote prune origin
मुझे गिट से प्यार हो गया है और एसवीएन में वापस जाना नहीं चाहता। यदि आप संघर्ष कर रहे हैं, तो बस इसके साथ रहें और अंततः आप सुरंग के अंत में प्रकाश देखेंगे।
rebaseसमझ के साथ बहुत मदद मिली
