git init and Config

The plain-language idea

git init does one thing: it creates a .git directory in the current folder and turns it into a repository. Nothing gets committed, nothing gets tracked automatically — it just gives the folder the object store and refs structure from the previous lesson to write into.

Config is separate from that, and it's layered. Git reads settings from three places, each overriding the one before it: system (every user on the machine), global (your user account, ~/.gitconfig), and local (just this one repo, .git/config). The two you'll set on day one — your name and email — get baked into every commit you make, permanently, as part of the commit object itself. Get them wrong and every commit in a repo's history carries the wrong author until someone rewrites it.

See it in a real thing: first-time setup

$ git config --global user.name "Adesh Shukla"
$ git config --global user.email "shuklaadesh7@gmail.com"
$ git config --global core.editor "code --wait"
$ git config --global init.defaultBranch main

That last one matters more than it looks — without it, every git init creates a branch called master, because that's still Git's built-in default. Setting init.defaultBranch once means every new repo you create starts on main instead.

Check what actually landed, and where it came from:

$ git config --list --show-origin
file:C:/Users/adesh/.gitconfig    user.name=Adesh Shukla
file:C:/Users/adesh/.gitconfig    user.email=shuklaadesh7@gmail.com
file:C:/Users/adesh/.gitconfig    core.editor=code --wait
file:C:/Users/adesh/.gitconfig    init.defaultbranch=main

Now actually start a repo, and override the email just for this one project (common if you use a different email for work vs personal repos):

$ mkdir my-project && cd my-project
$ git init
Initialized empty Git repository in my-project/.git/

$ git config user.email "adesh@work-company.com"
$ git config --list --show-origin | grep email
file:C:/Users/adesh/.gitconfig       user.email=shuklaadesh7@gmail.com
file:.git/config                     user.email=adesh@work-company.com

The local value in .git/config wins for this repo only — the global one is untouched everywhere else.

Before the first commit, set up .gitignore so you don't accidentally commit build output, dependencies, or secrets:

# .gitignore
node_modules/
dist/
.env
*.log
.DS_Store

A .gitignore entry only stops Git from offering to track a new file — it does nothing for a file that's already committed. If node_modules/ somehow got committed before you added the ignore rule, you have to explicitly git rm -r --cached node_modules to untrack it; adding the line alone won't remove it from history.

What people usually miss

Watch out

• .gitignore doesn't retroactively untrack files. If a file is already committed, ignoring it going forward does nothing — you need git rm --cached <file> first, then the ignore rule keeps it out from then on.
• git config without --global writes to the local repo, silently. Running it inside a repo by habit, meaning to set it globally, quietly creates a per-repo override that only bites you later when commits from that one repo show the wrong identity.
• Global config isn't retroactive either. Changing user.email doesn't rewrite the author on commits you already made — it only affects commits from that point forward.

The genealogy: config layering is everywhere

The system/global/local override chain is the same pattern as environment variables cascading from OS-level to project-level .env files, or CSS specificity where a more specific rule wins over a general one. Once you recognize "closer scope wins," Git config, npm config, and a dozen other tools stop needing separate explanations.