कोड पढ़ने से पहले चलाने वाले 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 प्रक्रिया की शुरुआत बन सकती है

[GN⁺]

Hacker News की राय

• Jujutsu में git analysis commands की जगह इस्तेमाल किए जा सकने वाले उदाहरण साझा किए गए
  पिछले 1 साल में सबसे ज़्यादा बदली गई files, मुख्य contributors, जहाँ bugs ज़्यादा केंद्रित हैं, project की जीवंतता, urgent fixes की frequency आदि को jj log command से देखा जा सकता है
  shell script की तुलना में इसका syntax programming के ज़्यादा क़रीब है, लेकिन याद रखने वाले flags कम हैं

  • मुझे jujutsu version control systems का Nix जैसा लगता है
    जैसे Nix शानदार है लेकिन complexity बढ़ा देता है, jujutsu भी वैसा ही लगा
    कुछ महीनों तक इस्तेमाल करने के बाद मैं फिर git पर लौट आया। git हाथ में बैठ चुका है और हर जगह इस्तेमाल होता है
  • समझ नहीं आता लोग ये custom script languages सब कैसे याद रखते हैं
    jq में array loop ही याद रह जाए तो खुशी होती है, ऐसी syntax तो बिल्कुल समझ में नहीं आती
  • jj हो या git, दोनों के commands इतने लंबे और complex हैं कि इन्हें याद करने का इरादा नहीं है
    अगर बार-बार इस्तेमाल करना हो तो alias बनाकर छोटा कर लूँगा
  • commits नहीं हैं तो इसका मतलब ये नहीं कि project मर चुका है, इसका मतलब उल्टा stable भी हो सकता है
    उदाहरण के लिए एक QR code generation library है जिसमें 10 साल से update नहीं आया, लेकिन वह पूरी तरह सही चलती है
    कभी-कभी लगता है कि क्या बस बेकार commits जोड़ने के लिए bot चला देना चाहिए
  • मैं git को program नहीं करना चाहता, बस काम ख़त्म करना चाहता हूँ
    इसलिए jujutsu जैसे tools से ज़्यादा पारंपरिक UNIX pipe commands पसंद हैं
    Gradle की जगह Maven इस्तेमाल करने की वजह भी यही है

• यह मज़ेदार था कि लेखक ने मान लिया कि developers commit messages अच्छे लिखते हैं
  असलियत में ज़्यादातर “changed stuff” स्तर का ही लिखते हैं
  मेरी तरह commit log को गंभीरता से लेने वाले लोग कम हैं
  AI-generated commit messages इस समस्या में काफ़ी मदद कर सकते हैं

  • यह leadership की समस्या है। अच्छा team lead या CTO commit message quality को लेकर expectations साफ़ करता है
  • जिन teams में PR को squash करके merge किया जाता है, वहाँ PR body ही commit message बन जाती है, इसलिए quality बेहतर होती है
  • squash & merge workflow में आख़िरकार PR title ही मुख्य message बन जाता है
    developer commit messages जैसे चाहें लिख सकते हैं, क्योंकि बाद में वैसे भी कोई नहीं पढ़ता
  • हमारी team Core repos और Non-Core repos को अलग रखती है
    Core में PR review और detailed explanation ज़रूरी हैं, जबकि Non-Core में खुलकर experiment किया जा सकता है
    Core में कभी-कभी commit message code से 20 गुना लंबा होता है, जबकि Non-Core में “hope this works” स्तर चलता है
  • developers commit messages नहीं लिखते, यह culture की समस्या है
    हमारी company में हम एक-दूसरे से इसकी अपेक्षा रखते हैं

• मैंने कई codebases पर commands चलाकर देखे, लेकिन results असली स्थिति से मेल नहीं खाते थे
  उदाहरण के लिए git shortlog -sn --no-merges में सबसे ज़्यादा commits वाला व्यक्ति कभी-कभी कंपनी छोड़ चुका होता है
  commits ज़्यादा होने का मतलब contribution ज़्यादा होना नहीं है

  • इसी वजह से मैं squash-and-merge पसंद करता हूँ
    ज़रूरत से ज़्यादा commits को सिर्फ feature branch में रखा जाए, और main में साफ़-सुथरा merge किया जाए
  • ये commands समस्याग्रस्त projects को diagnose करने में काम आते हैं
    सामान्य codebase में ये अक्सर बस बेअर्थ results देते हैं
  • सच कहूँ तो शक होता है कि लेखक ने खुद commands चलाकर देखे भी थे या नहीं, लेख LLM से लिखा हुआ लगता है
  • अगर automated workflow एक ही व्यक्ति के credentials से चलता है तो stats बिगड़ सकते हैं
  • एक company के central codebase में मेरे commits भी बहुत ज़्यादा हैं
    क्योंकि project मैंने शुरू से बनाया था, जबकि अब दूसरे लोग मुझसे ज़्यादा बार commit करते हैं

