एसवीएन और गिट के बीच शाखा के अंतर को समझना

Question

मैं SVN का उपयोगकर्ता हूं और अब मैं Git सीख रहा हूं।

एसवीएन में मैं आमतौर पर अपने स्थानीय मशीन एक रेपो पर चेकआउट करता हूं, जिसमें मेरी परियोजना में सभी शाखाएं शामिल हैं और मैं अपनी शाखा के लिए फ़ोल्डर का चयन करता था जिसे मैं दिलचस्पी रखता हूं और वहां काम करता हूं।

मुझे Git का उपयोग करके एक अंतर दिखाई देता है।

वर्तमान में मैं एक रेपो का क्लोनिंग कर रहा हूं और एक विशिष्ट शाखा का उपयोग कर रहा हूं जो कि gitk का उपयोग कर रही है।

प्रोजेक्ट फ़ोल्डर में केवल उस शाखा की सामग्री है और मैं SVN की तरह सभी शाखाओं को नहीं देख सकता, जो मेरे लिए थोड़ा भ्रमित करने वाला है।

मुझे Git का उपयोग करके अपने स्थानीय भंडार में सभी शाखाओं को देखने का एक आसान तरीका नहीं मिल सकता है।

• मैं जानना चाहूंगा कि क्या मैंने जो गिट प्रक्रिया बताई है वह "मानक" है और कुछ सही है या मैं कुछ याद कर रहा हूं।

• इसके अलावा, मैं यह जानना चाहूंगा कि ऐसी प्रक्रिया को कैसे संभालना है जहाँ मुझे एक ही समय में दो शाखाओं पर काम करने की आवश्यकता है, उदाहरण के लिए, मुझे मास्टर पर एक हॉटफ़िक्स बनाने की आवश्यकता है, लेकिन दूसरी शाखा की सामग्री भी रखें।

• फ़ोल्डर्स को बनाने के लिए एक सिफारिश नाम सम्मेलन क्या है जिसमें Git में रेपो से क्लोन की गई शाखा शामिल है, उदाहरण myproject-branchname?

Comments

दिलचस्प है - आमतौर पर एसवीएन के साथ आप केवल उस ट्रंक या शाखा की जांच करेंगे, जिस पर आप काम कर रहे हैं, लेकिन मैं समझता हूं कि आपका क्या मतलब है।

— होरसकॉल

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

— आलसी बेजर

git cloneसे अधिक svnadmin hotcopyया svnrdump+ svnadmin loadकी तरह है svn checkout। साथ git, आप से बिट और टुकड़े का अनुरोध नहीं करते भंडार; आप संपूर्ण रिपॉजिटरी की नकल करते हैं और स्थानीय स्तर पर इसके साथ काम करते हैं, परिवर्तन को "स्रोत" रिपॉजिटरी में वापस भेजते हैं जब और यदि आपको ऐसा लगता है। Git और Subversion स्रोत नियंत्रण के लिए दो पूरी तरह से अलग मॉडल का उपयोग करते हैं।

— चेपनर

हॉटफ़िक्स चीज़ के बारे में, का उपयोग करने पर विचार करेंgit-flow

— Bakuriu

@LazyBadger यह वर्कफ़्लो नहीं टूटा है यदि यह विकास और सुविधा प्रदान करता है। शाखाओं का उपयोग करने का एक सही तरीका नहीं है।

— आहारबुद्ध

Answer 1

मैं एसवीएन का उपयोगकर्ता हूं और अब मैं जीआईटी सीख रहा हूं।

गिरोह में आपका स्वागत है!

एसवीएन पुनः शिक्षा

SVN में मैं आमतौर पर [...]

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

http://hginit.com ( archive.org पर देखने योएल Spolsky (स्टैक एक्सचेंज का बहुत संस्थापकों में से एक) द्वारा), तेज नहीं Git के लिए एक ट्यूटोरियल है, लेकिन यह शून्य वें अध्याय है, "सबवर्सन पुन: शिक्षा" है करने के लिए SVN से स्विच कर लोगों के लिए उपयोगी किसी भी , वितरित संस्करण नियंत्रण प्रणाली के रूप में यह बताता है कि SVN अवधारणाओं आप (अस्थायी) के लिए है संयुक्त राष्ट्र -learn (या करने के लिए stashदूर के रूप में Git उपयोगकर्ताओं कह सकते हैं) के चारों ओर अपने सिर वितरित सक्षम होने के लिए चादर संस्करण नियंत्रण प्रणाली अवधारणाओं और उनके साथ काम करने के लिए स्थापित मुहावरेदार वर्कफ़्लोज़।

