इंटीग्रेटर वर्कफ़्लो, रिमोट रिपोज़ के लिए fetch-rebase-push सुरक्षित है?

Question

मैं इंटीग्रेटर कार्य प्रवाह का उपयोग कर एक गिट रेपो का प्रबंधन कर रहा हूं। दूसरे शब्दों में, मैं अपने सहकर्मियों से काम करता हूं, और उन्हें धन्य रेपो में डाल देता हूं।

मैं ज्यादातर मामलों के लिए प्रतिबद्धता इतिहास रैखिक रखना चाहता हूं, तो क्या merge के बजाय जब मैं परिवर्तनों को एकीकृत करता हूं तो क्या करना ठीक है?

git fetch coworker 
git checkout coworker/master 
git rebase master 
git checkout master 
git merge HEAD@{1} 
git push 

मैं चिंतित क्या दूरस्थ रेपोस का क्या होगा जब वे अपने अगले git pull कर रहा हूँ: यहाँ एक उदाहरण है। क्या यह गिट इसे संभालने में सक्षम होगा, या coworker रेपो pull के दौरान असफल हो जाएगा, अब यह origin पर एक अलग क्रम में है?

अद्यतन: मूल रूप से उदाहरण में 'मास्टर' से 'सहकर्मी' शाखा को पुन: पेश किया गया था। मेरा उद्देश्य इरादा था कि 'सहकर्मी' मास्टर के शीर्ष पर काम करता है। तो मैंने उदाहरण अपडेट किया।

Answer 1

आप निश्चित रूप से ऐसा नहीं करना चाहते हैं जो आप सुझाते हैं, यह आपके सहकर्मी के master पर master शाखा को पुनर्जीवित करेगा। आपके सहकर्मी के master पर आधारित इस आधार पर आप केंद्रीय master को अक्सर रिवाइंड कर सकते हैं।

आप जो करना चाहते हैं वह विपरीत है, इसे अपने सहकर्मी के स्वामी को मास्टर में विलय करने से पहले पुन: पेश करें।

git fetch coworker 
git checkout coworker/master 
git rebase master 
git checkout master 
git merge HEAD@{1} 
git push 

हालांकि मैं अभी भी इसकी अनुशंसा नहीं करता हूं। आपके सहकर्मियों को यह हल करना होगा कि आपने उनके परिवर्तनों को कैसे बदला है। अधिकांश समय यह संभवतः छोटा होता है और वे आपके कामों को आपके पक्ष में फेंक सकते हैं, लेकिन यह अभी भी कुछ ऐसा है जिसे उन्हें मैन्युअल रूप से जांचने की आवश्यकता है।

व्यक्तिगत रूप से, मैं उनके कामों की सीधे विलय की सिफारिश करता हूं। यदि आपको लगता है कि वे मास्टर के पुराने संस्करण पर आधारित हैं और विलय अनावश्यक रूप से जटिल होगा या एक अन्यायपूर्ण पुरानी प्रतिबद्धता के आधार पर होगा तो उन्हें अपने मास्टर को रीबेट करने और रीफ्रैक करने के लिए प्राप्त करें। फिर कम से कम वे जानते हैं कि आप क्या विलय कर रहे हैं और वे अपने कोड में किसी भी विवाद को हल करते हैं।

इसके अलावा, मैं अनावश्यक रूप से रैखिक इतिहास के उद्देश्य से सावधानी बरतता हूं। समांतर में विकसित डेवलपर्स की शाखाओं में विलय आपको इतिहास का एक और वास्तविक प्रतिनिधित्व देता है। यदि आप विलय करने से पहले डेवलपर की प्रतिबद्धता को दोबारा शुरू करते हैं तो आपके पास अब एक प्रतिबद्ध रिकॉर्ड नहीं है जो उस कोड की बिल्कुल सही स्थिति का सटीक प्रतिनिधित्व है जिसे डेवलपर तय और सबमिट किया गया है। इससे अक्सर कोई फर्क नहीं पड़ता है लेकिन ऐसा हो सकता है कि दो एक बग का उत्पादन करने के लिए बातचीत करते हैं, लेकिन विलय संघर्ष नहीं करते हैं। यदि आप रीबेज नहीं करते हैं, तो आपको अधिक सटीक (और fairer!) 'दोष' मिलता है।

Answer 2

यह मामूली मामलों के लिए स्वीकार्य वर्कफ़्लो होगा। जब आपके सहकर्मी, git pull करें, तो यह वास्तव में git fetch है जिसके बाद git merge है। गिट विलय करने में वास्तव में बहुत अच्छा है और बिना किसी मुद्दे के साधारण मामलों को हल करने में सक्षम होगा।

हालांकि, अगर आपको git rebase चरण पर संघर्ष सुलझाने के लिए कोई काम करना है, तो आपके सहकर्मियों को उस काम को फिर से करना होगा। ऐसा इसलिए होगा क्योंकि रीबेज के बाद आपके अनुक्रम का अनुक्रम उनके से बहुत अलग दिखता है।

यदि आप एक nonlinear इतिहास के साथ सहज हो जाते हैं, तो गिट शायद इस वर्कफ़्लो को बेहतर तरीके से प्रबंधित करने में सक्षम होगा (क्योंकि यही वह है जिसे इसे संभालने के लिए डिज़ाइन किया गया है)।

Answer 3

"A truce in the merge vs. rebase war?" लेख में उल्लेख किया है, (जोर मेरा)

शायद पारंपरिक रिबेसिंग साथ सबसे खराब समस्या यह है कि यह सहयोग रोकता है।
कोई भी जो रिबेजिंग से पहले और बाद में एक भंडार से खींचता है, संघर्ष का अनुभव करेगा क्योंकि दोनों इतिहास एक-दूसरे से विरोधाभास करते हैं। इस प्रकार मानक चेतावनी "एक प्रकाशित भंडार के भीतर पुन: प्रतिक्रिया न करें", जिसे "उस काम पर सहयोग न करें जिसे आप बाद में रीबेज करना चाहते हैं" के लिए दोहराया जा सकता है।

यहां तक ​​कि अगर यह "काम" क्योंकि संघर्ष की कमी होती है, यह आप अपने रिबेस के दौरान किसी भी गैर तुच्छ मर्ज हल करने के लिए करता है, तो कुछ परेशानियों का कारण बन सकता: के

M0----M1----M2 
\ 
\ 
    \ 
    B1----B2 

M0----M1----M2 
      \ 
      \ 
       \ 
       B1'---B2' 

SHA-1 आपकी (पहले प्रकाशित) शाखा को फिर से लिखा जा रहा है, आपके सहयोगियों को अपने पर्यावरण में उस शाखा को विलय करने में कठिन समय लगेगा।

Answer 4

गिट के बारे में बड़ी मात्रा में दस्तावेज और ट्यूटोरियल का विशाल बहुमत यह स्पष्ट करता है कि रिबेस का उपयोग निजी शाखाओं पर ही किया जाना चाहिए, ऐसा कुछ भी नहीं जो कोई और देख सके। आपके मॉडल के तहत मैं अकल्पनीय विफलताओं से डरता हूं या अन्य प्रतिकृतियों पर काम दोहराना चाहता हूं। से बचें!

Answer 5

मैंने इस काम प्रवाह पर कुछ सरल परीक्षण किए। मैं चार्ल्स की पोस्ट से सहमत हूं, लेकिन कुछ अन्य जानकारी जोड़ना चाहता हूं।

पेशेवरों

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

विपक्ष

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