Git
इस जवाब में GitHub शामिल है क्योंकि कई लोगों ने उस बारे में भी पूछा है।
स्थानीय रिपोजिटरी
Git (स्थानीय रूप से) की एक निर्देशिका है (.git ) है, जिसे आप अपनी फ़ाइलों के लिए प्रतिबद्ध करते हैं और यह आपकी 'स्थानीय रिपॉजिटरी' है। यह एसवीएन जैसी प्रणालियों से अलग है जहां आप दूरस्थ रिपॉजिटरी में तुरंत जोड़ते और प्रतिबद्ध करते हैं।
Git एक फ़ाइल के प्रत्येक संस्करण को संग्रहीत करता है जो पूरी फ़ाइल को सहेजकर बदलता है। यह इस संबंध में SVN से भी अलग है क्योंकि आप डेल्टा परिवर्तनों के माध्यम से इसे 'पुनः बनाए' बिना किसी भी व्यक्तिगत संस्करण पर जा सकते हैं।
Git सभी फाइलों को 'लॉक' नहीं करता है और इस तरह एडिट के लिए 'एक्सक्लूसिव लॉक' की कार्यक्षमता से बचता है (पुराने सिस्टम जैसे pvcs दिमाग में आते हैं), इसलिए सभी फाइल्स को हमेशा ऑफ-लाइन रहते हुए भी एडिट किया जा सकता है। यह वास्तव में विलय (या एक ही फ़ाइल के भीतर!) फाइल को एक अद्भुत काम करता है, जो कि GitHub जैसे दूरस्थ रिपॉजिटरी में खींचने या लाने के दौरान एक साथ होता है। केवल आपको मैन्युअल परिवर्तन करने की आवश्यकता है (वास्तव में एक फ़ाइल को संपादित करना) यदि दो बदलावों में कोड की एक ही पंक्ति (यों) शामिल होती है।
शाखाओं
शाखाएँ आपको मुख्य कोड ('मास्टर' शाखा) को संरक्षित करने, कॉपी (नई शाखा) बनाने और फिर इस नई शाखा में काम करने की अनुमति देती हैं। यदि कार्य में कुछ समय लगता है या मास्टर को बहुत अपडेट मिलते हैं, तो ब्रांच को मर्ज या रिबासिंग (अक्सर बेहतर इतिहास के लिए पसंद किया जाता है और संघर्षों को हल करने में आसान) के लिए मास्टर ब्रांच के खिलाफ किया जाना चाहिए। जब आप काम पूरा कर लेते हैं, तो आप मास्टर रिपॉजिटरी में वापस शाखा में किए गए परिवर्तनों को मर्ज कर देते हैं। कई संगठन प्रत्येक कार्य के लिए शाखाओं का उपयोग करते हैं चाहे वह एक सुविधा, बग या कोर आइटम हो। अन्य संगठन केवल बड़े बदलाव के लिए शाखाओं का उपयोग करते हैं जैसे कि संस्करण उन्नयन।
कांटा: एक शाखा के साथ आप शाखा को नियंत्रित और प्रबंधित करते हैं, जबकि एक कांटा के साथ कोई अन्य व्यक्ति कोड को वापस स्वीकार करने को नियंत्रित करता है।
मोटे तौर पर, शाखाओं को करने के दो मुख्य दृष्टिकोण हैं। पहला यह है कि मास्टर ब्रांच में ज्यादातर बदलाव होते रहें, केवल बड़े और लंबे समय तक चलने वाली चीजों के लिए शाखाओं का उपयोग करना, जैसे कि आप विभिन्न जरूरतों के लिए दो ब्रांच उपलब्ध कराना चाहते हैं। दूसरा, जिससे आप मूल रूप से हर सुविधा के अनुरोध, बग फिक्स या कोर के लिए एक शाखा बनाते हैं और फिर मैन्युअल रूप से निर्णय लेते हैं कि वास्तव में उन शाखाओं को मुख्य मास्टर शाखा में कैसे मिलाएं। यद्यपि यह थकाऊ लगता है, यह एक सामान्य दृष्टिकोण है और वह है जो मैं वर्तमान में उपयोग करता हूं और सिफारिश करता हूं क्योंकि यह मास्टर शाखा क्लीनर रखता है और यह मास्टर है जिसे हम उत्पादन को बढ़ावा देते हैं, इसलिए हम केवल पूर्ण, परीक्षण किए गए कोड, रिबासिंग के माध्यम से और चाहते हैं शाखाओं का विलय।
'करने के लिए' में एक शाखा लाने के लिए मानक तरीका है merge। इतिहास को साफ़ करने के लिए शाखाएँ "विद्रोह" भी हो सकती हैं। यह वर्तमान स्थिति को प्रभावित नहीं करता है और एक 'क्लीनर' इतिहास देने के लिए किया जाता है।
मूल रूप से, विचार यह है कि आप एक निश्चित बिंदु (आमतौर पर मास्टर से) पर आधारित हैं। जब से आप शाखबद्ध हुए हैं, तब से 'गुरु' स्वयं उस शाखा बिंदु से आगे बढ़ गया है। यह 'क्लीनर' होगा (मुद्दों को हल करना आसान होगा और इतिहास को समझना आसान होगा) यदि आपने किसी शाखा में किए गए सभी परिवर्तनों को मास्टर की वर्तमान स्थिति के खिलाफ खेला है तो इसके सभी नवीनतम बदलाव होंगे। तो, प्रक्रिया है: परिवर्तन सहेजें; 'नया' मास्टर प्राप्त करें, और फिर पुन: लागू करें (यह रिबास भाग है) फिर से उस के खिलाफ परिवर्तन। यह जान लें कि मर्ज की तरह ही रिबास, संघर्ष का परिणाम हो सकता है जिसे आपको मैन्युअल रूप से हल करना होगा (यानी संपादित करें और ठीक करें)।
नोट करने के लिए एक दिशानिर्देश:
केवल यदि शाखा स्थानीय है और आपने इसे अभी तक रिमोट पर नहीं धकेला है तो रिबेट करें!
यह मुख्य रूप से है क्योंकि रिबासिंग उस इतिहास को बदल सकता है जो अन्य लोग देखते हैं जिसमें अपने स्वयं के शामिल हो सकते हैं।
ट्रैकिंग शाखाएँ
ये वे शाखाएँ हैं जिन्हें नाम दिया गया है origin/branch_name(जैसा कि सिर्फ विरोध किया जाता है branch_name)। जब आप दूरस्थ रिपॉजिटरी से कोड को / पर धकेल रहे हैं और खींच रहे हैं तो यह वास्तव में वह तंत्र है जिसके माध्यम से ऐसा होता है। उदाहरण के लिए, जब आप git pushएक शाखा को बुलाते हैं building_groups, तो आपकी शाखा पहले origin/building_groupsऔर उसके बाद दूरस्थ रिपॉजिटरी में जाती है। इसी तरह, यदि आप एक करते हैं, तो git fetch building_groupsपुनर्प्राप्त की गई फ़ाइल को आपकी origin/building_groupsशाखा में रखा गया है । फिर आप इस शाखा को अपनी स्थानीय प्रति में मिलाना चुन सकते हैं। हमारा अभ्यास हमेशा एक git fetchऔर एक मैनुअल मर्ज करने की बजाय सिर्फ एक है git pull(जो एक चरण में उपरोक्त दोनों करता है)।
नई शाखाएँ लाना।
नई शाखाएँ प्राप्त करना: एक क्लोन के प्रारंभिक बिंदु पर आपके पास सभी शाखाएँ होंगी। हालाँकि, यदि अन्य डेवलपर्स शाखाएँ जोड़ते हैं और उन्हें दूरस्थ में धकेल देते हैं, तो उन शाखाओं और उनके नामों के बारे में 'पता' करने का एक तरीका होना चाहिए ताकि वे स्थानीय स्तर पर उन्हें खींच सकें। यह एक ऐसा तरीका है git fetchजिसके माध्यम से सभी नई और बदली हुई शाखाओं को ट्रैकिंग शाखाओं (जैसे, origin/) का उपयोग करके स्थानीय रूप से रिपॉजिटरी में प्राप्त किया जाएगा । एक बार fetchएड, कोई git branch --remoteट्रैकिंग शाखाओं को सूचीबद्ध करने और git checkout [branch]वास्तव में किसी दिए गए पर स्विच करने के लिए कर सकता है।
विलय
विलय करना विभिन्न शाखाओं से या एक ही शाखा के विभिन्न संस्करणों से कोड परिवर्तन की प्रक्रिया है (उदाहरण के लिए जब एक स्थानीय शाखा और रिमोट सिंक से बाहर हैं)। यदि किसी ने शाखा में काम विकसित किया है और काम पूरा हो गया है, तैयार और परीक्षण किया गया है, तो उसे masterशाखा में विलय किया जा सकता है । यह तब शाखा में जाने के git checkout masterलिए किया जाता है । मर्ज सभी अलग-अलग फ़ाइलों और यहां तक कि अलग-अलग फ़ाइलों को एक साथ फ़ाइलों में लाएगा । इसका मतलब है कि यह वास्तव में सभी परिवर्तनों को मर्ज करने के लिए फ़ाइलों के अंदर कोड को बदल देगा।mastergit merge your_branch
ऐसा करके जब checkoutसे masterयह भी एक ऐसा करने के लिए अनुशंसा की जाती है git pull origin masterदूरदराज के गुरु के बहुत नवीनतम संस्करण प्राप्त करने के लिए अपने स्थानीय गुरु में विलय कर दिया। यदि दूरस्थ मास्टर बदल गया है, अर्थात moved forward, आपको वह जानकारी दिखाई देगी जो उस दौरान दिखाई देती है git pull। यदि ऐसा है (मास्टर बदला हुआ) तो आपको सलाह दी जाती है git checkout your_branchऔर फिर rebaseइसे मास्टर करने के लिए ताकि आपके परिवर्तनों को वास्तव में 'नए' मास्टर के शीर्ष पर 'पुनःप्ले' किया जा सके। फिर आप अगले पैराग्राफ में दिखाए गए अनुसार मास्टर अप-टू-डेट प्राप्त करना जारी रखेंगे।
यदि कोई टकराव नहीं हैं, तो मास्टर में नए बदलाव जोड़े जाएंगे। यदि संघर्ष होते हैं, तो इसका मतलब है कि समान फ़ाइलों में कोड की समान लाइनों के आसपास परिवर्तन होते हैं जो स्वचालित रूप से विलय नहीं कर सकते। इस मामले git merge new_branchमें रिपोर्ट करेगा कि हल करने के लिए संघर्ष (ओं) हैं। आप फ़ाइलों को संपादित करके (जो उन दोनों में परिवर्तन होंगे) आप उन्हें हल करते हैं, आप जो बदलाव चाहते हैं उनका चयन करते हुए, आप जो बदलाव नहीं चाहते हैं उनकी पंक्तियों को हटाकर और फिर फ़ाइल को सहेज कर रख सकते हैं। परिवर्तनों को चिह्नित किया जाता है जैसे विभाजक ========और <<<<<<<<।
एक बार जब आप कोई विरोध आप एक बार फिर से समाधान कर लिया है git addऔर git commitउन परिवर्तनों को मर्ज जारी रखने के लिए (आप आपका मार्गदर्शन करने के लिए इस प्रक्रिया के दौरान Git से प्रतिक्रिया मिल जाएगा)।
जब प्रक्रिया अच्छी तरह से काम नहीं करती है तो आप पाएंगे कि git merge --abortचीजों को रीसेट करना बहुत आसान है।
इंटरएक्टिव रिबासिंग और स्क्वैशिंग / रीऑर्डरिंग / रिमूविंग कमिट्स
यदि आपने बहुत से छोटे चरणों में काम किया है, उदाहरण के लिए, आप हर दिन 'वर्क-इन-प्रोग्रेस' के रूप में कोड बनाते हैं, तो आप उन कई छोटे-छोटे कामों को 'स्क्वैश' करना चाहते हैं। यह विशेष रूप से उपयोगी हो सकता है जब आप सहकर्मियों के साथ कोड समीक्षा करना चाहते हैं। आप अपने द्वारा किए गए सभी 'चरणों' को फिर से खेलना नहीं चाहते (कमिट के माध्यम से), आप केवल यह कहना चाहते हैं कि इस कार्य के लिए मेरे सभी परिवर्तनों का एक प्रभाव में अंतिम प्रभाव (विस्तार) है।
यह करने के लिए कि क्या यह करने के लिए कि क्या एक ही फ़ाइल या फ़ाइलों को एक से अधिक बार (उस मामले में स्क्वैश करने के लिए बेहतर है) के विरुद्ध है या नहीं, का मूल्यांकन करने के लिए महत्वपूर्ण कारक। यह इंटरेक्टिव रिबासिंग टूल के साथ किया जाता है। यह उपकरण आपको स्क्वैश करने, कमिट्स हटाने, संदेशों को पुन: प्रकाशित करने आदि की अनुमति देता है। उदाहरण के लिए, git rebase -i HEAD~10( नोट: यह एक ~नहीं है- ) निम्नलिखित को लाता है:
हालांकि सावधान रहें और इस उपकरण का उपयोग करें 'अदरक'। एक बार में एक स्क्वैश / डिलीट / रीऑर्डर करें, उस कमिट से बाहर निकलें और सेव करें, फिर टूल को रीटर करें। यदि कमिट्स सन्निहित नहीं हैं, तो आप उन्हें पुनः व्यवस्थित कर सकते हैं (और फिर आवश्यकतानुसार स्क्वैश कर सकते हैं)। आप वास्तव में यहां भी कमिट्स हटा सकते हैं, लेकिन आपको वास्तव में यह सुनिश्चित करने की आवश्यकता है कि जब आप ऐसा करते हैं तो आप क्या कर रहे हैं!
फोर्क्स
गिट रिपॉजिटरी में सहयोग के लिए दो मुख्य दृष्टिकोण हैं। सबसे पहले, ऊपर विस्तृत, सीधे शाखाओं के माध्यम से होता है जिसे लोग खींचते हैं और / से धक्का देते हैं। इन सहयोगियों के पास दूरस्थ रिपॉजिटरी के साथ पंजीकृत एसएसएच कुंजी है। यह उन्हें सीधे उस भंडार में धकेल देगा। नकारात्मक पक्ष यह है कि आपको उपयोगकर्ताओं की सूची को बनाए रखना होगा। अन्य दृष्टिकोण - फोर्किंग - किसी को भी रिपॉजिटरी को 'कांटा' करने की अनुमति देता है, जो मूल रूप से अपने स्वयं के गिट रिपॉजिटरी खाते में एक स्थानीय प्रतिलिपि बनाता है। वे तब परिवर्तन कर सकते हैं और जब एक 'पुल अनुरोध' भेजते हैं (वास्तव में यह उनसे अधिक 'पुश' और वास्तविक रिपॉजिटरी मेंटेनर के लिए एक 'पुल' अनुरोध) स्वीकार किए जाते हैं।
यह दूसरी विधि, कांटे का उपयोग करते हुए, किसी को भंडार के लिए उपयोगकर्ताओं की सूची को बनाए रखने की आवश्यकता नहीं होती है।
GitHub
GitHub (एक रिमोट रिपॉजिटरी) एक दूरस्थ स्रोत है जिसे आप सामान्य रूप से उन प्रतिबद्ध परिवर्तनों को धक्का देते हैं और खींचते हैं यदि आपके पास ऐसा रिपॉजिटरी है (या जोड़ा जाता है), तो स्थानीय और रिमोट वास्तव में काफी अलग हैं। दूरस्थ रिपॉजिटरी के बारे में सोचने का एक और तरीका यह है कि यह एक .gitनिर्देशिका संरचना है जो दूरस्थ सर्वर पर रहती है।
जब आप 'fork' - GitHub वेब ब्राउज़र GUI में आप इस बटन पर क्लिक कर सकते हैं 
- आप अपने GitHub खाते में कोड की एक प्रति ('क्लोन') बनाएँ । आप इसे करते समय पहली बार थोड़ा सूक्ष्म हो सकते हैं, इसलिए सुनिश्चित करें कि आप देखते हैं कि किसका भंडार कोड के नीचे सूचीबद्ध है - या तो मूल स्वामी या 'से कांटा' और आप, जैसे, इस तरह:
एक बार जब आपके पास स्थानीय प्रति हो जाती है, तो आप अपनी इच्छानुसार परिवर्तन कर सकते हैं (स्थानीय मशीन से खींचकर और धक्का देकर)। जब आप संपन्न हो जाते हैं, तब आप मूल रिपॉजिटरी मालिक / व्यवस्थापक को एक 'पुल अनुरोध' प्रस्तुत करते हैं (फैंसी लगता है लेकिन वास्तव में आप बस इस पर क्लिक करते हैं 
:) और वे इसे 'पुल' करते हैं।
एक साथ कोड पर काम करने वाली टीम के लिए अधिक सामान्य है रिपॉजिटरी को 'क्लोन' करना (रिपॉजिटरी की मुख्य स्क्रीन पर 'कॉपी' आइकन पर क्लिक करना)। फिर, स्थानीय रूप से टाइप करें git cloneऔर पेस्ट करें। यह आपको स्थानीय रूप से सेट करेगा और आप GitHub स्थान पर (साझा) पुश और पुश भी कर सकते हैं।
क्लोन
जैसा कि GitHub पर अनुभाग में दिखाया गया है, एक क्लोन एक रिपॉजिटरी की एक प्रति है। जब आपके पास एक दूरस्थ रिपॉजिटरी होती है तो आप git cloneउसके URL के खिलाफ कमांड जारी करते हैं और आप रिपॉजिटरी की एक स्थानीय प्रति या क्लोन के साथ समाप्त हो जाते हैं। इस क्लोन में सब कुछ है , फाइल, मास्टर ब्रांच, अन्य ब्रांच, सभी मौजूदा कमेटी, पूरा शेबंग। यह क्लोन है कि आप अपने जोड़ते हैं और इसके खिलाफ काम करते हैं और फिर दूरस्थ रिपॉजिटरी ही है जो आप उन कमिटों को धक्का देते हैं। यह स्थानीय / दूरस्थ अवधारणा है जो Git (और मर्क्यूरियल के समान सिस्टम) को DVCS ( डिस्ट्रीब्यूटेड वर्जन कंट्रोल सिस्टम) के रूप में अधिक परंपरागत CVS (कोड वर्जन सिस्टम) जैसे SVN, PVCS, CVS इत्यादि के विपरीत बनाती है। आप दूरस्थ रिपॉजिटरी के लिए सीधे प्रतिबद्ध हैं।
दृश्य
मुख्य अवधारणाओं का दृश्य
http://marklodato.github.com/visual-git-guide/index-en.html और http://ndpsoftware.com/git-cheatsheet.html#loc=index पर देखा जा सकता है
यदि आप चाहते हैं कि परिवर्तन कैसे काम कर रहे हैं, तो आप दृश्य उपकरण gitg( gitxmacOS के लिए) को GUI के साथ हरा नहीं सकते हैं, जिसे मैं 'सबवे मैप' (esp। लंदन अंडरग्राउंड) कहता हूं, जो दिखाने के लिए महान है कि क्या किया। कैसे चीजें बदलती हैं, विचलन और विलय, आदि।
आप अपने परिवर्तनों को जोड़ने, प्रतिबद्ध करने और प्रबंधित करने के लिए भी इसका उपयोग कर सकते हैं!
हालांकि gitg / gitx काफी न्यूनतम है, GUI टूल की संख्या का विस्तार जारी है। कई मैक उपयोगकर्ता भाई के कांटे का उपयोग gitx के लिए करते हैं और लिनक्स के लिए, एक बढ़िया विकल्प स्मार्ट-गिट है जो एक सहज ज्ञान युक्त शक्ति प्रदान करता है:
ध्यान दें कि GUI टूल के साथ भी, आप संभवतः कमांड लाइन पर बहुत सारी कमांड करेंगे।
इसके लिए, मेरी ~/.bash_aliasesफ़ाइल में निम्नलिखित उपनाम हैं (जो ~/.bashrcप्रत्येक टर्मिनल सत्र के लिए मेरी फ़ाइल से कहा जाता है ):
# git
alias g='git status'
alias gcob='git checkout -b '
alias gcom='git checkout master'
alias gd='git diff'
alias gf='git fetch'
alias gfrm='git fetch; git reset --hard origin/master'
alias gg='git grep '
alias gits='alias | grep "^alias g.*git.*$"'
alias gl='git log'
alias gl1='git log --oneline'
alias glf='git log --name-status'
alias glp='git log -p'
alias gpull='git pull '
alias gpush='git push '
और मेरी ~/.gitconfigफ़ाइल में निम्नलिखित "गिट एलियाज़" हैं - ये क्यों हैं?
ताकि शाखा पूरा हो (TAB कुंजी के साथ) काम करे!
तो ये हैं:
[alias]
co = checkout
cob = checkout -b
उदाहरण उपयोग: git co [branch]<- शाखाओं के लिए टैब पूरा होने पर काम करेगा।
जीयूआई लर्निंग टूल
आप कुछ आधार अवधारणाओं को सीखने में उपयोगी https://learngitbranching.js.org/ पा सकते हैं । स्क्रीन शॉट:
वीडियो: https://youtu.be/23JqqcLPss0
अंत में, 7 प्रमुख जीवन रक्षक!
आप परिवर्तन करते हैं, उन्हें जोड़ते हैं और उन्हें कमिट करते हैं (लेकिन धक्का नहीं देते हैं) और फिर ओह! आपको एहसास है कि आप मास्टर हैं!
git reset [filename(s)]
git checkout -b [name_for_a_new_branch]
git add [file(s)]
git commit -m "A useful message"
Voila! You've moved that 'master' commit to its own branch !
आप स्थानीय शाखा में काम करते समय कुछ फ़ाइलों को गड़बड़ कर देते हैं और बस अंतिम बार आपके पास जो करना था, उसमें वापस जाना चाहते हैं git pull:
git reset --hard origin/master # You will need to be comfortable doing this!
आप स्थानीय रूप से परिवर्तन करना शुरू करते हैं, आप आधा दर्जन फाइलें संपादित करते हैं और फिर, ओह बकवास, आप अभी भी मास्टर (या किसी अन्य) शाखा में हैं:
git checkout -b new_branch_name # just create a new branch
git add . # add the changes files
git commit -m"your message" # and commit them
आप अपनी वर्तमान शाखा में एक विशेष फ़ाइल को गड़बड़ कर देते हैं और मूल रूप से उस फ़ाइल को 'रीसेट' करना चाहते हैं (परिवर्तन खो देते हैं) कि यह आखिरी बार कैसे था जिसे आपने दूरस्थ भंडार से खींचा था:
git checkout your/directories/filename
यह वास्तव में फ़ाइल को रीसेट करता है (जैसे कई Git कमांड्स इसे अच्छी तरह से नाम नहीं दिया गया है कि यह यहाँ क्या कर रहा है)।
आप स्थानीय रूप से कुछ बदलाव करते हैं, आप यह सुनिश्चित करना चाहते हैं कि आप उन्हें खोते नहीं हैं जब आप एक git resetया करते हैं rebase: मैं अक्सर पूरे प्रोजेक्ट की मैनुअल कॉपी ( cp -r ../my_project ~/) करता हूं, जब मुझे यकीन नहीं होता कि मैं गिट में गड़बड़ कर सकता हूं या महत्वपूर्ण खो सकता हूं परिवर्तन।
आप रिबास कर रहे हैं लेकिन चीजें गड़बड़ हो जाती हैं:
git rebase --abort # To abandon interactive rebase and merge issues
अपनी प्रिट में अपनी Git शाखा जोड़ें PS1( https://unix.stackexchange.com/a/127800/10043 ), उदाहरण के लिए
शाखा है selenium_rspec_conversion।
