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

Git Security Best Practices

Git security अपनी house key को कभी शेयर की गई किसी photo पर tape न करने जैसा है। Git में committed passwords इसकी memory में हमेशा के लिए रहते हैं, इसलिए secrets बाहर रखें।

In this page:

  1. Secrets को Git से बाहर रखना
  2. Committed Secrets के लिए History Scrub करना
  3. GPG के साथ Commits Sign करना
  4. Remote Access Keys Audit करना
  5. Branch Access Restrict करना
Syntax
bash 
# .gitignore
.env
secrets_file

Secrets को Git से बाहर रखना

Git में committed एक password या API key push होते ही effectively public हो जाती है, क्योंकि Git पूरी history preserve करता है — repo clone करने वाला कोई भी बाद में इसे "remove" करने के बाद भी एक पुरानी commit से निकाल सकता है। secrets को एक untracked .env file में रखें (.gitignore में listed) और इसके बजाय runtime पर load करें।

उदाहरण: Keeping Secrets Out of Git

bash 
echo ".env" >> .gitignore

Committed Secrets के लिए History Scrub करना

एक नई commit में एक secret delete करना इसे हर पहली commit में पूरी तरह intact छोड़ देता है — history default रूप से overwrite नहीं होती। इसे actually हटाने के लिए git filter-repo या BFG Repo-Cleaner जैसे tool से history rewrite करनी होगी, और तब भी आपको leaked credential को compromised मानकर rotate करना चाहिए, क्योंकि पुराने clones में यह अभी भी हो सकता है।

उदाहरण: Scrubbing History for Comitted Secrets

bash 
git filter-repo --path secrets.env --invert-paths

GPG के साथ Commits Sign करना

एक GPG-signed commit आपकी key से जुड़ा एक cryptographic signature carry करता है, जिसे Git (और hosting platforms) verify कर सकते हैं यह prove करने के लिए कि commit really आपसे आई और tampered नहीं हुई — एक protection जो एक plain commit, जो सिर्फ एक name और email record करता है जिसे आप खुद type कर सकते हैं, नहीं देता।

उदाहरण: Signing Commits with GPG

bash 
git commit -S -m "Signed commit"

Remote Access Keys Audit करना

SSH keys और personal access tokens default रूप से खुद expire नहीं होते, इसलिए एक ऐसे laptop की key जो अब इस्तेमाल नहीं होता, या सालों पहले एक one-off script के लिए generated एक token, एक live, भुला हुआ access point बना रह सकता है। unused वालों को regularly review और revoke करना उस gap को बंद करता है।

उदाहरण: Auditing Remote Access Keys

bash 
ssh-add -l
git config --global --get user.signingkey

Branch Access Restrict करना

Branch protection rules (GitHub, GitLab, वगैरह पर available) main जैसी branch में push की अनुमति देने से पहले CI checks pass करना और कम से कम एक approving review की माँग कर सकते हैं, code review को एक social convention से किसी ऐसी चीज़ में बदलते हुए जो platform actually enforce करता है।

उदाहरण: Restricting Branch Access

bash 
# Configured on the hosting platform: require CI checks and reviews before merging to main
Related Topics

Git Commit Message Best Practices · Git Best Practices · Git Common Mistakes · Git Interview Questions

{# 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. .env commit करना और फिर इसे .gitignore में add करना, जबकि secret पहली commits में रहता है और rotate किया जाना ज़रूरी है।
  2. एक नई commit में एक secret हटाना और यह सोचना कि यह गया, जबकि history में अभी भी यह तब तक रहता है जब तक आप git filter-repo जैसे tool से इसे rewrite न करें।
  3. यह मान लेना कि एक private repository secrets के लिए safe है, जबकि access पाने वाला कोई भी, या बाद में एक leak, history पढ़ सकता है।
🔒

Chapter Quiz — Complete all 6 topics to unlock

0/6 topics done

Complete these topics first:

← Previous Lesson Git Commit Message Best Practices Next Lesson → Git Common Mistakes

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.