एक खोजयोग्य Git चीट शीट जो सेटअप, दैनिक कमिट लूप, ब्रांचिंग, रिमोट्स, इतिहास और रिकवरी को कवर करती है, हर कमांड के लिए वन-क्लिक कॉपी के साथ।
याद रखने लायक उनचालीस Git कमांड। कमांड नामों और विवरणों में फ़िल्टर करें, फिर जिसकी ज़रूरत है उसे कॉपी करें। सेटअप, दैनिक वर्कफ़्लो, ब्रांचिंग, रिमोट्स, इतिहास और गलतियाँ सुधारने के अनुसार समूहीकृत।
कोई कमांड उस फ़िल्टर से मेल नहीं खाता।
Git के सौ से अधिक porcelain कमांड हैं, लेकिन अधिकांश इंजीनियर हर दिन उसी बीस-तीस कमांड का उपयोग करते हैं और शेष का साल में कुछ बार ही सहारा लेते हैं। एक चीट शीट समझ का विकल्प नहीं है; यह इसलिए है ताकि जिन कमांड्स को आप पहले से समझते हैं वे एक कीस्ट्रोक दूर बने रहें, न कि एक ब्राउज़र टैब और तीन Stack Overflow उत्तर दूर।
इस पृष्ठ पर संदर्भ उसी तरह समूहीकृत है जैसे काम वास्तव में होता है: रिपॉज़िटरी सेट करना, दिन में दर्जनों बार चलने वाला कमिट लूप, ब्रांचिंग, रिमोट से बात करना, इतिहास पढ़ना, और मुसीबत से बाहर निकलना। फ़िल्टर बॉक्स में टाइप करें और सूची कमांड टेक्स्ट और उसके विवरण दोनों में संकरी हो जाती है, इसलिए "stash", "force" या "undo" खोजने से संबंधित पंक्तियाँ तुरंत सामने आती हैं। हर पंक्ति में एक कॉपी बटन है, क्योंकि --force-with-lease वाले कमांड को फिर से टाइप करना ही टाइपो का कारण बनता है।
लगभग हर Git कमांड तब समझ में आता है जब आप अपने दिमाग में तीन जगह रखते हैं। working tree वे फ़ाइलें हैं जो डिस्क पर आपके एडिटर में दिखती हैं। index — जिसे staging area भी कहा जाता है — वह स्नैपशॉट है जिसे आप अगले कमिट के लिए जोड़ रहे हैं। repository पहले से रिकॉर्ड किए गए कमिट्स की अपरिवर्तनीय श्रृंखला है। git add वर्किंग ट्री से इंडेक्स में कंटेंट ले जाता है, git commit इंडेक्स को एक नए कमिट में बदलता है, और git restore कंटेंट को विपरीत दिशा में वापस धकेलता है।
ब्रांचेस दूसरा विचार हैं, और वे दिखने से सरल हैं: एक ब्रांच बस एक कमिट की ओर एक चलायमान संकेतक है, और HEAD उस ब्रांच की ओर संकेतक है जिस पर आप हैं। एक ब्रांच बनाने में कुछ नहीं लगता क्योंकि यह चालीस-वर्ण के हैश वाली एक फ़ाइल लिखता है। यही कारण है कि git switch -c पाँच मिनट के प्रयोग के लिए इस्तेमाल करने के लिए पर्याप्त सस्ता है।
मर्जिंग और रीबेसिंग दोनों दो ब्रांचों का काम जोड़ते हैं; वे इसमें भिन्न हैं कि वे क्या रिकॉर्ड करते हैं। एक मर्ज दोनों इतिहासों को रखता है और एक कमिट जोड़ता है जो उन्हें जोड़ती है, जो ईमानदार है लेकिन एक ब्रेडेड ग्राफ़ बनाती है। एक रीबेस आपके कमिट्स को फिर से लिखता है ताकि वे दूसरी ब्रांच के ऊपर लिखे गए लगें, जो एक साफ़ सीधी रेखा बनाता है लेकिन कमिट हैश बदल देता है — जो बिल्कुल वही कारण है कि आप कभी भी उन कमिट्स को रीबेस नहीं करते जिन्हें दूसरों ने पहले ही पुल कर लिया है।
Git के बारे में जानने योग्य सबसे उपयोगी बात यह है कि यह बहुत कम ही कमिट किया गया काम खोता है। जब तक कोई परिवर्तन किसी समय कमिट किया गया था, git reflog आपको हैश दिखाएगा, और git switch -c rescue <hash> उसे वापस लाएगा। वह सुरक्षा जाल खराब रीबेस, कमिट के बाद अकस्मात reset --hard, और थोड़ी ज़्यादा उत्सुकता से डिलीट की गई ब्रांचेस को कवर करता है।
खतरनाक ऑपरेशन वे हैं जो अकमिट किए गए काम को छूते हैं: git reset --hard, बदली हुई फ़ाइल पर git checkout --, और git clean -fd। उनमें से कोई भी बदलाव कभी रिकॉर्ड नहीं हुआ, इसलिए रेफ़लॉग को इंगित करने के लिए कुछ नहीं है। बनाने लायक आदत यह है कि एक स्क्रैच ब्रांच पर जल्दी और बार-बार कमिट करें, या किसी भी प्रयोग से पहले git stash push करें। एक कमिट जिसे आप बाद में स्क्वैश कर देते हैं उसकी कोई कीमत नहीं; अकमिट किए गए काम की एक दोपहर वापस नहीं आती।
शेयर्ड ब्रांचेस पर, इतिहास को रीराइट करने के बजाय git revert को प्राथमिकता दें। यह एक पुराने कमिट को उलटने वाला एक नया कमिट रिकॉर्ड करता है, इसलिए हर किसी के क्लोन वैध बने रहते हैं। अपनी खुद की फ़ीचर ब्रांच के लिए --force-with-lease को आरक्षित रखें, और ध्यान दें कि यह सादे --force से वास्तव में सुरक्षित है: यह तभी मना कर देता है जब से आपने अंतिम बार फ़ेच किया है रिमोट हिल गया हो, जो बिल्कुल वही स्थिति है जहाँ एक सादा फ़ोर्स पुश चुपचाप सहयोगी के कमिट्स नष्ट कर देगा।