🈺 🚢 📶 जीआईटी का उपयोग करते समय जीवन को आसान बनाने के लिए (साथ ही गहरी विसर्जन के लिए सामग्री का चयन) 🙇🏻 🤹 🚘

Surrealistguitarist द्वारा ड्रेगन II का पेड़

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

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

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

हम चीजों को क्रम में रखते हैं

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

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

शाखाओं को तिथि के अनुसार क्रमबद्ध करें

तिथि के अनुसार छंटनी आपकी सभी स्थानीय शाखाओं को दिखाती है, जो आखिरी से शुरू होती है। बहुत आम बात है, लेकिन इसने मुझे कई बार मदद की:

# To sort branches by commit date
git branch --sort=-committerdate

पिछला धागा

यदि आप प्रतिबद्ध नहीं हैं, तो शाखा को स्विच करें, और फिर पिछले एक पर लौटना चाहते हैं? आप शायद इसे शाखाओं की सूची में पा सकते हैं यदि आपको इसके नाम के बारे में कुछ पता है। लेकिन क्या होगा अगर यह एक शाखा नहीं है, लेकिन एक detached HEADविशिष्ट प्रतिबद्ध है?

यह पता चला है कि एक सरल तरीका है:

# Checkout previous branch
git checkout -

ऑपरेटर -सिंटैक्स के लिए एक शॉर्टहैंड @{-1}है जो आपको किसी भी संख्या में चेकआउट पर वापस जाने की अनुमति देता है। इसलिए, उदाहरण के लिए, आपने एक शाखा बनाई feature/thing-a, फिर feature/thing-b, और फिर bugfix/thing-c, पैरामीटर @{-2}आपको वापस लौटा देगा feature/thing-a:

# Checkout branch N number of checkouts ago
git checkout @{-N}

सभी शाखाओं के बारे में जानकारी दिखाएं

ध्वज vअंतिम प्रतिबद्ध पहचानकर्ता और संदेश के साथ सभी शाखाओं की एक सूची दिखाता है। डबल vvइच्छा भी दूरदराज के नदी के ऊपर शाखाओं, स्थानीय शाखाओं के बाद दिखाई देते हैं:

# List branches along with commit ID, commit message and remote
git branch -vv

फ़ाइल ढूंढे

हम सभी इस स्थिति में गिर गए: किसी तरह यह पता चला कि एक फ़ाइल गलत शाखा में छोड़ दी गई थी। क्या करें? फिर से काम करें या एक शाखा से दूसरी शाखा में कोड कॉपी करें? नहीं, सौभाग्य से, एक विशिष्ट फ़ाइल खोजने का एक तरीका है।

विधि थोड़ी अजीब है, जो git checkout -आपको पिछली शाखा में ले जाती है। सामान्य तौर पर, यदि आप --चेकआउट में शाखा के नाम के बाद निर्दिष्ट करते हैं, तो यह आपको उस विशिष्ट फ़ाइल को निर्दिष्ट करने की अनुमति देगा, जिसे आप खोज रहे हैं। आपने बिना किसी संकेत के ऐसे कार्य का अनुमान नहीं लगाया है, लेकिन यदि आप जानते हैं तो यह बहुत सुविधाजनक है:

git checkout feature/my-other-branch -- thefile.txt

स्पष्ट स्थिति

टॉमस लैकोमा नेgit status झंडे की मदद से जारी करने को कम करने के बारे में ट्वीट किया-sb और कहा: "कई सालों से मैं गिट का उपयोग कर रहा हूं, लेकिन किसी ने भी मुझे इस बारे में नहीं बताया।" यह सिर्फ खोई हुई फाइलों को खोजने के बारे में नहीं है। ऐसे समय होते हैं जब समस्या को सरल करना परिवर्तनों को देखना आसान बनाता है।

अधिकांश Git कमांड्स में ये झंडे होते हैं, इसलिए आपको अपने वर्कफ़्लो को कस्टमाइज़ करने के लिए इनका उपयोग करना सीखना चाहिए:

# Usually we would use git status to check what files have changed
git status

# Outputs:
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

modified: README.md

Untracked files:
(use "git add <file>..." to include in what will be committed)

another-file
my-new-file

# Using the flags -sb we can shorten the output
git status -sb

