दूरस्थ सुविधा/बग/विषय (निजी) शाखा

Question

रीबेज करना इस नियम को रिमोट रिपोजिटरी में धकेलने वाले कार्यों को पुनर्जीवित न करने का यह नियम है। जब तक मैं इसके लिए सामान्य कारणों को समझता हूं, यह मेरे लिए स्पष्ट नहीं है, क्या यह इस परिदृश्य पर भी लागू होता है:

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

काम खत्म करने के बाद, मैं इसे किसी भी तरह मास्टर में विलय करना चाहता हूं।

मेरे सवालों का:

1. धारणा है कि और कोई नहीं चेकआउट होगा कभी नहीं और MyFeature शाखा निकालते हैं और इस शाखा से प्रतिबद्ध पर अपने काम के आधार पर (क्यों किसी को कुछ यादृच्छिक शाखा खींचने के लिए चाहते हैं?), क्या इस तरह की रिमोट शाखा को पुनर्जीवित करना ठीक है? (-फोर्स स्विच का उपयोग)
2. यदि यह किसी कारण से अभी भी सलाह नहीं दी जाती है (हालांकि मैं उस कारण को जानना चाहता हूं) विकल्प क्या है? सरल विलय? लेकिन यदि ऐसा है, तो बाद में, मैं अभी भी स्थानीय और दूरस्थ दोनों भंडारों से माईफिएचर शाखा को हटाना चाहता हूं। तो यह कैसे अलग होगा (1)? मैं अभी भी इसे पूरी तरह से हटाकर इतिहास बदलता हूं।
3. ऊपर उल्लिखित परिदृश्य दुर्लभ या अनैतिक है? मेरा मतलब है, इसके लिए उत्तर खोजते समय, गिट-रीबेस के बारे में ट्यूटोरियल्स और SO प्रश्नों को पढ़ते समय, हमेशा रिमोट शाखाओं को रिहा करने के इस खतरे पर जोर दिया जाता है, लेकिन इस तरह के अन्य उपयोग मामलों को कभी भी नहीं माना जाता है। आईएमएचओ उस दिन कुछ फीचर पर काम करना बहुत आम है, और मुझे लगता है कि कोई सतर्क डेवलपर केवल अपने कंप्यूटर पर बदलाव नहीं रखना चाहिए ...

Answer 1

इस धारणा पर कि कोई भी कभी भी चेकआउट नहीं करेगा और माईफैचर शाखा खींच नहीं पाएगा, और इस शाखा से काम करने के लिए अपना काम आधार करेगा, क्या इस तरह की रिमोट शाखा को पुनर्जीवित करना ठीक है? (-Force स्विच का उपयोग)

इतना ही नहीं यह ठीक rebase करने और master पर अपने रिमोट सुविधा शाखा धक्का मजबूर है, यह परिवर्तन लाने जबकि linearity बनाए रखने के द्वारा master से आगे रहने के लिए एक ही रास्ता है। जिस पल में आप rebase अपनी स्थानीय फीचर शाखा को दूसरी शाखा (जैसे master) पर लेते हैं, तो आपको रिमोट पर धक्का देना होगा क्योंकि आपने इतिहास को प्रभावी रूप से फिर से लिखा है। किसी भी नुकसान का कोई खतरा नहीं है क्योंकि आप इस शाखा पर काम करने वाले अकेले होंगे। मैं दृष्टिकोण लेता हूं कि गिट बनाया गया कुछ भी स्वाभाविक रूप से बुरा नहीं है, और प्रत्येक गिट सुविधा में इसका समय और स्थान होता है। यह एक उदाहरण है जहां बल धक्का करना स्वीकार्य है।

वास्तव में, एक दूरस्थ व्यक्तिगत सुविधा शाखा एकमात्र उदाहरण है जहां एक शाखा पर rebase का उपयोग करना ठीक है जिसे पहले ही रिमोट पर धक्का दिया गया है। जैसा कि बताया गया है, आप किसी और के लिए समस्याएं नहीं पैदा करेंगे क्योंकि आपने केवल इस शाखा की जांच की है।

कहा जा रहा है कि, एक सार्वजनिक शाखा के rebase को एक सार्वजनिक शाखा के द्वारा साझा किया जा रहा है, जो खतरनाक है, क्योंकि यह उनके अगले खींचने पर हर किसी के लिए संघर्ष का कारण बन सकता है (बेशक उपयोगकर्ता के लिए बेशक छोड़कर)।

Answer 2

बहुत ही व्यक्तिपरक। "क्या यह ठीक है?" किसको? आप को? अपने नियोक्ता के लिए? उनसे पूछों।

तकनीकी व्यवहार्यता के लिए के रूप में:

1. हाँ, कोई समस्या नहीं है।

2. आप शाखा को विलय और हटा सकते हैं। मैं इस विधि को पसंद करता हूं (देखें? व्यक्तिपरक) और मैं git merge --no-ff का भी उपयोग करता हूं ताकि अगर विलय तेजी से आगे हो, तो विलय प्रतिबद्धता बनाई गई है। शाखा हटाना इतिहास को संशोधित नहीं करता है; आप सिर्फ शाखा सूचक को हटाते हैं, काम नहीं करते हैं।

   एक और विकल्प git merge --squash है जो शाखा को उस एकल प्रतिबद्धता में विलय करने के लिए स्क्वैश करता है जो उस शाखा में लागू होता है जिसे आप विलय करना चाहते हैं। मैं उस के प्रशंसक नहीं हूं लेकिन कुछ ऐसे लोग हैं।

3. नहीं, यह न तो दुर्लभ और न ही अनैतिक है।

Answer 3

धारणा है कि और कोई नहीं चेकआउट होगा कभी नहीं और MyFeature शाखा खींच, और इस शाखा से प्रतिबद्ध पर अपने काम के आधार पर (क्यों किसी को कुछ यादृच्छिक शाखा खींचने के लिए चाहते हैं?), यह rebase के लिए ठीक है ऐसी रिमोट शाखा?

बेशक, और आपको rebase चरण के लिए --force की आवश्यकता नहीं है।
आप केवल जब तक आप नदी के ऊपर रेपो पर अपने खुद के शाखा अद्यतन कर रहे हैं के रूप में अपनी शाखा

git checkout MyFeature 
git fetch 
git rebase origin/master 
git push --force 

धक्का मजबूर करने के लिए इसकी आवश्यकता है, कि एक मुद्दा नहीं होना चाहिए।

Answer 4

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

यह साझा शाखाएं हैं जो पुन: प्रयास करते समय परेशानी का कारण बनती हैं। यहां क्यों स्पष्टीकरण देखें: https://superuser.com/a/667200