Git Things

कोड समीक्षा और वर्कफ़्लो

• कुछ टीमें “ship/show/ask” जैसी शैलियाँ अपनाती हैं, जहाँ लेखक तय करता है कि कितनी समीक्षा चाहिए, जिससे छोटे, कम-जोखिम वाले बदलावों के लिए तेज़ मर्ज संभव हो जाता है।
• अन्य लोग तर्क देते हैं कि समीक्षक का चयन लेखक के आत्मविश्वास पर नहीं, बल्कि इस पर अधिक निर्भर होना चाहिए कि प्रभावित कोड को कौन सबसे अच्छी तरह समझता है।
• मुख्य शाखा में “optimistically merge” करके बाद में समीक्षा करने के प्रस्ताव को विरोध मिलता है: आलोचकों का कहना है कि इससे main की विश्वसनीयता घटती है, समीक्षा करने का सामाजिक दबाव हटता है, और जूनियर्स को मर्ज से पहले फ़ीडबैक के जरिए सीखने का अवसर नहीं मिलता।
• दस्तावेज़ और परीक्षण अक्सर PR को रोक देते हैं; सुझावों में docs को first-class मानना शामिल है (उनके बिना PR स्वीकार्य नहीं), इरादे को स्पष्ट करने के लिए पहले docs लिखना, या समीक्षकों द्वारा प्रारंभिक docs का मसौदा तैयार करना ताकि कमियाँ सामने आएँ।

कमिट संदेश और इतिहास

• “minor”/“fix” शैली के संदेशों पर कड़ा मतभेद है: कुछ लोग मानते हैं कि वे बहुत छोटे बदलावों के लिए स्वीकार्य हैं; अन्य ज़ोर देते हैं कि हर कमिट को इरादा व्यक्त करना चाहिए, खासकर blame/bisect डिबगिंग के लिए।
• कई लोग subject में कम-से-कम उच्च-स्तरीय संदर्भ (“what”) चाहते हैं, कभी-कभी ticket ID के साथ; अन्य तर्क देते हैं कि न्यूनतम “why” होना चाहिए, क्योंकि diff पहले से “what” दिखा देता है।
• 50-अक्षरों की subject guideline पर बहस होती है: कुछ इसे पुराने terminals से उपजा और पुरातन मानते हैं; अन्य log और blame जैसे tools में स्किमेबिलिटी के लिए छोटे subjects का बचाव करते हैं। 50 chars लागू करने वाले tools चिढ़ाने वाले माने जाते हैं।
• Squashing बनाम सूक्ष्म कमिट्स को बनाए रखना: कुछ लोग clutter कम करने के लिए squashing पसंद करते हैं; अन्य तर्क देते हैं कि आप --first-parent से “squashed view” की नकल कर सकते हैं और squashing उपयोगी इतिहास को नष्ट कर देता है।

टेस्ट, असफल टेस्ट, और bisect

• पहले एक असफल test commit करने, फिर fix करने वाली सलाह को कम-घर्षण TDD और review के लिए सहायक माना जाता है।
• आलोचकों का कहना है कि यदि failing tests main पर आ जाएँ तो यह git bisect और CI अपेक्षाओं को तोड़ सकता है।
• एक संबंधित सुझाव, जिसमें assertions को समायोजित करके मौजूदा गलत व्यवहार को (TODO के साथ) lock-in किया जाता है, व्यापक रूप से आलोचित है; कई लोग तर्क देते हैं कि tests को कभी भी गलत व्यवहार लागू नहीं करना चाहिए और इसके बजाय उन्हें expected-fail चिह्नित किया जाना चाहिए या हटाया जाना चाहिए।

Rename और history tracking

• कुछ लोगों के लिए Git का content-based rename detection एक विफलता है; वे स्पष्ट move metadata (git mv robustly recorded) चाहते हैं।
• अन्य लोग मौजूदा मॉडल का बचाव करते हैं, यह बताते हुए कि यह file splits/merges और सूक्ष्म moves के across history tracking सक्षम बनाता है, भले ही imperfect हो; git blame -C जैसे flags मदद कर सकते हैं।
• स्पष्ट move metadata जोड़ने के प्रस्ताव complexity, tooling support, और merge conflicts को लेकर चिंता पैदा करते हैं।

Line length और tooling conventions

• Line/subject limits (code के लिए 80–120, commit subjects के लिए ~50–72) को ऐतिहासिक अवशेष और व्यावहारिक पठनीयता के मिश्रण के रूप में चर्चा की जाती है: side-by-side diffs, छोटे laptops, उम्रदराज़ आँखें।
• कुछ लोग ढीली या कोई hard limits न होने और tools को wrap करने देने की वकालत करते हैं; अन्य ज़ोर देते हैं कि छोटी lines पढ़ने में आसान होती हैं और soft limit अत्यधिक जटिल expressions को भी उजागर करती है।

Branching: merge बनाम rebase

• Merge और rebase को अलग tools माना जाता है: shared feature branches और history rewrites के लिए rebase; work integrate करने और मूल commits को संरक्षित रखने के लिए merge।
• कुछ लोग merge commits को conflict resolution के स्पष्ट स्थान के रूप में पसंद करते हैं; अन्य “dragon-filled” merge commits से बचने और main को CI/bisect के लिए linear रखने हेतु rebase करते हैं।