← Back to Git Course | Chapter 8: Best Practices | Lesson 1 of 6

Git Best Practices

अच्छी Git habits -- clear commit messages, focused commits, एक shared branching strategy, एक maintained .gitignore, और share होने से पहले changes review करना -- किसी project की history readable और उसकी collaboration friction-free रखती हैं।

Clear Commit Messages लिखना

एक अच्छा commit message एक छोटी, specific summary line से शुरू होता है जो imperative mood में लिखी होती है, जैसे Added या Fixed के बजाय Add या Fix, और एक optional body जो explain करता है कि change क्यों किया गया, जिस पर future readers खुद diff से कहीं ज़्यादा depend करते हैं।

उदाहरण: Writing Clear Commit Messages

bash
git commit -m "Fix login button not responding on mobile"

Atomic Changes Commit करना

एक atomic commit में exactly एक logical change होता है -- एक single bug fix, एक single feature, या एक single refactor -- साथ bundled कई unrelated edits के बजाय, जो हर commit को दूसरों से independently review, revert, या cherry-pick करना आसान बनाता है।

उदाहरण: Committing Atomic Changes

bash
git add login.js
git commit -m "Fix login validation bug"
git add navbar.css
git commit -m "Fix navbar spacing"

एक Branching Strategy चुनना

एक branching strategy पर agree करना, चाहे एक simple feature-branch workflow हो या Git-flow जैसा एक ज़्यादा structured model, main को हमेशा deployable रखता है, हर change को एक isolated branch देता है जिस पर review हो सके, और same branch पर सीधे conflicting काम होने से बचाता है।

उदाहरण: Choosing a Branching Strategy

bash
git checkout -b feature/checkout-flow main

.gitignore को Up to Date रखना

एक well-maintained .gitignore file, project की life में जल्दी committed, build artifacts, dependency folders, editor settings, और API keys जैसे secrets को version control से पूरी तरह बाहर रखती है, जो उन्हें commit करके बाद में हटाने की कोशिश करने से कहीं ज़्यादा safer और cleaner है।

उदाहरण: Keeping .gitignore Up to Date

bash
echo "node_modules/\n.env\n*.log" > .gitignore
git add .gitignore
git commit -m "Add gitignore"

Commit या Push करने से पहले Review करना

commit करने से पहले staged changes का एक diff review करना, और push करने से पहले local commits की list review करना, leftover debug statements, accidental file inclusions, और unclear commit messages पकड़ता है जब तक वे अभी भी fix करना आसान हों, shared history का हिस्सा बनने से पहले।

उदाहरण: Reviewing Before You Commit or Push

bash
git diff --staged
git log origin/main..HEAD
Related Topics
{# common_mistakes/chapter_summary/browser_support: on Hindi pages the view already swaps in the hi_ translation fields (or blanks these out if untranslated), so this renders correctly for both languages without a lang_code check here. #}
आम गलतियां
  1. fix या update stuff जैसे commit messages लिखना, जो किसी को नहीं बताते कि क्या बदला या क्यों।
  2. एक bug fix, एक refactor और एक नई feature को एक commit में bundle करना, जबकि atomic commits review और revert करना आसान होते हैं।
  3. एक team project पर एक branch और review इस्तेमाल करने के बजाय सीधे main में commit करना।
🔒

Chapter Quiz — Complete all 6 topics to unlock

0/6 topics done

Complete these topics first:

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.