तो आप उस शून्य-वें अध्याय को पढ़ सकते हैं और ज्यादातर "म्यूरियल" शब्द को "Git" से बदल सकते हैं और इस प्रकार Git के लिए अपने और अपने मन को ठीक से तैयार कर सकते हैं।

बारीक अक्षर

(अब आप के लिए इसे छोड़ सकता है।) जबकि तेज और Git और अधिक SVN करने के लिए की तुलना में एक दूसरे के समान हैं, वहाँ रहे हैं उन दोनों के बीच कुछ वैचारिक मतभेद है, तो बयानों और "सबवर्सन पुन: शिक्षा" में सलाह के कुछ तकनीकी रूप से गलत हो जाएगा "Git" के साथ "मर्क्यूरियल" को प्रतिस्थापित करते समय:

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

एसवीएन में, सब कुछ एक निर्देशिका है (लेकिन आपको आवश्यक रूप से इसे इस तरह नहीं मानना ​​चाहिए)

लेकिन मैं आपको बीच में रोक रहा हूं। तुम कह रहे थे?

एसवीएन में मैं आमतौर पर अपने स्थानीय मशीन एक रेपो पर चेकआउट करता हूं, जिसमें मेरी परियोजना में सभी शाखाएं शामिल हैं और मैं अपनी शाखा के लिए फ़ोल्डर का चयन करता था जिसे मैं दिलचस्पी रखता हूं और वहां काम करता हूं।

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

हालांकि यह समानांतर में कई SVN शाखाओं को बदलने के लिए लुभावना हो सकता है, अर्थात AFAIK है कि कैसे SVN का उपयोग करने का इरादा नहीं है। (हालांकि मैं इस बारे में अनिश्चित हूं कि जो विशिष्ट डाउनसाइड उस तरह काम कर रहा है, वह हो सकता है।)

Git में, केवल निर्देशिका निर्देशिका हैं

Git रिपॉजिटरी का हर क्लोन अपने आप में एक Git रिपॉजिटरी है: डिफ़ॉल्ट रूप से, इसे मूल रिपॉजिटरी के इतिहास की पूरी कॉपी मिलती है, जिसमें सभी संशोधन, शाखाएं और टैग शामिल हैं। लेकिन यह हमारे सभी तरह से रखेगा कि: Git इसे फ़ाइल-आधारित डेटाबेस में सॉर्ट करता है, रिपॉजिटरी के रूट फ़ोल्डर के छिपे हुए .git/सबफ़ोल्डर में स्थित है।

लेकिन गैर-छिपी हुई फाइलें आप रिपॉजिटरी फ़ोल्डर में क्या देखते हैं?

जब आप git cloneएक भंडार करते हैं, तो Git कई काम करता है। मोटे तौर पर:

1. यह लक्ष्य फ़ोल्डर बनाता है , और इसमें .git/"डेटाबेस" के साथ सबफ़ोल्डर
2. यह मूल रिपॉजिटरी के डेटाबेस के संदर्भ (टैग, शाखाएं आदि) को स्थानांतरित करता है और नए डेटाबेस में उनकी प्रतिलिपि बनाता है, जिससे उन्हें एक सुव्यवस्थित रूप से संशोधित नाम दिया जाता है जो उन्हें "दूरस्थ" संदर्भ के रूप में चिह्नित करता है।
3. यह सभी संशोधनों (यानी फ़ाइल ट्री स्टेट्स) को स्थानांतरित करता है, जो इन संदर्भों को इंगित करता है, साथ ही सभी संशोधन जो इन संशोधनों को सीधे नए या डेटाबेस में (उनके माता-पिता और पूर्वजों) को इंगित करते हैं और उन्हें संग्रहीत करते हैं, ताकि नए रिमोट वास्तव में नई रिपॉजिटरी में उपलब्ध किसी चीज़ की ओर इशारा करें।
4. यह मूल रिपॉजिटरी की डिफ़ॉल्ट शाखा (आमतौर पर master) के अनुरूप रिमोट रिवीजन पर नज़र रखने वाली एक स्थानीय शाखा बनाता है ।
5. यह उस स्थानीय शाखा की जाँच करता है।

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

