Git में शाखाएँ

docs.scrimba.com

आप weather-app बनाने के बीच में हैं, और आप एक पाँच दिन का पूर्वानुमान सुविधा जोड़ने का प्रयास करना चाहते हैं। इसे सही करने में कई commits लग सकते हैं, और जब तक यह तैयार नहीं हो जाता, आप अधूरा कोड उस ऐप के बगल में नहीं रखना चाहते जो पहले से सभी के लिए काम कर रहा है। एक शाखा (branch) यही है कि Git यह कैसे हल करता है: काम की एक अलग लाइन जहाँ प्रयोग रहता है, जबकि main बिल्कुल वैसे ही काम करता रहता है जैसे आपने शुरू करने से पहले किया था।

एक शाखा वास्तव में क्या है

यहाँ यह क्रिया में है:

$ git branch forecast
$ git switch forecast
Switched to branch 'forecast'

दो commands: पहली एक नई शाखा forecast बनाती है, दूसरी आपको इस पर ले जाती है। यहाँ से, हर commit जो आप करते हैं वह forecast पर आता है जबकि main बिल्कुल वहाँ रहता है जहाँ यह है।

एक branch एक movable label है जो एक commit की ओर इशारा करता है। अभी, main और forecast दोनों उसी commit की ओर इशारा करते हैं, जिस पर आप git branch forecast चलाते समय खड़े थे। जैसे ही आप forecast पर फिर से commit करते हैं, वह label नए commit की ओर आगे बढ़ता है। main बिल्कुल वहाँ रहता है जहाँ यह था जब तक आप इस पर स्विच नहीं करते और खुद को वहाँ commit नहीं करते।

आप दोनों labels को git branch के साथ देख सकते हैं:

$ git branch
  forecast
* main

तारांकन चिन्ह उस शाखा को चिह्नित करता है जिस पर आप वर्तमान में हैं। एक शाखा केवल एक नाम है जो एक commit की ओर इशारा करता है। यह पूरी व्यवस्था है। इस अध्याय में बाकी सब कुछ इन labels को चारों ओर घुमाने की भिन्नताएँ हैं।

एक वास्तविक प्रोजेक्ट में, शाखा के नाम जानकारी रखते हैं। एक आम परंपरा परिवर्तन के प्रकार का वर्णन करने वाला एक छोटा उपसर्ग है, जिसके बाद विवरण है: feature/five-day-forecast, fix/broken-date-picker, chore/upgrade-eslint। कुछ teams एक ticket number जोड़ते हैं (feature/wa-142-forecast)। कोई भी परंपरा चुनें, इसे पूरे प्रोजेक्ट में सुसंगत रखें ताकि कोई भी बता सके कि एक शाखा किस लिए है।

जो workflow ये नाम समर्थन करते हैं वह short-lived feature branches है: एक शाखा एक काम के लिए बनाएँ, इसमें commit करें, परिवर्तन की समीक्षा करें और merge करें, फिर शाखा हटाएँ। एक शाखा जो हफ्तों तक रहती है वह main से बहुत दूर चली जाती है, और अंतिम merge जितना लंबा वह drift होता है उतना ही कठिन हो जाता है। सबसे स्वस्थ शाखाएँ दिनों के भीतर समाप्त हो जाती हैं।

एक शाखा Git की अपनी bookkeeping के अंदर छिपी एक छोटी फ़ाइल से ज्यादा कुछ नहीं है। एक बनाने का मतलब उस एक लाइन को लिखना है, यही कारण है कि git branch तुरंत समाप्त हो जाता है भले ही एक repository में वर्षों का इतिहास हो। वही cheapness शाखा को हटाने के लिए भी लागू होता है: अगर Git को कोई स्टेल branch मिली तो कुछ नहीं होता, इसलिए abandoned branches को pile up करने से कुछ नहीं रोकता सिवाय एक team के अपने disci के।

Junoएक शाखा वास्तव में क्या हैgit branch forecast आपके वर्तमान commit पर pointing एक नया label बनाता है, और git switch forecast आपको इस पर ले जाता है। आपकी files के बारे में कुछ नहीं बदलता जब तक आप वास्तव में वहाँ commit नहीं करते। मुझे branches को एक commit पर sticky notes के रूप में सोचना पसंद है: जोड़ने में सस्ता, घुमाने में सस्ता, हटाने में सस्ता जब आप कर लें।

Junoएक शाखा वास्तव में क्या है एक शाखा name एक pointer है, इसलिए एक बनाना कुछ नहीं लगता और उनके बीच स्विच करना तुरंत है। branches को ऐसे नाम दें जो काम का वर्णन करें, जैसे feature/five-day-forecast, और उन्हें short-lived रखें: बनाएँ, commit करें, merge करें, हटाएँ। Long-lived branches वे हैं जो एक routine merge को एक वास्तविक headache में बदल देते हैं।

