दिलचस्प पोस्ट
उलट () या का उपयोग किए बिना एक स्ट्रिंग उल्टा है? शैली = "स्थिति: निरपेक्ष" और शैली = "स्थिति: सापेक्ष" के बीच का अंतर कैसे सी # में डेस्कटॉप पर प्रभावी ढंग से आकर्षित? getWidth () और getHeight () दृश्य का रिटर्न 0 हेडर-केवल लाइब्रेरी में स्थैतिक डाटा सदस्यों के लिए कैसे है? स्ट्रट्स + हाइबरनेट: @ सत्र टार्गेट काम नहीं कर रहा है सेलेनियम का उपयोग करने वाले प्रमाण पत्रों से कैसे निपटें? <Div> <a>> के आसपास लिंक लपेटें सर्वर पर एक्सक्शंस डिक्टचर इन्फॉल्ट (यानी सेवाविशेषित्र से या <serviceDebug> कॉन्फ़िगरेशन वर्तन से) को शामिल करें चालू करें सबसे सफ़ेद पर्स एमवीसी को समझना कैसे नए नेविगेशनदृश्य में एक सरल विभक्त बनाने के लिए? डेटाटेबल () बनाम डेटाटाले () – क्यों कोई अंतर है और मैं उन्हें एक साथ कैसे काम करूं? नेस्टेड सूची इंडेक्स stoi और std :: to_string mingw पर 4.7.1

जीआईटी फास्ट फॉरवर्ड डिफ़ॉल्ट रूप से क्यों विलीन हो जाती है?

मौसमी से आ रहा है, मैं सुविधाओं को व्यवस्थित करने के लिए शाखाओं का उपयोग करता हूं। स्वाभाविक रूप से, मैं अपने इतिहास में इस काम-प्रवाह को भी देखना चाहता हूं।

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

तो भविष्य में सोचने के लिए: मैं इस परियोजना पर केवल एक ही काम कर रहा हूं। अगर मैं जीआईटी के डिफ़ॉल्ट दृष्टिकोण (फास्ट फॉरवर्ड मर्जिंग) का उपयोग करता हूं, तो मेरा इतिहास एक विशाल मास्टर शाखा का परिणाम होगा कोई भी नहीं जानता कि मैं हर सुविधा के लिए एक अलग शाखा का इस्तेमाल करता हूं, क्योंकि अंत में मुझे उस विशाल मास्टर शाखा ही मिलेगी। क्या यह अव्यवसायिक नहीं होगा?

इस तर्क से, मैं तेजी से आगे विलय नहीं करना चाहता और नहीं देख सकता कि यह डिफ़ॉल्ट क्यों है। इसके बारे में क्या अच्छा है?

Solutions Collecting From Web of "जीआईटी फास्ट फॉरवर्ड डिफ़ॉल्ट रूप से क्यों विलीन हो जाती है?"

फास्ट-फॉरवर्ड विलय अल्पकालिक शाखाओं के लिए समझ में आता है, लेकिन एक और अधिक जटिल इतिहास में , गैर-फास्ट-फॉरवर्ड विलीन करने से इतिहास को समझना आसान हो सकता है, और कमिट के एक समूह को वापस करना आसान बना सकता है।

चेतावनी : गैर-फास्ट-अग्रेषण में संभावित दुष्प्रभाव भी हैं कृपया https://sandofsky.com/blog/git-workflow.html की समीक्षा करें , इसके "चेकपॉइंट कटिट्स" के साथ 'नो-एफएफ' से बचें, जो विच्छेदन या दोष को तोड़ता है, और सावधानी से विचार करें कि यह master लिए आपका डिफ़ॉल्ट दृष्टिकोण होना चाहिए या नहीं।

वैकल्पिक शब्द
( Nvie.com से , विन्सेन्ट ड्रिसेन , " एक सफल गिट ब्रांचिंग मॉडल " के बाद)

विकास पर एक पूर्ण सुविधा शामिल है

आगामी सुविधाओं को आगामी रिलीज में जोड़ने के लिए विकास शाखा में मिलाया जा सकता है:

 $ git checkout develop Switched to branch 'develop' $ git merge --no-ff myfeature Updating ea1b82a..05e9557 (Summary of changes) $ git branch -d myfeature Deleted branch myfeature (was 05e9557). $ git push origin develop 

--no-ff फ्लैग हमेशा एक नया कमिट ऑब्जेक्ट बनाने के लिए मर्ज का कारण बनता है, भले ही मर्ज एक तेज़-आगे के साथ किया जा सकता है यह एक सुविधा शाखा और समूहों के ऐतिहासिक अस्तित्व के बारे में जानकारी खोने से बचा जाता है, सभी एक साथ जोड़ दिया गया है जो इस सुविधा को जोड़ता है।