# Outputs:
## master
M README.md
?? another-file
?? my-new-file

पूरी कहानी

ऐसे समय होते हैं जब कुछ पूरी तरह से गलत हो जाता है, उदाहरण के लिए, आपने गलती से मंचन (प्रारंभिक) परिवर्तनों को करने से पहले उन्हें छोड़ दिया। यदि यह git logआपको पिछली स्थिति में लौटने की अनुमति नहीं देता है और उपरोक्त सुझावों में से कोई भी मदद नहीं करता है, तो यह है git reflog।

Git में आपके सभी कार्य जो संदर्भ द्वारा सामग्री को बदलते हैं HEAD@{}(उदाहरण के लिए push/pull/branch/checkout/commit) रिफ्लॉग (संदर्भ लॉग) में आते हैं। वास्तव में, यह आपके सभी कार्यों की कहानी है, चाहे आप किस शाखा में हों। यह वह अंतर है git log, जो किसी विशेष शाखा के लिए परिवर्तनों को दर्शाता है।

आप git showप्रतिबद्ध आईडी के साथ कर सकते हैं - और विशिष्ट परिवर्तन देख सकते हैं। यदि यह वही है जो आप ढूंढ रहे थे, तो यह git checkoutआपको वांछित शाखा में स्थानांतरित कर देगा या आपको एक विशिष्ट फ़ाइल का चयन करने की अनुमति भी दे सकता है, जैसा कि ऊपर दिखाया गया है:

# See the reference log of your activity
git reflog --all

# Look at the HEAD at given point from reflog
git show HEAD@{2}

# Checkout the HEAD, to get back to that point
git checkout HEAD@{2}

Prep फ़ाइलें जो कमिट करने से चूक गईं

चरम मामलों में, यदि यह git reflogआपकी फ़ाइलों को वापस लाने में मदद नहीं करता है (उदाहरण के लिए, आपने मध्यवर्ती फ़ाइलों के साथ एक हार्ड रीसेट चलाया), तो एक और चाल है।

प्रत्येक परिवर्तन को उन ऑब्जेक्ट्स के अंदर संग्रहीत किया जाता .git/objectsहै जो सक्रिय प्रोजेक्ट में फ़ाइलों से भरे होते हैं, इसलिए यह पता लगाना लगभग असंभव है। हालांकि, एक Git कमांड है git fsck, जिसे रिपॉजिटरी में अखंडता (क्षतिग्रस्त फ़ाइलों की उपस्थिति) की जांच करने के लिए उपयोग किया जाता है। हम इसका उपयोग उस झंडे के साथ कर सकते हैं --lost-found, जो उन सभी फाइलों को खोजने के लिए है जो किसी कमिट से संबंधित नहीं हैं। ऐसी फाइलों को "लटकती हुई बूँद" कहा जाता है।

यह कमांड आपको "हैंगिंग ट्री" और "हैंगिंग कमिट" खोजने की अनुमति देता है। यदि आप चाहें, तो आप ध्वज का उपयोग कर सकते हैं --dangling, लेकिन लाभ--lost-foundउस में यह एक फ़ोल्डर में सभी प्रासंगिक फ़ाइलों को निकालता है .git/lost-found। सबसे अधिक संभावना है, एक सक्रिय परियोजना में आपके पास ऐसी कई "फांसी" फाइलें होंगी। गिट में एक कचरा निपटान कमान है जो नियमित रूप से चलती है और उन्हें हटा देती है।

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

# This will find any change that was staged but is not attached to the git tree
git fsck --lost-found

# See the dates of the files
ls -lah .git/lost-found/other/

# Copy the relevant files to where you want them, for example:
cp .git/lost-found/other/73f60804ac20d5e417783a324517eba600976d30 index.html

टीम वर्क में जीआईटी

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

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

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

एक ही पंक्ति समाप्त होती है