Junoएक शाखा वास्तव में क्या है एक शाखा वास्तव में एक छोटी फ़ाइल है जो एक commit hash रखती है, यही कारण है कि एक बनाना Git में सबसे सस्ते operations में से एक है। Naming conventions और short-lived branches यही है कि एक team अपने parallel work को कैसे legible रखता है; Git खुद कुछ भी enforce नहीं करता। मैंने छह महीने पहले से काफी abandoned branches साफ किए हैं कि इस बारे में strong opinions हैं।

Branches बनाना और स्विच करना

git branch forecast अपने आप एक label बनाता है बिना आपको वहाँ ले जाए। अधिकतर समय आप दोनों एक साथ चाहते हैं, इसलिए git switch के पास एक shortcut है:

$ git switch -c forecast
Switched to a new branch 'forecast'

-c का अर्थ है "create"। git switch -c दोनों एक शाखा बनाता है और आपको इस पर ले जाता है। वह एकल command है जो आप लगभग हर बार नया काम शुरू करते हैं।

Branches को स्विच करने से आपकी files कौन सा snapshot दिखाते हैं यह बदल जाता है। इसे try करें: नीचे echo लाइन एक एक-कदमीय तरीका है एक नई फ़ाइल बनाने का, src/forecast.js, इसमें एक लाइन के साथ, और बाकी सब कुछ commands हैं जो आप पहले से जानते हैं:

$ git switch forecast
$ echo "# पाँच-दिन पूर्वानुमान logic" > src/forecast.js
$ git add src/forecast.js
$ git commit -m "Start forecast module"
$ ls src
forecast.js  index.js
$ git switch main
Switched to branch 'main'
$ ls src
index.js

फ़ाइल गायब नहीं हुई है। यह forecast शाखा पर रहती है, और main शाखा के snapshot में कभी इसे शामिल नहीं किया गया। forecast पर वापस स्विच करें और यह ठीक वैसे ही फिर से दिखाई दे जाएगी जैसे आपने इसे छोड़ा था।

आप मौजूदा code और tutorials में इसके लिए एक पुराना verb देखेंगे: git checkout forecast git switch forecast के समान ही काम करता है। checkout पुराना है और एक से अधिक काम करता है: जो आप इसे देते हैं उसके आधार पर, यह branches को स्विच कर सकता है या एक फ़ाइल को एक पुराने version में restore कर सकता है, और command name अकेले यह नहीं बताता कि कौन सा होने वाला है। switch और restore उन दो jobs को अलग commands में विभाजित करते हैं ताकि name आपको बताए: switch branches के बीच आपको ले जाता है, restore एक फ़ाइल को वापस वैसे ही डालता है जैसे यह एक दिए गए commit पर दिखता था। नए verbs के लिए पहुँचें; जब आप इसे जंगल में मिलें तब checkout को पहचानें।

checkout तय करता है कि आप इसे क्या देते हैं इसके आधार पर क्या करना है: एक शाखा name branches को स्विच करता है, एक फ़ाइल path उस फ़ाइल को restore करता है, और अगर एक name दोनों से मेल खाता है, तो Git को अनुमान लगाना पड़ता है कि आप किसका मतलब है। वह guesswork बिल्कुल यही है कि command को क्यों दो में विभाजित किया गया। switch केवल branches को बदलता है और restore केवल files को बदलता है, इसलिए एक गलत typed path आपको accidentally एक branch पर स्विच नहीं कर सकता। पुराने scripts और tutorials में वर्षों के लिए checkout की उम्मीद करें; कुछ भी नया लिखते समय switch और restore लिखें।

JunoBranches बनाना और स्विच करनाgit switch -c forecast एक शाखा बनाता है और आपको एक कदम में इस पर ले जाता है, जो आप लगभग हर बार उपयोग करेंगे। Branches को स्विच करने से आपकी files का कौन सा version आप देखते हैं यह बदल जाता है, इसलिए एक branch पर जोड़ी गई एक फ़ाइल दूसरे पर अनुपस्थित है जब तक आप वापस स्विच नहीं करते। कुछ भी खो नहीं जाता है, यह दूसरी शाखा पर parked है।

JunoBranches बनाना और स्विच करनाgit switch -c name एक कदम में बनाता है और ले जाता है। आप पुराने tutorials और codebases में git checkout name को समान काम करते हुए देखेंगे; यह एक पुराने, अधिक overloaded command के तहत एक ही विचार है। दिन-दर-दिन switch के लिए पहुँचें और जब आप checkout देखें तो बिना hesitation के पढ़ें।

JunoBranches बनाना और स्विच करनाcheckout अपनी arguments के आधार पर branch switching और file restoration दोनों को संभालता है, जो बिल्कुल वह ambiguity है जिसे switch और restore हटाने के लिए split किए गए थे। पुराने scripts और tutorials में वर्षों के लिए checkout को पढ़ने की उम्मीद करें; यह अभी भी काम करता है, यह डिफ़ॉल्ट रूप से लिखने के लिए अब command नहीं है।

HEAD और detached HEAD