Jakub Narębski भी config merge.ff का उल्लेख करता है:

डिफ़ॉल्ट रूप से, Git एक प्रतिबद्धता को विलीन करते समय एक अतिरिक्त मर्ज कमिट नहीं बनाता है जो वर्तमान प्रतिबद्धता के वंशज है। इसके बजाय, वर्तमान शाखा की नोक तेजी से अग्रेषित की जाती है।
जब false सेट किया जाता false , तो यह चर गिट को ऐसे मामले में एक अतिरिक्त मर्ज कमिट बनाने के लिए कहता है (कमांड लाइन से --no-ff विकल्प देने के बराबर)।
जब only ' only ' पर सेट किया जाता है, तो केवल ऐसे ही फास्ट फॉरवर्ड विलीन की अनुमति दी जाती है (कमांड लाइन से --ff-only विकल्प देने के बराबर)।


फास्ट फॉरवर्ड डिफ़ॉल्ट है क्योंकि:

  • जीआईटी में अल्पावधि की शाखाएं बनाने और उपयोग करने में बहुत आसान हैं
  • अल्पकालिक शाखाएं अक्सर कई कमिट को अलग करती हैं जिन्हें उस शाखा में स्वतंत्र रूप से पुनर्गठित किया जा सकता है
  • ये लोग वास्तव में मुख्य शाखा का हिस्सा हैं: एक बार पुनर्गठित किया गया, मुख्य शाखा को उन्हें शामिल करने के लिए तेज़ अग्रेषित किया गया है।

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

इस स्थिति में, आप इस तरह की कॉन्फ़िग फाइल सेट कर सकते हैं:

 [branch "master"] # This is the list of cmdline options that should be added to git-merge # when I merge commits into the master branch. # The option --no-commit instructs git not to commit the merge # by default. This allows me to do some final adjustment to the commit log # message before it gets commited. I often use this to add extra info to # the merge message or rewrite my local branch names in the commit message # to branch names that are more understandable to the casual reader of the git log. # Option --no-ff instructs git to always record a merge commit, even if # the branch being merged into can be fast-forwarded. This is often the # case when you create a short-lived topic branch which tracks master, do # some changes on the topic branch and then merge the changes into the # master which remained unchanged while you were doing your work on the # topic branch. In this case the master branch can be fast-forwarded (that # is the tip of the master branch can be updated to point to the tip of # the topic branch) and this is what git does by default. With --no-ff # option set, git creates a real merge commit which records the fact that # another branch was merged. I find this easier to understand and read in # the log. mergeoptions = --no-commit --no-ff 

ओपी टिप्पणियों में जोड़ता है:

मुझे [अल्पावधि] शाखाओं के लिए फास्ट फॉरवर्ड में कुछ समझ है, लेकिन इसे डिफ़ॉल्ट क्रिया करने का अर्थ है कि git आपको मानता है … अक्सर [अल्पकालिक] शाखाएं हैं उचित?

जेफमी जवाब देती है:

मुझे लगता है कि शाखाओं का जीवनकाल उपयोगकर्ता से बहुत ही भिन्न होता है। अनुभवी उपयोगकर्ताओं में से, हालांकि, संभवत: अधिक अल्पकालिक शाखाओं की प्रवृत्ति हो सकती है।

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

अधिक सामान्यतः, मैं जोड़ता हूं:

यह वास्तव में आपके विकास कार्यप्रवाह पर निर्भर करता है :

  • यदि यह रैखिक है, तो एक शाखा समझ में आता है।
  • अगर आपको सुविधाओं को अलग करने और लंबी अवधि के लिए उन पर काम करने और उन्हें बार-बार मर्ज करने की आवश्यकता है, तो कई शाखाएं समझ लेती हैं

" आप कब शाखाएं चाहिए? " देखें

दरअसल, जब आप मर्क्यूरिअल शाखा मॉडल पर विचार करते हैं, तो इसकी प्रति एक शाखा इसकी शाखा में होती है (भले ही आप अनाम सिर, बुकमार्क्स और यहां तक ​​कि नामांकित शाखाएं बना सकते हैं)
"गिट और मर्कुरियल – तुलना करें और कंट्रास्ट" देखें

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

मुझे VonC के बहुत व्यापक उत्तर पर थोड़ा विस्तारित करने दें:


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

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


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

HTH