कोड पढ़ने से पहले चलाने वाले Git commands

• नई codebase को समझते समय Git history analysis से project की structure और risk areas को पहचानकर अधिक प्रभावी exploration direction तय की जा सकती है
• पिछले 1 साल में सबसे ज़्यादा बदली गई files ढूँढकर change frequency और bug concentration का cross-analysis करके high-risk code पहचाना जा सकता है
• Contributor distribution और activity trends के आधार पर bus factor, maintenance gaps और knowledge silos की संभावना की जाँच की जा सकती है
• महीनेवार commit counts से team की development speed और momentum में बदलाव ट्रैक किए जा सकते हैं, और Revert·Hotfix frequency से deployment stability का आकलन किया जा सकता है
• ये पाँच commands code की एक भी line खोले बिना project health को जल्दी diagnose करने के practical tools की तरह काम आ सकती हैं

---

कोड पढ़ने से पहले चलाने वाले पाँच Git commands

• नई codebase का analysis करते समय, files खोलने से पहले Git history से project health diagnose करने का यह approach उपयोगी है
  • commit history के माध्यम से इसे किसने बनाया, समस्याएँ कहाँ केंद्रित हैं, और team कितनी स्थिरता से deploy करती है यह समझा जा सकता है

• सबसे ज़्यादा क्या बदलता है

  • command:

    git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20
    

  • पिछले 1 साल में सबसे अधिक संशोधित हुई top 20 files दिखाता है
  • top files अक्सर वे होती हैं जिन्हें team “छूने से डरती” है; जब high churn और ownership avoidance साथ आते हैं, तो वे codebase का सबसे बड़ा burden बन सकती हैं
  • Microsoft Research (2005) के अनुसार change frequency आधारित metrics, complexity metrics की तुलना में defects predict करने में अधिक प्रभावी थे
  • top 5 files को bug concentration command के साथ cross-analyze करके ज़्यादा बदलने वाली और ज़्यादा bugs वाली files को सबसे बड़े risk factor के रूप में पहचाना जा सकता है

• यह code किसने बनाया

  • command:

    git shortlog -sn --no-merges
    

  • commit count के आधार पर contributors की ranking करता है
  • अगर एक व्यक्ति 60% से अधिक हिस्सेदारी रखता है, तो bus factor का जोखिम मौजूद है
  • अगर top contributor पिछले 6 महीनों में सक्रिय नहीं रहा, तो maintenance gap की संभावना है
  • अगर 30 contributors में से पिछले 1 साल में सिर्फ 3 ही सक्रिय हैं, तो developer turnover के कारण knowledge break हो सकता है
  • लेकिन squash-merge strategy इस्तेमाल करने वाली teams में author information merger के पक्ष में distort हो सकती है, इसलिए merge strategy की जाँच ज़रूरी है

• bugs कहाँ केंद्रित हैं

  • command:

    git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20
    

  • bug-related keywords वाले commits के आधार पर bug-prone top 20 files निकालता है
  • इस list को change frequency list से तुलना करके बार-बार बदलने वाली और बार-बार टूटने वाली files को high-risk code के रूप में पहचाना जा सकता है
  • commit message quality के अनुसार result की accuracy बदल सकती है, लेकिन एक rough bug density map के रूप में भी यह काफ़ी उपयोगी है

• project तेज़ हो रहा है या ठहर रहा है

  • command:

    git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c
    

  • महीनेवार commit counts से activity trend को दृश्य रूप में समझा जा सकता है
  • एक स्थिर rhythm, healthy project का संकेत है
  • अगर एक महीने में commit count आधा हो जाए, तो key staff departure की संभावना हो सकती है
  • 6~12 महीनों तक लगातार गिरावट team momentum में कमी का संकेत है, जबकि समय-समय पर तेज़ उछाल और फिर ठहराव batch-style release pattern दिखा सकता है
  • एक वास्तविक उदाहरण में commit velocity chart देखकर CTO ने पहचाना कि “यही वह समय था जब senior engineer गया था”
  • यह data code data नहीं, team data होने के कारण भी अर्थपूर्ण है

• team कितनी बार emergency response में जाती है

  • command:

    git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'
    

  • Revert·Hotfix frequency मापता है
  • साल में कुछ बार होना सामान्य है, लेकिन अगर यह हर 2 हफ़्ते में हो रहा है, तो यह deployment process पर अविश्वास का संकेत है
  • यह unstable testing, staging की कमी, और complex rollback procedures जैसी गहरी समस्याओं का लक्षण हो सकता है
  • अगर result 0 है, तो team स्थिर हो सकती है या commit messages सटीक नहीं हैं
  • crisis patterns साफ़ दिखाई देते हैं, और सिर्फ़ उनका मौजूद होना भी reliability का अंदाज़ा देने के लिए काफ़ी है

निष्कर्ष

• ये पाँच commands कुछ ही मिनटों में चलाई जा सकती हैं, और code की एक भी line खोले बिना कहाँ से पढ़ना शुरू करना चाहिए इसकी दिशा दिखाती हैं
• इससे पहले दिन बिना दिशा के खोजबीन करने के बजाय problem areas पर केंद्रित systematic code analysis संभव होता है
• यह प्रक्रिया codebase audit के पहले एक घंटे के बराबर है, और इसके बाद एक हफ़्ते तक चलने वाली analysis प्रक्रिया की शुरुआत बन सकती है