Git शाखाओं को देखना और Git शाखाओं के साथ बातचीत करना

वर्तमान में मैं एक रेपो का क्लोनिंग कर रहा हूं और एक विशिष्ट शाखा का उपयोग कर रहा हूं जो कि gitk का उपयोग कर रही है।

gitkI का संस्करण रिपॉजिटरी क्लोन नहीं कर सका। यह केवल रेपो इतिहास को देख सकता है और शाखाएं बना सकता है और शाखाओं की जांच कर सकता है। इसके अलावा, कोई "क्लोनिंग" एक शाखा नहीं है। आप केवल रिपॉजिटरी क्लोन कर सकते हैं।

क्या आपका मतलब है आप का उपयोग कर एक रेपो क्लोन git clone ...और फिर, का उपयोग कर gitk, बाहर की जाँच एक शाखा?

प्रोजेक्ट फ़ोल्डर में केवल उस शाखा की सामग्री है और मैं SVN की तरह सभी शाखाओं को नहीं देख सकता, जो मेरे लिए थोड़ा भ्रमित करने वाला है।

[...]

• मैं जानना चाहूंगा कि क्या मैंने जो git प्रक्रिया बताई है वह "मानक" है और कुछ कैसे सही [...]

हाँ, यह बहुत मानक है:

• एक रिपॉजिटरी का उपयोग करके क्लोन git clone ...
• उस शाखा की जाँच करें जिसे आप git checkout ...किसी ग्राफ़िकल टूल की तरह या उसके साथ काम करना चाहते हैंgikt

मुझे जीआईटी का उपयोग करके अपने स्थानीय भंडार में सभी शाखाओं को देखने का एक आसान तरीका नहीं मिल सकता है।

• [...] या मुझे श्रीमती याद आ रही है।

शायद:

• आप स्थानीय शाखाओं को सूचीबद्ध कर सकते हैं git branch
• आप के साथ git branch -rया सभी शाखाओं के साथ दूरस्थ शाखाओं को सूचीबद्ध कर सकते हैंgit branch -a

• आप इसका उपयोग gitkकरके पूरा इतिहास (सभी शाखाओं के टैग आदि) जो आपके स्थानीय रेपो के बारे में जानते हैं) को देखने के लिए उपयोग कर सकते हैं

  gitk --all
  

समानांतर में कई शाखाओं के साथ कैसे काम करें

• इसके अलावा, मैं यह जानना चाहूंगा कि ऐसी प्रक्रिया को कैसे संभालना है जहाँ मुझे एक ही समय में दो शाखाओं पर काम करने की आवश्यकता है, उदाहरण के लिए, मुझे मास्टर पर एक हॉटफ़िक्स बनाने की आवश्यकता है, लेकिन दूसरी शाखा की सामग्री भी रखें।

यहाँ विभिन्न परिदृश्य हैं:

एक नई (अभी तक बनाई गई) परिवर्तन को कई शाखाओं में लागू करने की आवश्यकता है

इस वर्कफ़्लो का उपयोग करें:

1. cएक संशोधन से एक नई शाखा बनाएँ, जो पहले से ही इन सभी शाखाओं (जैसे संशोधन जो बग को प्रस्तुत करता है, जब परिवर्तन बगफिक्स होगा) या उस संशोधन से (जो इसके सभी पूर्वजों सहित) को प्रस्तुत करने के लिए स्वीकार्य है इन सभी शाखाओं।
2. उस नई शाखा में परिवर्तन करें और करें c।

3. प्रत्येक शाखा के लिए bजो परिवर्तन की आवश्यकता है:

   1. देखें b:

      git checkout b
      

   2. मर्ज cमें b:

      git merge c
      

4. शाखा निकालें c:

   git branch --delete c
   

एक अलग शाखा पर एक मौजूदा बदलाव की आवश्यकता है

(... लेकिन उस परिवर्तन में रहने वाले अन्य परिवर्तनों के बिना, वह परिवर्तन कहाँ रहता है)

1. उस शाखा की जाँच करें जहाँ परिवर्तन की आवश्यकता है
2. चेरी-लेने संशोधन (रों) परिवर्तन करने के क्रम में

एक शाखा पर a, आप एक या कुछ फ़ाइलों को सटीक स्थिति में बदलना चाहते हैं जो उनके पास एक अलग शाखा पर हैंb

1. चेक आउट a