डिफ़ॉल्ट रूप से, विंडोज डॉस लाइन एंडिंग्स \r\n(CRLF) का उपयोग करता है , जबकि मैक और लिनक्स यूनिक्स लाइन एंडिंग्स \n(LF) का उपयोग करते हैं, जबकि मैक के पुराने संस्करण \r(CR) का उपयोग करते हैं । इस प्रकार, जैसे-जैसे टीम बढ़ती है, असंगत लाइन एंडिंग की समस्या अधिक होने लगती है। यह असुविधाजनक है, वे (आमतौर पर) कोड को नहीं तोड़ते हैं, लेकिन उनके कारण, कमिट और पूल अनुरोध विभिन्न अप्रासंगिक परिवर्तन दिखाते हैं। अक्सर लोग उन्हें अनदेखा कर देते हैं, क्योंकि सभी गलत लाइन एंडिंग को बदलना और घूमना काफी तकलीफदेह होता है।

एक समाधान है - आप सभी टीम के सदस्यों को स्वचालित लाइन पूरा करने के लिए अपने स्थानीय कॉन्फ़िगरेशन को कॉन्फ़िगर करने के लिए कह सकते हैं:

# This will let you configure line-endings on an individual basis
git config core.eol lf
git config core.autocrlf input

बेशक, आपको इस सम्मेलन और एक शुरुआत के लिए साइन अप करने की आवश्यकता है, जिसे भूलना आसान है। पूरी टीम के लिए यह कैसे करना है? ऑपरेशन एल्गोरिथ्म के अनुसार, Git .git / config रिपॉजिटरी में एक कॉन्फ़िगरेशन फ़ाइल की उपस्थिति के लिए चेक करता है, फिर उपयोगकर्ता के सिस्टम-वाइड कॉन्फ़िगरेशन की ~/.gitconfigजांच करता है और फिर में वैश्विक कॉन्फ़िगरेशन की जांच करता है /etc/gitconfig।

यह सब अच्छा है, लेकिन यह पता चला है कि इनमें से कोई भी कॉन्फ़िगरेशन फ़ाइल रिपॉजिटरी के माध्यम से स्थापित नहीं की जा सकती है। आप रिपॉजिटरी-विशिष्ट कॉन्फ़िगरेशन जोड़ सकते हैं, लेकिन वे टीम के अन्य सदस्यों तक विस्तारित नहीं होंगे।

हालांकि, एक फाइल है जो वास्तव में भंडार के लिए प्रतिबद्ध है। इसे .gitattributes कहा जाता है । डिफ़ॉल्ट रूप से, आपके पास यह नहीं है, इसलिए एक नई फ़ाइल बनाएं और इसे सहेजें*.gitattributes*। यह प्रत्येक फ़ाइल के लिए विशेषताएँ सेट करता है। उदाहरण के लिए, आप द्विआधारी फ़ाइलों में अंतर की गणना करने के बजाय छवि फ़ाइलों से एक्सफ़ हेडर का उपयोग करने के लिए गिट फ़र्क को बाध्य कर सकते हैं। इस स्थिति में, हम वाइल्डकार्ड का उपयोग कर सकते हैं ताकि सेटिंग सभी फाइलों, अभिनय, वास्तव में, पूरे कमांड के लिए एक सामान्य कॉन्फ़िगरेशन फ़ाइल के रूप में काम करे:

# Adding this to your .gitattributes file will make it so all files
# are checked in using UNIX line endings while letting anyone on the team
# edit files using their local operating system’s default line endings.
* text=auto

स्वतः छिपना

यह संकलित फ़ाइलों (जैसे node_modules/) को .gitignore में जोड़ने के लिए प्रथागत है ताकि वे स्थानीय रूप से संग्रहीत हों और रिपॉजिटरी में अपलोड न हों। हालाँकि, कभी-कभी आप अभी भी फ़ाइल अपलोड करना चाहते हैं, लेकिन पूल अनुरोध में बाद में इसे पूरा नहीं करना चाहते हैं।

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

कोड समीक्षा प्रक्रिया में तनाव और संज्ञानात्मक भार को कम करने वाली हर चीज इसकी गुणवत्ता में सुधार करती है और समय कम करती है।

उदाहरण के लिए, आप भंडार में संसाधन फ़ाइलें (परिसंपत्ति) जोड़ना चाहते हैं, लेकिन आप बाद में उन्हें संशोधित और ट्रैक नहीं करने जा रहे हैं, इसलिए आप विशेषताओं के साथ फ़ाइल में निम्न पंक्ति जोड़ सकते हैं:

*.asset linguist-generated

गिट दोष का अधिक बार उपयोग करें

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

