क्या मुझे अपने प्रोजेक्ट के चल रहे बदलावों को सहेजने के लिए गिट स्टैश का इस्तेमाल करना चाहिए और इसे अन्य कंप्यूटरों में एक्सेस करने के लिए गिटबब पर धकेलना चाहिए?

Question

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

मैं GitHub रिमोट ट्रैकिंग के साथ क्लाउड सिंकिंग (जैसे ड्रॉपबॉक्स) को मिक्स नहीं करना चाहता।

मैं केवल अपने कोड से पहले (और इसे धक्का दिया) के अधूरे (और गड़बड़) राज्यों को प्रतिबद्ध किया है ताकि काम जारी रखने के लिए दूसरे कंप्यूटर में खींचने के उद्देश्य से। मुझे पूरा यकीन है कि यह एक बुरा अभ्यास है।

आज, हालांकि, मैं git stashथोड़ी सी गुग्लिंग के बाद आया था । यह मैं क्या जरूरत के लिए सही समाधान के रूप में लगता है।

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

अग्रिम में धन्यवाद!

Comments

मैं इस प्रश्न को ऑफ-टॉपिक के रूप में बंद करने के लिए मतदान कर रहा हूं क्योंकि यह पहले से ही स्टैक ओवरफ्लो

— डेविड अरनो

@DavidArno: मुझे नहीं लगता कि यह एक क्रॉस साइट डुप्लिकेट है। स्टैकओवरफ़्लो प्रश्न "क्या मैं एक्स कर सकता हूँ" के बारे में है और यह एक "एक्स एक्स एक अच्छा अभ्यास है" के बारे में है। बहुत कम में सवाल का मूल कारण अलग है।

— ग्रेग बरगार्ड

@DavidArno अंतिम मैंने जाँच की, "पहले से ही SO पर उत्तर दिया गया" एक प्रश्न को बंद करने का कारण नहीं है।

— रबरडक

Answer 1

मैंने केवल अपने कोड से पहले (और इसे धक्का दिया) के अधूरे (और गन्दे) राज्यों को प्रतिबद्ध किया है ताकि काम जारी रखने के लिए दूसरे कंप्यूटर में खींचने के उद्देश्य से। मुझे पूरा यकीन है कि यह एक बुरा अभ्यास है।

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

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

Comments

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

— 9000

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

— लिएंड्रो

यह भी आपको अपनी शाखा में विलय करते समय एक व्यक्ति के साथ छेड़खानी

— snoopy

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

— बेन

Answer 2

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

यदि आप केवल एक शाखा पर काम कर रहे हैं, तो टूटे हुए कोड के साथ कोई समस्या नहीं है। जब मैं ऐसी ही स्थितियों में एक टूटी हुई प्रतिबद्धता करता हूं, तो इसे दूसरे स्थान पर खींचने के बाद, git reset HEAD~1इसे पूर्ववत करने के लिए करें। बेशक, यह --forceआपके pullsऔर pushesजब आप स्थान बदलते हैं , तो इसका उपयोग करने की आवश्यकता होती है ।

या मैं बस तब तक इंतजार करता हूं जब तक मेरी पहली प्रतिबद्धता और ए git commit --amend। या जब मैं फीचर ब्रांच करता हूं तो मैं सभी टूटे हुए को हटा देता हूं। या मैं सिर्फ अपने इतिहास में कुछ स्पष्ट रूप से चिह्नित टूटे हुए के बारे में चिंता नहीं करता, क्योंकि मैं तब तक नहीं छोड़ता जब तक मैं एक अच्छी जगह पर नहीं होता। बहुत सारे विकल्प हैं।

Comments

मैं --amendयह करने के लिए इस्तेमाल किया जा रहा है --force, हालांकि यह धक्का के लिए आवश्यकता होती है की सिफारिश नहीं होगा । बेहतर केवल एक फेंकने वाली शाखा के लिए प्रतिबद्ध है।

— लेफ्टनैबाउट

Answer 3

stashवास्तव में किसी भी चीज के लिए संतोषजनक नहीं है, लेकिन अपनी कार्य निर्देशिका को "अपनी शाखा को अनजाम" करने के लिए साफ करें; यदि आप तुरंत stash popराज्य वापस नहीं करते हैं तो चीजें बहुत भ्रामक हो जाएंगी।

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

1. जब आपने कुछ अधूरे काम किए हैं और कार्यस्थल को छोड़ने वाले हैं, तो निष्पादित करें git-tmp-commit। यह स्वचालित रूप से एक नई, अनूठी शाखा में सभी बदलाव करेगा।
2. इस शाखा को रिमोट से पुश करें।
3. छोड़ना।
4. जब आप जारी रखना चाहते हैं, तो उस शाखा को फिर से रिमोट से क्लोन करें। मैं ccdस्क्रिप्ट के साथ ऐसा करता हूं , जो वास्तव में एक अस्थायी फ़ोल्डर में खरोंच से सब कुछ की जांच करता है , स्वचालित रूप से सबसे हालिया शाखा का चयन करता है ... लेकिन आप केवल मैन्युअल रूप से प्राप्त कर सकते हैं और temporary-commits/original-branch/YYYY-MM-DD...रेपो के मौजूदा क्लोन से शाखा की जांच कर सकते हैं ।
5. अंत में, "अन-कमिट" के साथ परिवर्तन git-tmp-commit -r। यह आपको मूल शाखा ^† (जैसे master) में वापस ^{लाएगा} और काम निर्देशिका में अस्थायी प्रतिबद्ध के परिवर्तनों को छोड़ देगा, इसलिए आप यहां तब तक जारी रख सकते हैं जब तक कि यह उचित प्रतिबद्ध (या अस्थायी, यदि आपको फिर से छोड़ना नहीं है)।

---

^Only _{जिस तरह से स्क्रिप्ट को अभी लिखा गया है, यह केवल तभी काम करता है जब चेकआउट रेपो में कोई शाखा न होmaster । इसलिए संदेह में, आपको करना होगा git branch -d master; यह स्पष्ट रूप से आदर्श नहीं है ...}