2. फ़ाइल सामग्री शाखा से प्राप्त करें b:

   git checkout b -- path/to/a/file.txt path/to/another/file.cpp or/even/a/complete/directory/ ...
   

   ( git checkoutरास्ते से गुजरने के अलावा , यह शाखा में नहीं जाएगाb , केवल वहां से अनुरोधित फ़ाइल सामग्री प्राप्त करें। ये फाइलें पहले से मौजूद हो सकती हैं या हो सकती हैं a। यदि वे ऐसा करते हैं, तो वे अपनी सामग्री के साथ ओवरराइट हो जाते हैं b।)

एक शाखा पर काम करते समय, आप यह देखना चाहते हैं कि चीजें दूसरी शाखा में कैसी हैं

उस शाखा की जाँच करें जिस पर आप काम करना चाहते हैं।

फिर, दूसरी शाखा को देखने के लिए,

• या तो ग्राफ़िकल टूल का उपयोग करें जो आपको वर्तमान में चेक किए गए संशोधनों की सामग्री को देखने की अनुमति देता है (उदाहरण के gitkलिए "पैच" से "पेड़" के लिए रेडियो बटन स्विच करने की कोशिश)
• या रिपॉजिटरी को एक अस्थायी निर्देशिका में क्लोन करें और वहां दूसरी शाखा देखें
• या उसी रिपॉजिटरी कीgit worktree एक अलग कार्यशील निर्देशिका बनाने के लिए उपयोग करें (यानी अपने वर्तमान स्थानीय रिपॉजिटरी की निर्देशिका में डेटाबेस का उपयोग करके ) जहां आप उस दूसरी शाखा की जांच कर सकते हैं.git/

Comments

अंतिम वर्कफ़्लो के लिए, stashआदर्श है।

— CAD97

@ CAD97 नहीं यदि आप समानांतर में संदर्भ के लिए दूसरे को देखते हुए, पहली शाखा पर काम करना जारी रखना चाहते हैं । git stashअधूरे काम को रास्ते से हटाना अच्छा है, जैसे शाखाओं को स्विच करना और बाद में वापस आना।

— दास-जी

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

— केविन

@ केविन वह हो सकता है। यह कुछ समय पहले मैंने आखिरी बार मरकरी का इस्तेमाल किया है, इसलिए शायद यह अलग था। (या हो सकता है कि यह सिर्फ उस समुदाय का वर्कफ्लो था जिसका मैंने इसके साथ उपयोग किया था।)

— दास-जी

हो सकता है कि एचजी इनिट पाठ "[...] क्योंकि आपको वास्तव में मर्क्यूरियल तरीके से शाखा देना चाहिए था, रिपॉजिटरी को क्लोन करके [...] उस संबंध में भी अपडेट किया जाना चाहिए।

— दास-जी

Answer 2

एसवीएन में मैं आमतौर पर अपने स्थानीय मशीन एक रेपो पर चेकआउट करता हूं, जिसमें मेरी परियोजना में सभी शाखाएं शामिल हैं और मैं अपनी शाखा के लिए फ़ोल्डर का चयन करता था जिसे मैं दिलचस्पी रखता हूं और वहां काम करता हूं।

जब तक आप ट्रंक से ऊपर की निर्देशिका की जांच नहीं करते हैं, तब तक सबवर्सन में आपके पास आमतौर पर स्थानीय रूप से उपलब्ध सभी शाखाएं नहीं होती हैं। Git में सभी सामग्री (संदेश, संदेश, शाखाएं आदि) को हमेशा हर कॉपी पर क्लोन किया जाता है।

वर्तमान में मैं एक रेपो का क्लोनिंग कर रहा हूं और एक विशिष्ट शाखा का उपयोग कर रहा हूं जो कि gitk का उपयोग कर रही है।

संभव नहीं है, ऊपर देखें। आप कर सकते हैं git checkout branch-name, लेकिन आप नहीं कर सकते git clone something branch-name। तोड़फोड़ में, शाखाएँ फ़ोल्डर हैं। Git में, शाखाएँ एक कमिट की ओर संकेत करती हैं।

मुझे जीआईटी का उपयोग करके अपने स्थानीय भंडार में सभी शाखाओं को देखने का एक आसान तरीका नहीं मिल सकता है।

भागो git branch। डिफ़ॉल्ट रूप से यह केवल स्थानीय शाखाओं को दर्शाता है। git branch --remoteदूरस्थ शाखाओं को देखने के लिए उपयोग करें ।

