कुछ डेवलपर्स "interdiff" कोड रिव्यू क्यों पसंद करते हैं

 (gist.github.com/thoughtpolice)
3 पॉइंट द्वारा GN⁺ 2024-09-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें

कुछ लोग "interdiff" कोड रिव्यू क्यों पसंद करते हैं

Gerrit कोड रिव्यू टूल का आकलन

  • Gerrit एक open source कोड रिव्यू टूल है, जो Git repository के साथ काम करता है
  • repository में patch लिखकर उसे review के लिए submit किया जा सकता है
  • दूसरे लोग लिखे गए कोड की समीक्षा करते हैं और उन समस्याओं की ओर इशारा करते हैं जिन्हें ठीक करना चाहिए
  • कोड रिव्यू आम तौर पर एक अच्छा विचार है
  • open source projects में कोड merge हो सकता है, जिससे जिम्मेदारी और technical debt बढ़ती है

अलग-अलग कोड रिव्यू टूल

  • Gerrit, GitHub, Phabricator, bug tracker में .patch file upload करना, git send-email के ज़रिए email भेजना आदि जैसे कई टूल मौजूद हैं
  • हर टूल अलग-अलग स्तर तक काम कर सकता है

आदर्श patch series

  • 3 patch series codebase के विकास को चरण-दर-चरण दिखाती है
  • बदलाव तार्किक रूप से अलग होने चाहिए, और हर patch ऐसा पढ़ा जा सके मानो वह अलग से लागू किया गया हो
  • कोड रिव्यू के ज़रिए ऐसी आदर्श series की समीक्षा की जाती है

GitHub का कोड रिव्यू तरीका: "diff soup"

  • GitHub मूल commit के ऊपर नए commits जोड़कर review करने को प्रोत्साहित करता है
  • यह UX design और कई अन्य कारणों से हुआ है
  • review प्रक्रिया में जब कई commits जुड़ते जाते हैं, तो commits के बीच के implicit संबंध जटिल हो जाते हैं
  • git blame और git bisect टूल्स का उपयोग कठिन हो जाता है

बेहतर तरीका: "interdiff" रिव्यू (AKA git range-diff)

  • नए commits जोड़ने के बजाय, मूल commits के नए versions प्रकाशित किए जाते हैं
  • git range-diff का उपयोग करके commit versions के बीच का अंतर तुलना किया जाता है
  • reviewer को पूरा diff दोबारा पढ़ने की ज़रूरत नहीं होती, और वह incremental review कर सकता है
  • git blame और git bisect टूल्स अधिक भरोसेमंद तरीके से काम करते हैं

बीच में एक स्पष्टीकरण: patch merge strategy

  • ऊपर का तरीका merge strategy से स्वतंत्र है (जैसे git rebase बनाम multi-parent git merge commit)

बीच में एक स्पष्टीकरण: क्या git rebase बुरा है?

  • git rebase ठीक है। बस इसे उन public branches पर इस्तेमाल नहीं करना चाहिए, जिन पर दूसरे लोग अपने commits आधारित करेंगे

अन्य नोट्स

निष्कर्ष

  • interdiff review system ऐसे patches को बढ़ावा देता है जो छोटे हों और जल्दी main branch में merge हो जाएँ
  • यह reviewer और author, दोनों के लिए बेहतर कोड रिव्यू अनुभव देता है

GN⁺ का सारांश

  • यह लेख कोड रिव्यू टूल्स और methodology का गहन विश्लेषण देता है
  • interdiff review तरीका कोड रिव्यू की दक्षता को काफी बेहतर बना सकता है
  • यह GitHub की "diff soup" समस्या को हल करने में मदद करता है
  • कोड रिव्यू टूल चुनते समय विचार करने योग्य महत्वपूर्ण पहलुओं को सामने रखता है
  • समान सुविधाओं वाले टूल्स में GitHub, Gerrit, Phabricator आदि शामिल हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-09-12
Hacker News राय

  • GitHub में आम तौर पर इस्तेमाल होने वाला workflow काफी मेहनत वाला है और सहयोगियों के लिए स्पष्ट नहीं है

    • reviewer को feedback शामिल करने के बाद का diff दिखाया जा सकता है, जिससे git blame और git bisect नहीं टूटते
    • reviewer feedback को शामिल करते समय git commit --fixup <업데이트할 커밋의 해시> का उपयोग किया जाता है
    • PR approve होने पर git rebase --interactive origin/main --autosquash का उपयोग करके fixup commit को मूल commit के साथ जोड़ दिया जाता है
    • अंत में git push --force-with-lease का उपयोग करके merge किया जाता है
    • लंबे commands आसानी से टाइप करने के लिए auto-complete फीचर का उपयोग किया जाता है

  • GitHub का code review तरीका अक्षम है, इसलिए Phabricator का उपयोग करके इसे मैन्युअली संभाला गया

    • अगर explicit UI हो तो और बेहतर होगा

  • GitHub के code review तरीके से बेहतर system चाहिए

    • छोटे bug fix patch को जल्दी merge करना है और review scope को सीमित रखना है
    • अलग review/PR बनाने की बात कही जाती है, लेकिन इससे patch set के बीच dependency की समस्या आती है

  • code review के लिए नया approach देखना हमेशा दिलचस्प होता है

    • patches को अलग dependent PRs में बांटने पर विचार किया गया था
    • GitContext जैसे tools का उपयोग करने पर PR छोटे रखे जा सकते हैं और dependency भी बनी रहती है
    • AI का उपयोग करके PR और reviews का summary बनाया जा सकता है और सटीक commit message तैयार किए जा सकते हैं
    • reviewer पिछली review के बाद हुए बदलाव ही देख सकता है

  • Review Board ने सबसे पहले interdiffs पेश किए थे, और यह code review में बहुत उपयोगी है

    • fix-it commit उचित विकल्प नहीं हैं
      1. upstream changes का पता नहीं चलता
      2. commit graph जटिल हो जाता है
      3. हर कोई Git का उपयोग नहीं करता
    • interdiffs reviewer को पहले review request से लेकर सभी updates को ट्रैक करने देते हैं
    • कई commits को एक review request के रूप में पोस्ट करते समय यह उपयोगी होता है

  • Gerrit code review system का उपयोग करने का अनुभव है, और GitHub का code review अक्षम है

    • Gerrit कई patches को stack के रूप में रखने का support देता है, जिससे छोटे patches की review आसानी से हो जाती है
    • GitHub का interface forum thread जैसा दिखता है, और rebase को ट्रैक नहीं कर सकता

  • कई तरह के code review systems इस्तेमाल किए हैं, और हर system के अपने फायदे और नुकसान हैं

    • Critique, Google के monorepo और custom VCS के लिए optimized है
    • Gerrit reviewer के लिए अच्छा है, लेकिन author के लिए असुविधाजनक है
    • GitHub author-friendly है, लेकिन reviewer और team के लिए अक्षम है
    • बेहतर code review tools का उपयोग करना महत्वपूर्ण है

  • Gerrit code review system इस्तेमाल करने के बाद, GitHub के stack PR असुविधाजनक लगते हैं

    • GitHub code review comments पर हुए बदलावों को ठीक से नहीं दिखाता
    • कुछ scripts का उपयोग करके stack PR पर काम करना आसान बनाया गया
    • ejoffe/spr और spacedentist/spr जैसे tools उपयोगी हैं