• यह बात दिलचस्प लगी कि “सबसे ज़्यादा बदली गई file वही file है जिसे लोग छूने से डरते हैं”

  • यह कुछ वैसा paradox लगता है जैसे “इतना भीड़भाड़ वाला restaurant कि कोई जाता ही नहीं”
  • test करने पर सबसे ज़्यादा edited files अक्सर auto-generated files या entry point जैसी उबाऊ files निकलीं
  • ऐसी commands के साथ warning होनी चाहिए
    सिर्फ output देखकर निष्कर्ष निकालना उल्टा मूर्खतापूर्ण लग सकता है
    असल में ये बस इतना दिखाती हैं कि पिछले 1 साल में किन features पर काम हुआ
  • अगर Churn (बदलाव की आवृत्ति) और Complexity (जटिलता) को साथ देखें तो यह कहीं ज़्यादा उपयोगी होता है
    जहाँ दोनों ऊँचे हों, वही असली problem area होता है
    ऐसे areas जमा होते-होते लोग कहते हैं, “app को शुरू से फिर लिखना पड़ेगा”
  • जिन files से लोग डरते हैं, वे आम तौर पर ज़रूरी और complex files होती हैं
    सबको उन्हें बदलना पड़ता है, लेकिन वे इतनी बड़ी होती हैं कि संभालना मुश्किल हो जाता है

• मैंने git में एक summary alias बनाया है जो branch summary, commit count, author count, file count आदि एक साथ दिखाता है
  idea GitAlias/gitalias से मिला

  • जिज्ञासा है कि इसे .gitconfig function के रूप में क्यों लिखा गया, git-summary script बनाना ज़्यादा आसान लगता है
  • ये commands हर बार हाथ से टाइप करना AI से लिखा लेख जैसा लगता है, असली अनुभवी लोग alias बनाकर दोबारा इस्तेमाल करते हैं
  • script अच्छी है, लेकिन मेरे environment में log-of-count-and-email जैसा command नहीं है
  • local में man page बना ली जाए तो अच्छा होगा

• regex में word boundary (\b) जोड़नी चाहिए
  उदाहरण के लिए “debugger” के अंदर “bug” होने से ग़लत result आ सकता है
  सुधरा हुआ उदाहरण यह है
  git log -i -E --grep="\b(fix|fixed|fixes|bug|broken)\b" ...

  • macOS में \b support नहीं करता, इसलिए -E की जगह Perl regex option -P इस्तेमाल करना होगा
    इसे git log -i -P --grep="\b(...)\b" के रूप में बदला जा सकता है
  • हम भी “rollback” शब्द का दूसरा मतलब लेते हैं, इसलिए filtering ज़रूरी है
  • अच्छा point है, इससे काफ़ी accuracy बढ़ती है

• अगर squash-merge नहीं किया जाए, तो सबसे ज़्यादा commits वाला व्यक्ति उल्टा सबसे ख़राब developer भी हो सकता है
  पहले ऐसा एक व्यक्ति था, जो बार-बार उसी file को ठीक करता रहा और आख़िरकार निकाल दिया गया
  squash ऐसे मामलों को छिपा देने का अच्छा तरीका है

• सिर्फ़ commit count stats पर भरोसा करना मुश्किल है
  कोई व्यक्ति पूरी तरह tested code commit करता है, और कोई दूसरा एक-एक line करके बार-बार commit करता है
  एक commit की value व्यक्ति-दर-व्यक्ति 100 गुना तक अलग हो सकती है

  • लेकिन लेखक का उद्देश्य change trends देखना था
    absolute value से ज़्यादा change rate मायने रखती है

• यह analysis approach Adam Tornhill की “Your Code as a Crime Scene” की याद दिलाती है
  मूल लिंक
  और Developer’s Legacy Index की concept से भी मिलती-जुलती है

  • Tornhill के शुरुआती C-संबंधित लेख मुझे पसंद थे, इसलिए यह देखकर अच्छा लगा

• अगर लेखक हर command का actual output भी दिखाता तो और अच्छा होता
  सिर्फ explanation से ज़्यादा output examples ज़्यादा भरोसेमंद लगते

  • मुझे भी लेख थोड़ा AI से लिखा हुआ लगा, लेकिन फिर भी पाँच commands सीखने को मिलीं, इसलिए बुरा नहीं था