मुझे यकीन नहीं है कि यह कितना आसान हो सकता है। यदि आप rebase -i करते हैं, तो यह सभी विलयों को अनदेखा करने का प्रयास करेगा, जो विवाद के बिना विलय के लिए सफल हो जाते हैं, लेकिन यदि कोई संघर्ष हुआ तो बंद हो जाता है और आपके लिए इंतजार कर रहा है।
यदि आप इसे rebase -i -p के रूप में आमंत्रित करते हैं, तो दूसरी तरफ, यह विलय को संरक्षित रखेगा, जो उपयोगकर्ता चाहते हैं जब आप वास्तविक विलय करते हैं, लेकिन अन्यथा पूरी तरह से इस बिंदु को याद करते हैं।
शायद दो आदेशों का कुछ अनुक्रम, केवल जब आप चाहें विलय को संरक्षित करते हैं, तो इस मामले में काम पूरा हो सकता है।
मुझे चार्ल्स से सहमत होना चाहिए, हालांकि, इतिहास को वास्तविकता को प्रतिबिंबित करने से यह "सुंदर दिखने" से कहीं अधिक मूल्यवान है। तथ्य यह है कि, एक प्रतिबद्धता दूसरे के ज्ञान के बिना बनाई गई थी, और स्रोत कोड के मामले में यह आपको बता सकता है कि कुछ गलत क्यों हो सकता है।
हमारी टीम एक विशुद्ध रूप से विलय आधारित Git कार्यप्रवाह
क्या हमेशा साथ --rebase (जैसे git pull -r) खींच साथ कुछ गड़बड़ है का उपयोग करता है? यदि आप एक फ्लैट टोपोलॉजी चाहते हैं, तो सबसे आसान तरीका यह है कि जब आप रीबेज कर सकते हैं तो विलय नहीं करना चाहिए।
इसके अलावा: आप कहते हैं कि अगर आप "मर्ज साफ है" तो आप केवल फ़्लैट करना चाहते हैं। मैं बस यहां अनुमान लगा रहा हूं, लेकिन मुझे लगता है कि डिफ़ॉल्ट प्रतिबद्ध संदेश में किसी नोट के अलावा तथ्य के बाद गिट रिकॉर्ड संघर्ष नहीं है, जो अभी भी वहां नहीं हो सकता है।
स्रोत
2009-10-28 08:55:58
+1 - "वास्तविकता काटने"। गिट इतने विशाल टूलस्पेस और इतने सारे विकल्प प्रदान करता है, यह जानना मुश्किल हो सकता है कि स्मार्ट क्या है और क्या नहीं है। मैं काम के लिए काम नहीं करने में दृढ़ आस्तिक हूं, इसलिए शायद मैं आपकी सलाह के साथ रहूंगा। – krosenvold