Git आपको track करता है कि आप वर्तमान में कहाँ हैं एक marker के साथ जिसे HEAD कहा जाता है। आम तौर पर HEAD आपकी वर्तमान शाखा की ओर इशारा करता है, और वह शाखा एक commit की ओर इशारा करती है, इसलिए HEAD हर बार जब आप switch या commit करते हैं तब स्वचालित रूप से आगे बढ़ता है। अगर आप एक विशिष्ट commit को इसके hash द्वारा check out करते हैं, या एक tag (एक निश्चित label एक commit पर pinned, अक्सर एक release को चिह्नित करता है), एक शाखा name के बजाय, HEAD उस एक commit के लिए सीधे attach करता है बजाय एक branch label के। इस state को detached HEAD कहा जाता है।

आप वहाँ स्वतंत्र रूप से देख सकते हैं, और आप commit भी कर सकते हैं, लेकिन कुछ भी उन नए commits की ओर नाम से इशारा नहीं करता। अगर आप एक branch के लिए स्विच करते हैं पहले एक बनाए बिना, वे फिर से खोजना कठिन हो जाते हैं।

$ git switch a1b2c3d
HEAD is now at a1b2c3d Add password strength meter

वह message, "HEAD is now at", Git आपको बता रहा है कि आप branch territory छोड़ गए हैं और HEAD को एक single commit से attach किया है।

रोजमर्रा के काम में आप accidentally यहाँ शायद ही कभी आते हैं। यह अक्सर तब होता है जब आप एक पुरानी tag या एक विशिष्ट commit को देखने के लिए check out करते हैं कि code उस बिंदु पर कैसे व्यवहार करता था, या जब एक build tool एक exact commit को work करने के लिए check out करता है। अगर आप केवल देखना चाहते हैं, तो यह ठीक है: files को browse करें, app चलाएँ, फिर जब आप कर लें तो एक branch पर वापस स्विच करें। अगर आप detached state में रहते हुए कोई परिवर्तन करते हैं जो रखने योग्य है, switch करने से पहले एक branch बनाएँ: git switch -c fix/old-bug उस detached state से commit को एक real label देता है ताकि यह switch से survive हो।

एक detached HEAD द्वारा छोड़ा गया एक commit जिस moment आप switch करते हैं वह हटाया नहीं जाता है। यह unreachable हो जाता है: अभी भी stored, कोई branch, tag, या HEAD इस पर pointing नहीं है। Git उन्हें तुरंत साफ नहीं करता। यह एक reflog रखता है, everywhere HEAD has pointed का एक record, और एक unreachable commit आमतौर पर हफ्तों तक survive करता है जब तक Git वास्तव में इसे अच्छे के लिए delete नहीं करता।

यह आपको वास्तविक समय recovery के लिए देता है, हालांकि यह forever तक नहीं चलता। Switch करने से पहले एक branch बनाना detached work को safe रखता है। एक commit को reflog से वापस निकालना आज काम करता है, लेकिन entry eventually expire हो जाता है और एक commit hash आपके mind से बहुत पहले slip हो जाता है इससे पहले, इसलिए branching को एक habit बनाएँ और reflog को उस दुर्लभ समय के लिए save करें जब आप भूल जाते हैं, Undoing things में covered।

JunoHEAD और detached HEAD HEAD उस commit को चिह्नित करता है जिस पर आप वर्तमान में खड़े हैं, और यह आमतौर पर उस शाखा के साथ ride करता है जिस पर आप हैं। अगर आप एक branch के बजाय एक विशिष्ट commit को check out करते हैं, तो आपको एक detached HEAD मिलता है, और कोई भी नया commit जो आप वहाँ करते हैं उसके पास कोई शाखा name pointing नहीं है। अगर यह कभी होता है और आप काम रखना चाहते हैं, तो किसी और स्विच करने से पहले वहीं एक branch बनाएँ।

JunoHEAD और detached HEAD आप सबसे अधिक संभवतः एक detached HEAD से मिलते हैं जब एक tag या एक पुरानी commit को check out करते हैं look करने के लिए, और यह harmless है जब तक आप केवल reading कर रहे हैं। जिस moment आप कुछ commit करते हैं जो रखने योग्य है, वहीं git switch -c चलाएँ switch करने से पहले इसे एक branch देने के लिए।

JunoHEAD और detached HEAD आमतौर पर HEAD एक शाखा की ओर इशारा करता है, जो एक commit की ओर इशारा करता है। Detached, HEAD सीधे commit की ओर इशारा करता है, इसलिए कुछ भी आप वहाँ जोड़ते हैं उसके पास कोई branch name नहीं है एक बार जब आप switch करते हैं। यह rarely gone for good है क्योंकि reflog एक trail रखता है, लेकिन तीन सप्ताह बाद commit hash को याद रखने पर निर्भर न करें। हमेशा switch से पहले branch बनाएँ।

यह कहाँ जाता है

आपने अब branches बनाए हैं, उनके बीच moved किया है, और देखा है कि main कैसे untouched रहता है जब आप कहीं और experiment करते हैं। अगला सवाल यह है कि एक branch पर काम main में कैसे वापस आता है, जो ठीक वही है जो Merging and conflicts cover करता है। अगर आप move करने से पहले commit history reading पर एक refresher चाहते हैं, History git log, git show, और git diff के माध्यम से चलता है।