कोड रिव्यू डिफ, परिणाम और संदर्भ को जुड़ा हुआ रखें

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

रिव्यू सीमा तय करें

पुल रिक्वेस्ट का विवरण, लिंक किया गया इश्यू, बेस ब्रांच और प्रभावित व्यवहार को पढ़ें। GitHub "Files changed" की समीक्षा करने से पहले संदर्भ बनाने की सलाह देता है। सबसे अधिक जोखिम वाली फाइलों और अपेक्षित सत्यापन पर ध्यान दें, फिर एडिटर में मिलान करने वाली रिपॉजिटरी और ब्रांच को खोलें।

जब परिभाषाओं के बीच नेविगेशन आवश्यक हो, तो डिफ को लोकल कोड के बगल में रखें। टेस्ट या बिल्ड आउटपुट को टर्मिनल विंडो में रखें, और उत्पाद पूर्वावलोकन (प्रिव्यू) को तभी खोलें जब बदलाव में उपयोगकर्ता को दिखने वाला व्यवहार हो। वर्तमान संस्करण की जाँच करने के बाद ही फ़ाइलों को रिव्यूड के रूप में चिह्नित करें; फ़ाइल बदलने पर GitHub देखी गई (viewed) स्थिति को साफ़ कर देता है।

साक्ष्य को चर्चा से अलग रखें

विशिष्ट निष्कर्षों के लिए लाइन टिप्पणियों का उपयोग करें, सटीक संपादनों के लिए सुझावों का और क्रॉस-कटिंग निष्कर्षों के लिए रिव्यू सारांश का उपयोग करें। प्रासंगिक होने पर पुल रिक्वेस्ट की स्वचालित जाँच (Checks) की जाँच करें और डिपेंडेंसी बदलावों का निरीक्षण करें। एक ग्रीन चेक स्रोत डिफ को पढ़ने का विकल्प नहीं है।

रिव्यू निर्णय के साथ समाप्त करें

रिपॉजिटरी की रिव्यू नीति और देखे गए साक्ष्य के आधार पर Comment, Approve, या Request changes सबमिट करें। इसके बाद स्थानीय प्रक्रियाओं को रोकें और अस्थायी विंडो बंद करें। Wallo डिफ ब्राउज़र, एडिटर, टर्मिनल और प्रिव्यू विंडो को समूहीकृत कर सकता है, लेकिन इसे पुल रिक्वेस्ट की स्थिति या रिव्यू निर्णय का पता नहीं होता है।