Installing Git is quick, but good initial configuration saves time every day. Your name and email appear in commits, your editor opens when Git needs input, and your default branch name affects new repositories.
A clean setup helps you avoid confusing commit authors, awkward editor prompts, and inconsistent branch names across projects.
Tip: Configure Git once on your machine before starting real work. It prevents small problems from becoming repeated annoyances.
On macOS, the easiest path is often to install the Xcode Command Line Tools. If Git is missing, macOS may prompt you automatically when you run git.
Check first:
git --versionIf Git is not installed, you can use:
xcode-select --installIf you use Homebrew, you can also install Git with:
brew install gitAfter installation, verify it:
git --versionGit is available through most Linux package managers.
sudo apt update
sudo apt install git -ysudo dnf install git -ysudo yum install git -ysudo pacman -S gitThen confirm the installation:
git --versionOn Windows, the most common option is Git for Windows, which includes Git Bash and useful command-line tools.
git --versionGit Bash is especially helpful because many tutorials and DevOps commands assume a Unix-like shell experience.
Note: If you work with VS Code, Git for Windows integrates well with its built-in terminal and source control features.
Git needs to know who you are so commits can record an author.
Set your global name:
git config --global user.name "Vish Patel"Set your global email:
git config --global user.email "vish@example.com"These settings apply to all repositories on your machine unless a repository overrides them.
Check your current config:
git config --global --listIf your name or email is wrong, your commits may appear under the wrong identity on Git hosting platforms. That can make collaboration and auditing harder.
Git sometimes opens an editor for commit messages, merge messages, or rebase instructions. Setting your preferred editor makes those workflows smoother.
For VS Code:
git config --global core.editor "code --wait"For Vim:
git config --global core.editor "vim"For Nano:
git config --global core.editor "nano"The --wait flag is important for VS Code because Git must pause until you finish editing.
Many teams now use main instead of master as the default branch name.
Configure new repositories to start with main:
git config --global init.defaultBranch mainNow when you run git init, the initial branch will be main.
Verify it:
git config --global init.defaultBranchHere are a few optional settings beginners often appreciate.
git config --global color.ui autogit config --global credential.helper cacheOn Windows, Git for Windows can help manage stored credentials depending on your install options.
Tip: Be careful storing credentials directly in files. Use secure credential helpers or SSH keys when possible.
Git configuration can exist at different levels:
For example, if one work project needs a company email, you can override it inside that repository:
git config user.email "vish@company.com"To inspect all effective settings and where they came from:
git config --list --show-originA practical first-time setup often looks like this:
git config --global user.name "Vish Patel"
git config --global user.email "vish@example.com"
git config --global core.editor "code --wait"
git config --global init.defaultBranch main
git config --global color.ui autoThen verify:
git config --global --listInstalling Git is easy, but the important part is configuration. Set your identity, editor, and default branch right away. That gives you cleaner commits, better compatibility with team workflows, and fewer surprises when Git opens an editor or creates a new repository.
Once Git is installed and configured, you are ready to create or clone repositories and start tracking real work.
Scenario: You are on a new macOS machine and want to confirm whether Git is already available before installing anything.
Question: Which command from the tutorial should you run first?
<MCQExercise
exercise={{
id: 'git-installing-q1',
title: 'Exercise 1: Verifying installation',
description: 'Choose the command that checks whether Git is already installed.',
options: [
{ id: 'a', text: 'git --version' },
{ id: 'b', text: 'git config --global --list' },
{ id: 'c', text: 'xcode-select --install' },
{ id: 'd', text: 'git init.defaultBranch' },
],
correctId: 'a',
explanation: 'The tutorial recommends starting with git --version to verify whether Git is already installed. On macOS, that check may also trigger the prompt to install the Xcode Command Line Tools if Git is missing.',
wrongExplanations: {
b: 'That command reads global configuration, but it does not answer the basic installation question first.',
c: 'That is a valid installation path on macOS, but the tutorial said to check for Git before installing it.',
d: 'That is not a valid command, and the default branch setting comes after Git is installed.',
},
}}
/>
Question: Why does the tutorial recommend git config --global core.editor "code --wait" when using VS Code?
<MCQExercise
exercise={{
id: 'git-installing-q2',
title: 'Exercise 2: Choosing an editor',
description: 'Identify why the --wait flag matters when configuring VS Code as the Git editor.',
options: [
{ id: 'a', text: 'It makes Git open a browser tab instead of the terminal.' },
{ id: 'b', text: 'It forces every commit to use squash merge mode.' },
{ id: 'c', text: 'It makes Git pause until you finish editing the message or rebase instructions.' },
{ id: 'd', text: 'It changes the default branch name to code.' },
],
correctId: 'c',
explanation: 'Git sometimes needs you to write commit messages or edit rebase instructions. The --wait flag tells Git to pause until VS Code is closed for that editing session, so the workflow can complete correctly.',
wrongExplanations: {
a: 'The setting is about editor behavior for Git prompts, not about launching a browser.',
b: 'Editor configuration does not control merge strategy choices like squash merging.',
d: 'Default branch naming is handled by init.defaultBranch, not by core.editor.',
},
}}
/>
Scenario: Your personal machine uses vish@example.com globally, but one company repository must use vish@company.com for commits.
Question: Which approach matches the tutorial?
<MCQExercise
exercise={{
id: 'git-installing-q3',
title: 'Exercise 3: Global vs local identity',
description: 'Choose the correct way to override commit identity for just one repository.',
options: [
{ id: 'a', text: 'Reinstall Git separately for the company repository.' },
{ id: 'b', text: 'Change the system config so every user on the machine uses the company email.' },
{ id: 'c', text: 'Create a new default branch called company and commit there.' },
{ id: 'd', text: 'Run git config user.email "vish@company.com" inside that repository.' },
],
correctId: 'd',
explanation: 'The lesson explained that local configuration applies only inside one repository. Setting user.email locally overrides the global value for that project without affecting your other repositories.',
wrongExplanations: {
a: 'Git installation is unrelated to per-repository author identity.',
b: 'System config is much broader than needed and would affect other users or repositories.',
c: 'Branch names do not control commit author metadata.',
},
}}
/>
Your identity, because Git refuses to commit without it and it is stamped permanently into every commit you make: git config --global user.name "Your Name" and git config --global user.email "you@example.com". Use the email associated with your hosting account, or your commits will not be attributed to you. Then set init.defaultBranch main to match what GitHub and GitLab expect, and core.editor to something you can exit.
No user.name or user.email is configured, so Git cannot author a commit. Set them globally with the two --global commands, or per repository without the flag when a project needs a different address. The error usually appears on a brand new machine, or after cloning into a repository with a local config that cleared the values. Commits already made under the wrong identity can be corrected with git commit --amend --reset-author, though only safely before pushing.
Homebrew, if you use Git seriously. The Apple-supplied build is tied to Xcode Command Line Tools updates and is often several minor versions behind, which means missing newer commands and flags, git switch and git restore arrived relatively recently, for example. brew install git gives you current Git that updates with everything else you have installed. Make sure Homebrew's path precedes /usr/bin in your PATH so the new one actually wins.
They are two separate installations that do not share configuration or credentials. Git for Windows provides Git Bash and integrates with Windows tooling; Git inside a WSL distribution is a Linux Git operating on the Linux filesystem. Mixing them causes real problems, line endings, file permissions and credential helpers all differ, so pick one per project and stay with it. If you develop inside WSL, use WSL's Git and keep repositories in the Linux filesystem rather than under /mnt/c, which is also much faster.
Add a .gitattributes file to the repository with * text=auto so Git normalises text files to LF in history while checking them out natively, plus explicit rules for files that must stay LF, *.sh text eol=lf in particular, since a shell script with CRLF fails inside a Linux container with a baffling "not found". Committing .gitattributes is better than relying on each person's core.autocrlf setting, because it makes the behaviour a property of the project rather than of whoever cloned it.
Learn the everyday Git loop with init, clone, status, add, commit, log and diff, understand the staging area and build checks to run before every commit.
Learn what a Git branch really is, git switch versus checkout, how HEAD and detached HEAD work, and how to delete, rename and name branches well.
Learn git merge: fast-forward versus three-way merges, resolving conflict markers step by step, --no-ff and squash merges, and aborting a bad merge.