एक शक्तिशाली फ़ंक्शन git blame (या git praise, यदि आप चाहते हैं) दिखाता है कि इस कोड के साथ काम करने वाला अंतिम कौन था। हम उसे दोष देने या उसकी प्रशंसा करने नहीं जा रहे हैं, बल्कि सिर्फ स्थिति स्पष्ट करना चाहते हैं। यह स्पष्ट हो जाता है कि कौन सा प्रश्न पूछना है और किससे, जो समय बचाता है।

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

लापता फ़ाइलों के लिए एनालॉग गिट दोष

हाल ही में, हमने देखा कि हमारी टीम के एक डेवलपर ने यह पता लगाने की कोशिश की कि किसने, कब और क्यों एक फाइल को डिलीट किया। ऐसा लगता है कि यह यहाँ मदद कर सकता है git blame, लेकिन यह फ़ाइल में मौजूद लाइनों के साथ काम करता है और यदि फ़ाइल गायब है तो बेकार है।

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

# By using -- for a specific file,
# git log can find logs for files that were deleted in past commits
git log -- missing_file.txt

संदेश टेम्पलेट तैयार करें

प्रतिबद्ध संदेशों को अक्सर सुधारने की आवश्यकता होती है। जल्द या बाद में, टीम के डेवलपर्स इस निष्कर्ष पर आते हैं। सुधार करने के कई तरीके हैं। उदाहरण के लिए, आप आंतरिक प्रोजेक्ट प्रबंधन उपकरण से बग पहचानकर्ताओं को संदर्भित कर सकते हैं, या शायद रिक्त संदेश के बजाय कम से कम कुछ पाठ लिखने के लिए प्रोत्साहित कर सकते हैं।

इस आदेश को हर बार किसी को रिपॉजिटरी क्लोन करने के लिए मैन्युअल रूप से चलाने की आवश्यकता होती है, क्योंकि कॉन्फ़िगरेशन फाइलें रिपॉजिटरी के लिए प्रतिबद्ध नहीं हैं। हालाँकि, यह सुविधाजनक है क्योंकि आप किसी भी नाम के साथ एक आम फ़ाइल बना सकते हैं जो एक प्रतिबद्ध संदेश टेम्पलेट के रूप में कार्य करता है:

# This sets the commit template to the file given,
# this needs to be run for each contributor to the repository.
git config commit.template ./template-file

स्वचालन के लिए पकड़

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

गिट हुक

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

मैनुअल ऑटोमेशन

Git में प्रमुख स्वचालन सुविधाओं में से एक git bisect है। बहुतों ने इसके बारे में सुना है, लेकिन बहुत कम लोग इसका उपयोग करते हैं। लब्बोलुआब यह है कि Git ट्री (कमिट हिस्ट्री) को प्रोसेस कर रहा है और यह खोज रहा है कि त्रुटि कहाँ दर्ज की गई है।

ऐसा करने का सबसे आसान तरीका हाथ से है। आप शुरू करते हैं git bisect start, अच्छे और बुरे कमिट्स (जहां कोई बग नहीं है और जहां बग है) के पहचानकर्ताओं को सेट करते हैं, फिर प्रत्येक कमिट के लिए निष्पादित करें git bisect goodया git bisect badकरें।

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

# Begin the bisect
git bisect start

# Tell git which commit does not have the bug
git bisect good c5ba734

# Tell git which commit does have the bug
git bisect bad 6c093f4

# Here, do your test for the bug.
# This could be running a script, doing a journey on a website, unit test etc.

# If the current commit has bug:
git bisect bad

# If the current commit does not have the bug
git bisect good

# This will repeat until it finds the first commit with the bug
# To exit the bisect, either:

# Go back to original branch:
git bisect reset

# Or stick with current HEAD
git bisect reset HEAD

# Or you can exit the bisect at a specific commit
git bisect reset <commit ID>

चल रहा है: वैज्ञानिक स्वचालन

अपनी वैज्ञानिक डिबगिंग रिपोर्ट में, स्टुअर्ट हल्लोवे नेgit bisect डिबगिंग को स्वचालित करने के लिए कमांड का उपयोग करने का तरीका बताया ।
वह क्लूज्योर पर ध्यान केंद्रित करता है, लेकिन हमें उसकी बात से लाभ उठाने के लिए इस भाषा को जानने की जरूरत नहीं है।

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

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

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