Comments

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

— पाइप

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

— Frozn

@ सबसे पहले, आप वास्तव में केवल एक शाखा का उपयोग करके क्लोन कर सकते हैं --single-branch(यहां तक ​​कि केवल टिप के साथ --depth 1)। गिट के लिए जानी जाने वाली स्थानीय और दूरस्थ शाखाओं के बीच का अंतर केवल एक प्रकार का लेबल है। दूरस्थ शाखाओं को सुदूर स्रोत (अक्सर origin) के नाम से उपसर्ग किया जाता है । स्थानीय शाखाओं में वह उपसर्ग नहीं है। लेकिन अंत में, डेटा स्थानीय रूप से उपलब्ध है (जब तक कि आपने --single-branchकुछ ऐसा ही नहीं किया था )। जब आप git checkout $branchnameऐसी शाखा के साथ चलते हैं जिसके लिए कोई स्थानीय नहीं बल्कि एक दूरस्थ शाखा मौजूद होती है, तो git स्वचालित रूप से एक स्थानीय शाखा "रिमोट" सेट करता है।

— जोनास शफर

"जब तक आप ट्रंक के ऊपर निर्देशिका की जांच नहीं करते हैं" - मेरा अनुभव है कि यह बहुत आम है, क्योंकि यह विलय को बहुत आसान बनाता है। (हालांकि हम संस्करण टैग के बजाय एक "लाइव" शाखा का उपयोग करते हैं, इसलिए यह आमतौर पर कोड की केवल 2-3 प्रतियों के बराबर होता है)

— इजाकाटा

@ इज़काटा "यह विलय को बहुत आसान बनाता है", है ना?

— होरसकॉल

Answer 3

जैसा कि यह git के साथ टैग किया गया है, मुझे आशा है कि मेरे SVN ज्ञान की कमी उपेक्षित है।

वर्तमान में मैं एक रेपो का क्लोनिंग कर रहा हूं और एक विशिष्ट शाखा का उपयोग कर रहा हूं जो कि gitk का उपयोग कर रही है।

आप केवल एक विशिष्ट शाखा ही नहीं, बल्कि पूरे दूरस्थ भंडार का क्लोन बना रहे हैं।

रिपॉजिटरी को डेटाबेस के रूप में सबसे अच्छी तरह से कल्पना की जाती है, इसलिए आप दूरस्थ डेटाबेस की वर्तमान स्थिति का एक क्लोन बना रहे हैं। लेकिन उसके बाद, आप उस डेटाबेस की अपनी प्रति पर काम कर रहे हैं; यदि आप प्रतिबद्ध हैं, तो आप अपने स्थानीय डेटाबेस को बदल देते हैं।

fetchआदेश दूरदराज के एक साथ सिंक में स्थानीय डेटाबेस रखने के लिए प्रयोग किया जाता है।

आमतौर पर उस स्थानीय डेटाबेस से, आप काम करने के लिए एक शाखा की जाँच करते हैं। यह git के लिए आंतरिक मार्कर जैसा कुछ और नहीं है, जहां आपका वर्तमान कार्य शुरू हुआ है।

कहते हैं, आप एक साधारण भंडार पर काम कर रहे हैं, जहाँ इसके अलावा कोई शाखा नहीं है master, आप .git"जादू" का अनावरण करने के लिए फ़ोल्डर में देख सकते हैं:

मान लें कि आपकी अंतिम प्रतिबद्धता (चालू master) थी 182e8220b404437b9e43eb78149d31af79040c66, तो आप ठीक उसी के तहत पाएंगे cat .git/refs/heads/master।

इससे आप एक नई शाखा को छोड़ देते हैं git checkout -b mybranch, आपको फ़ाइल में ठीक उसी सूचक मिलेगा cat .git/refs/heads/mybranch।

शाखाएं "संकेत" से ज्यादा कुछ नहीं हैं। "वर्किंग" मार्कर को कहा जाता है HEAD।

यदि आप जानना चाहते हैं कि आपका स्थान कहां HEADहै:

cat .git/HEADजो कहता है ref: refs/heads/mybranch, उदाहरण के लिए , जो cat .git/refs/heads/mybranchकमिट हैश की ओर इशारा करता है78a8a6eb6f82eae21b156b68d553dd143c6d3e6f

