गिट बिसेक्ट का उपयोग कैसे करें: अनियमित प्रतिबद्धता निर्धारित करने के लिए यूनिट परीक्षण का उपयोग करना?

Question

मैं गिट के लिए नया हूं और अभी "गिट बिसेक्ट" की खोज की है। यह आमतौर पर तब उपयोग किया जाता है जब आप एक नए लिखित यूनिट परीक्षण (जो पहले नहीं था) का उपयोग कर त्रुटि की जांच कर सकते हैं?

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

1. परीक्षण का मामला लिखें के लिए
2. देखो (जो निश्चित रूप से पहली बार में विफल रहता है) Git का उपयोग कर इस परीक्षण का मामला
3. ठीक का उपयोग कर द्विभाजित त्रुटि को शुरू करने के लिए प्रतिबद्ध त्रुटि और फिक्स (और परीक्षण केस)

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

तो क्या करना है? आमतौर पर गिट बिस्केट का उपयोग कैसे किया जाता है?

Answer 1

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

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

git stash save blah 
git bisect bad (and now I'm on a new commit) 
git stash pop 
mvn clean test 

git stash save blah 
git bisect good 
git stash pop 
mvn clean test 

और बहुत आगे।

Answer 2

पहले, इस प्रयास करने से पहले, सुनिश्चित करें कि आपके git status साफ है बनाने - मैं एक स्क्रिप्ट है कि git reset --hard आह्वान होगा उपयोग करने का सुझाव कर रहा हूँ, इसलिए किसी भी अप्रतिबद्ध परिवर्तन नष्ट हो जाएगा।

ऐसा करने का एक तरीका है सबसे पहले अपने कुछ हालिया परीक्षणों के लिए सोर्स कोड को उस स्थान पर कॉपी करना है जिसे कभी भी भंडार (या कहीं भी भंडार के बाहर) के इतिहास में ट्रैक नहीं किया गया था।

1. अपने स्रोत पेड़
2. में प्रतियां जगह में सबसे हाल ही में परीक्षण परीक्षण चलाता है, वापसी कोड की बचत: फिर एक स्क्रिप्ट है कि लिखें।
3. git bisect कहीं से शुरू करने के लिए देने के लिए कदम 2.

फिर से बचाया वापसी कोड के साथ 1

बाहर निकलता से परिवर्तन का सफाया करने के लिए एक git reset --hard करता है, अच्छे और बुरे के रूप में दो करता अंकन के बाद, आप पहली प्रतिबद्धता को खोजने के लिए git bisect run YOUR-SCRIPT का उपयोग कर सकते हैं जहां हालिया यूनिट परीक्षण विफल रहे होंगे।

इस विधि अनिवार्य है क्या in the documentation for git bisect run सुझाव दिया है, जहां यह कहते हैं:

आप अक्सर एक द्विविभाजित सत्र के दौरान यह है कि मिल सकता है आप अस्थायी संशोधन करना चाहते हैं (उदाहरण के लिए एस/# परिभाषित डीबग 0/# डीबग 1 परिभाषित/एक हेडर फ़ाइल में, या "संशोधन जिसमें इस प्रतिबद्धता की आवश्यकता नहीं है, इस पैच को किसी अन्य समस्या के आसपास काम करने के लिए लागू किया गया है, यह बीज़न में दिलचस्पी नहीं है") परीक्षण में संशोधन के लिए लागू किया गया है।

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

Answer 3

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

1. प्लेस अपनी परियोजना निर्देशिका के बाहर तारीख परीक्षण फ़ाइल करने के लिए अपने ऊपर। यहाँ मैं, यह /tmp/my_test.rb

2. अपने भंडार के अंदर पर है मान लेंगे एक छोटे से खोल स्क्रिप्ट बनाने के लिए, कहते हैं, test_runner.sh:

   #!/usr/bin/env sh  
   cp -f /tmp/my_test.rb test/my_test.rb # This will potentially overwrite some old test file 
   ruby test/my_test.rb # Change for whatever test runner you use 
   test_result=$? 
   git checkout test/my_test.rb # Undoes any changes that might have been made 
   exit $test_result 
   

3. मार्क के रूप में अच्छा/बुरा के रूप में आमतौर पर bisect साथ किया जाता है करता है,।

4. git bisect run test_runner.sh का उपयोग करें और एक कप कॉफी पकड़ो जबकि गिट आपके लिए अपनी बग पाता है।