# Begin the bisect
git bisect start

# Tell git which commit does not have the bug
git bisect good c5ba734

# Tell git which commit does have the bug
git bisect bad 6c093f4

# Tell git to run a specific script on each commit
# For example you could run a specific script:
git bisect run ./test-bug

# Or use a test runner
git bisect run jest

हर अतीत की प्रतिबद्धता पर

ताकत git bisectमें से एक इतिहास में गैर-रैखिक तरीके से सभी घटनाओं को बायपास करने के लिए बाइनरी खोज का प्रभावी उपयोग है। लेकिन कभी-कभी एक रैखिक बाईपास की आवश्यकता होती है। आप एक स्क्रिप्ट लिख सकते हैं जो हर कमिट पर कोड के माध्यम से गिट लॉग और साइकल को पढ़ता है। लेकिन एक दोस्त है, जो इसे आपके लिए करेगा git rebase:।

कामरान अहमद ने एक ट्वीट में लिखा rebaseहै कि कौन सा कमिटमेंट टेस्ट पास नहीं करता:

परीक्षण विफल रहता है कि एक प्रतिबद्ध खोजें:
$ git rebase -i --exec "yarn test" d294ae9
कमांड d294ae9 और HEAD के बीच सभी कमानों पर यार्न परीक्षण चलाता है और परीक्षण के क्रैश होने की स्थिति में रुक जाता है।

हमने git bisectइस कार्य के लिए पहले ही विचार कर लिया है , जो अधिक कुशल हो सकता है, लेकिन इस मामले में हम एक उपयोग के मामले तक सीमित नहीं हैं।

रचनात्मकता के लिए एक जगह है। शायद आप एक रिपोर्ट तैयार करना चाहते हैं कि समय के साथ कोड कैसे बदल गया है (या परीक्षणों का इतिहास दिखा), और सिर्फ गिट लॉग को पार्स करना पर्याप्त नहीं है। शायद यह इस लेख में सबसे उपयोगी चाल नहीं है, लेकिन यह दिलचस्प है और एक कार्य दिखाता है, जिसकी वास्तविकता हम पहले नहीं मान सकते थे:

# This will run for every commit between current and the given commit ID
git rebase -i --exec ./my-script

लेख और मैनुअल का चयन आपको Git में गहराई से पहुंचने में मदद करने के लिए

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

एक्सप्लोरर गिट । एक इंटरैक्टिव साइट जो आपको आसानी से समझने में मदद करती है कि आप क्या चाहते हैं।
डांग इट गिट! । कुछ बिंदु पर हम में से प्रत्येक Git में खो सकते हैं और किसी भी समस्या को हल करने का तरीका नहीं जानते हैं। यह साइट सबसे आम समस्याओं में से कई का समाधान प्रदान करती है।
प्रो गिट । यह मुफ्त पुस्तक Git को समझने के लिए एक अमूल्य संसाधन है।
Git Docs. — . , Git Docs, Git (, man git-commit) Git .
Thoughtbot. Git Thoughtbot .
Git. Git.
Git. , … . Git, .
गिट: शुरुआत से उन्नत स्तर तक । माइक रितमुल्लर ने यह उपयोगी लेख लिखा है, जो नौसिखिया उपयोगकर्ताओं के लिए आदर्श है।
छोटी चीजें जो मुझे गित से प्यार है । यह हैरी रॉबर्ट्स का यह लेख था जिसने मुझे एहसास कराया कि शाखाओं में बढ़ते कोड के अलावा, गीट में अभी भी कितनी संभावनाएं हैं।
एटलसियन एडवांस्ड गिट गाइड । ये ट्यूटोरियल इस लेख में वर्णित कई विषयों का विवरण देते हैं।
गीठब पर चिट चिट । Git जैसे टूल के लिए एक अच्छा धोखा पत्र होना हमेशा सुविधाजनक होता है।
घट घट । इस लेख में विभिन्न Git कमांड झंडे का विवरण है और कई उपनामों की सिफारिश की गई है।

लेकिन आप और क्या पढ़ सकते हैं :

जीआईटी का उपयोग करते समय जीवन को आसान बनाने के लिए (साथ ही गहरी विसर्जन के लिए सामग्री का चयन)