वास्तविक कमिट्स को objectsफ़ोल्डर के तहत संग्रहीत किया जाता है (यह अपने आप में एक विषय कैसे है)।

प्रोजेक्ट फ़ोल्डर में केवल उस शाखा की सामग्री है और मैं SVN की तरह सभी शाखाओं को नहीं देख सकता, जो मेरे लिए थोड़ा भ्रमित करने वाला है।

working directoryएक पूरे के रूप में "गिट-डेटाबेस" के साथ भ्रमित न करें । जैसा कि मैंने ऊपर कहा, आपकी कार्यशील निर्देशिका केवल (शायद) एक सबसेट का स्नैपशॉट है।

मान लें कि आपकी अलग-अलग शाखाएँ हैं, आपकी कार्यशील निर्देशिका केवल उस शाखा पर काम करने के लिए समर्पित है (हालाँकि आप वहाँ से कहीं और काम डाल सकते हैं)।

आमतौर पर, यदि आप यह देखना चाहते हैं कि परियोजना के लिए कौन सी शाखाएँ परिभाषित हैं, तो आपको इसकी संभावना है

• git branch स्थानीय शाखाओं के लिए
• git branch --remote दूरस्थ शाखाओं के लिए
• git branch -a दोंनो के लिए

(या git branch -v)

चूँकि git एक वितरित संस्करण नियंत्रण प्रणाली है जो न केवल संभव है, बल्कि स्थानीय / दूरस्थ विभिन्न शाखाओं को बनाने के लिए प्रोत्साहित किया जाता है।

मेरी विशिष्ट कार्यप्रवाह है:

• एक सुविधा शाखा बंद शाखा
• उसी से डब्ल्यूआईपी (कार्य प्रगति पर) शाखा को शाखा
• हालांकि आप चाहते हैं कि काम करते हैं - भले ही आप एक पंक्ति के बाद प्रतिबद्ध हों; इससे कोई फर्क नहीं पड़ता

जब सुविधा पूरी हो जाती है:

• स्क्वैश / WIPब्रांच को फिर से काम करना (इंटरएक्टिव रिबासिंग के साथ) = उससे एक सिंगल कमिट करें
• WIPशाखा को फ़ीचर शाखा में मर्ज करें और प्रस्ताव करें कि (यदि आप गिथब के साथ काम करते हैं तो उस ऑफ़र को "पुल अनुरोध" कहा जाएगा) स्थिर (मास्टर) शाखा में एकीकृत करने के लिए।

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

यह इस बात पर निर्भर करता है कि आपकी परियोजना कैसे संरचित है:

कहते हैं कि आपके पास एक स्थिर गुरु है। और सुविधाएँ केवल उस स्थिर शाखा से विकसित होती हैं - इसलिए यह आमतौर पर एक सुविधा शाखा के पीछे होती है। तब आपके पास मास्टर पर एक अंतिम प्रतिबद्धता होगी जो कि सुविधा शाखा का मूल होगा।

फिर आप मास्टर ब्रांच पर कमिटमेंट करेंगे और तय कर सकते हैं कि दोनों ब्रांच को एक साथ मर्ज करना है या रिबेज करना है (जो कि यूजर्स के लिए एक तरह का मर्ज है ऐसा कहने के लिए)।

या आप हमेशा शाखाओं (जैसे master) में परिवर्तन करने में सक्षम होते हैं और उन्हें अन्य शाखाओं पर चेरी करते हैं।

जीआईटी में रेपो से क्लोन की गई शाखा को शामिल करने के लिए फोल्डर बनाने के लिए एक सिफारिश नाम कन्वेंशन क्या है, उदाहरण myproject-branchname

यह आप पर निर्भर है।

आमतौर पर, आप रिपॉजिटरी नाम के साथ समाप्त होते हैं।

लेकिन ऐसे मौके आते हैं, जब यह नहीं चाहता है:

उदाहरण के लिए, आप ओह-माई-ज़श को git clone git://github.com/robbyrussell/oh-my-zsh.git ~/.oh-my-zsh यहां पर क्लोन करते हैं .oh-my-zshजिसे स्पष्ट रूप से लक्ष्य के रूप में नामित किया गया है।

Answer 4

Git clone वास्तव में पूरे रिपॉजिटरी को क्लोन करता है, लेकिन आपकी कार्यशील निर्देशिका को डिफ़ॉल्ट (आमतौर पर मास्टर) पर सेट करता है।

आप git branchस्थानीय शाखाओं git branch -rको देखने के लिए या दूरदराज के लोगों को देखने के लिए और फिर git checkoutमौजूदा शाखा पर स्विच करने या वर्तमान शाखा के आधार पर एक नया निर्माण करने के लिए अन्य शाखाओं को देख सकते हैं ।

आपको अधिक विवरण के लिए गिट प्रलेखन को पढ़ना चाहिए, और एटलसियन के पास इस पर कुछ अच्छे लेख हैं।

Answer 5

Git और svn में शाखाएं मौलिक रूप से अलग-अलग चीजें हैं।

Svn में एक शाखा (या एक टैग) रेपो में एक निर्देशिका है।

गिट में एक शाखा (या एक टैग) एक कमिट के लिए एक संकेतक है।

Svn के साथ आप चाहें तो रेपो की जड़ की जांच कर सकते हैं। इसका मतलब है कि आपके पास हर शाखा और टैग एक ही बार में चेक आउट होंगे। Afaict यह svn का उपयोग करने का सामान्य तरीका नहीं है।

एक गिट शाखा एक निर्देशिका नहीं है, इसलिए "रेपो की जड़ की जाँच" करने के लिए कोई संतुलन नहीं है। वहाँ कई काम कर रहे पेड़ों के लिए कुछ समर्थन है तो मुझे लगता है कि आप एक स्क्रिप्ट को एक साथ एक ही समय में हर शाखा को चेकआउट करने के लिए एक साथ कर सकते हैं यदि आप वास्तव में चाहते थे, लेकिन ऐसा होना असामान्य है।

इसके अलावा SVN के साथ वास्तव में एक रेपो है। Git के साथ हर डेवलपर का अपना रेपो है। इसका मतलब है कि डेवलपर्स ऑफ़लाइन काम कर सकते हैं लेकिन इसका मतलब यह भी है कि विभिन्न डेवलपर्स के पास प्रत्येक शाखा पर एक अलग विचार हो सकता है।

निर्देशिकाओं के आधार पर और svn के सरल रैखिक इतिहास मॉडल svn शाखाओं के आधार पर मजबूत इतिहास हैं। यदि आप जानना चाहते हैं कि दिनांक y पर शाखा x क्या था तो आप उस प्रश्न को आसानी से पूछ सकते हैं।

दूसरी ओर गिट शाखाओं में वास्तव में इतिहास नहीं है। वहाँ "reflog" है, लेकिन यह एक दीर्घकालिक इतिहास की तुलना में एक आपदा वसूली तंत्र के रूप में अधिक इरादा है। विशेष रूप से रिफ्लॉग को दूर से नहीं पढ़ा जा सकता है और यह नंगे रिपॉज के लिए डिफ़ॉल्ट रूप से अक्षम है।

पाठ्यक्रम के इतिहास में इतिहास है लेकिन उन इतिहासों में "तारीख z पर रेपो y की शाखा x पर क्या था" के प्रश्न का उत्तर देने के लिए पर्याप्त नहीं है।

मुझे Git का उपयोग करके अपने स्थानीय भंडार में सभी शाखाओं को देखने का एक आसान तरीका नहीं मिल सकता है।

आप "गिट शाखा" लिखकर सभी स्थानीय शाखाओं को सूचीबद्ध कर सकते हैं।

आप "git branch -a" का उपयोग करके सभी शाखाओं को स्थानीय और दूरस्थ दोनों को सूचीबद्ध कर सकते हैं

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

विकल्पों की एक जोड़ी।

आप "अन्य शाखा" पर अपने परिवर्तन कर सकते हैं, वहां अपना काम करने के लिए स्विच करें और फिर वापस स्विच करें।

आप एक अतिरिक्त कार्यशील पेड़ भी बना सकते हैं। सिंटैक्स पर विवरण के लिए Google "गिट-वर्कट्री"।

फ़ोल्डरों को बनाने के लिए एक सिफारिश नाम सम्मेलन क्या है जिसमें Git में रेपो से क्लोन की गई शाखा शामिल है, उदाहरण myproject-branchname?

मुझे नहीं लगता कि एक स्थापित सम्मेलन है। एक साथ कई कार्यशील पेड़ों की जाँच करना अपवाद नहीं नियम है।

Comments

यह उत्तर अधूरा लगता है, क्यों?

— gnat