Installing Git & Setup

Installing Git on Your Machine

Git is a single program available for Windows, macOS and Linux, and the official downloads all live at git-scm.com. Before installing anything, open a terminal and run git --version. On macOS and most Linux systems Git is often already present, and if a version number prints, you can skip straight to configuration.

On Windows, download Git for Windows from the official site and run the installer. It bundles something you will use constantly: Git Bash, a terminal that understands Unix-style commands such as ls, cat and ssh-keygen. Almost every Git tutorial you find online assumes those commands exist, so running your Git work inside Git Bash rather than the old Command Prompt removes a whole category of "that command doesn't work on my machine" problems. The installer asks a series of questions; accepting the defaults is entirely reasonable for a first install.

On macOS, the simplest route is Homebrew. On Linux, use your distribution's package manager. Either way, finish by confirming that git --version prints something. If the terminal says the command is not found after a successful install, the usual cause on Windows is that you opened a terminal window that was already running before the install — close it and open a new one so it picks up the updated PATH.

# Is Git already here?
git --version
# git version 2.45.2

# macOS (Homebrew)
brew install git

# Ubuntu / Debian / Linux Mint
sudo apt update && sudo apt install git

# Fedora
sudo dnf install git

# Windows: download the installer from https://git-scm.com/download/win
#          then use "Git Bash" as your terminal

Telling Git Who You Are

Every commit permanently records an author name and an email address. Git refuses to make a commit until it knows what to write there, so this is the one piece of configuration you cannot skip. Set it once with --global and it applies to every repository on your computer.

The email matters more than students expect. GitHub links a commit to your profile by matching the commit's email against the addresses registered on your account. Use the wrong address — a college address you later lose, or a typo — and your commits appear on GitHub under a greyed-out name with no profile picture and no link. They still count as commits, but they do not appear as your contributions, which is a small tragedy when a recruiter is looking at your profile. Use an address you have actually added to your GitHub account.

Fixing this later is unpleasant: the email is baked into every affected commit's hash, so correcting it means rewriting history. Two minutes of care now is worth it. If you would rather not publish your personal email address, GitHub can issue you a noreply address in its email settings, and you can set that as your user.email.

# Identity — required before your first commit
git config --global user.name "Ananya Sharma"
git config --global user.email "ananya@example.com"

# Check what Git thinks your identity is
git config --global user.name
git config --global user.email

# Every setting, and which file each one came from
git config --global --list --show-origin

Three Levels of Configuration

Git settings exist at three levels, and knowing which is which explains a lot of otherwise mysterious behaviour. --system settings apply to every user on the computer, --global settings apply to you across all your repositories, and --local settings — the default when you pass no flag at all — apply only to the repository you are standing in. The more specific level wins.

The local level is genuinely useful during an internship. Suppose your personal projects are committed as ananya@gmail.com but your work repository must use ananya@company.in. Set the global identity to your personal address and then, inside the work repository only, run git config user.email "ananya@company.in". From then on Git picks the right address automatically depending on which folder you are in.

Two more global settings are worth setting on day one. init.defaultBranch main makes every new repository start on main rather than master, matching what GitHub does. And core.editor decides which text editor Git opens when it needs a longer message from you.

# Levels, from broadest to narrowest
git config --system ...   # everyone on this computer
git config --global ...   # you, in every repository
git config --local  ...   # this one repository only (the default)

# Useful defaults to set once
git config --global init.defaultBranch main
git config --global core.editor "code --wait"
git config --global pull.rebase false        # git pull merges (see the Remotes lesson)

# A per-project override, run inside that project's folder
git config user.email "ananya@company.in"

• System config lives in Git's install directory and you will rarely touch it
• Global config lives at ~/.gitconfig — you can open and edit that file directly
• Local config lives at .git/config inside the repository, and is not shared with anyone who clones it
• git config --list --show-origin prints every effective setting with the file it came from, which is how you debug "why is Git doing that?"

The Editor Trap, and Line Endings on Windows

Two configuration problems catch first-time users so reliably that they deserve their own section. The first is the editor. If you run git commit without -m, Git opens a text editor for you to type the message in. On many systems that editor is Vim, and a beginner who has never used Vim is now trapped in a full-screen program that responds to none of the usual keys. The escape route is to press Esc, then type :wq and press Enter to save and quit, or :q! to quit without saving. Set core.editor to VS Code and you will never meet this screen again.

The second is line endings, and it mostly bites Windows users on group projects. Windows text files traditionally end each line with two invisible characters (carriage return plus line feed); macOS and Linux use one. If the setting is wrong, you pull your teammate's work and Git reports that every line of every file has changed, when in truth nothing has. Reviewing a pull request in that state is impossible.

The quick fix is core.autocrlf: set it to true on Windows and input on macOS or Linux. The better fix, and the one to use on any shared project, is a .gitattributes file committed into the repository. Because it lives in the repository, it applies to everybody who clones it, instead of relying on each teammate having configured their laptop correctly.

# Stop Vim from ambushing you
git config --global core.editor "code --wait"
# (Notepad on Windows: git config --global core.editor "notepad")
# If you are already stuck in Vim: press Esc, then type  :wq  and Enter

# Line endings, per machine
# Windows:
git config --global core.autocrlf true
# macOS / Linux:
git config --global core.autocrlf input

# Better: a .gitattributes file committed at the root of the project
# so the rule travels with the repository
#
#   * text=auto
#   *.sh text eol=lf
#   *.bat text eol=crlf
#   *.png binary

Connecting to GitHub: SSH or HTTPS

To push code to GitHub you must prove who you are, and there are two ways to do it. With HTTPS your repository URL looks like https://github.com/user/repo.git and Git asks for credentials. Be careful here: GitHub stopped accepting your account password for Git operations back in 2021. If a prompt asks for a password, what it actually wants is a personal access token generated in your GitHub developer settings. Typing your real login password produces an authentication failure that looks inexplicable if you do not know this.

With SSH the URL looks like git@github.com:user/repo.git and authentication happens with a key pair instead. You generate two matching files: a private key that never leaves your computer, and a public key that you paste into your GitHub account settings. After that, pushing just works, with nothing to type and nothing to expire. For a machine you use regularly, SSH is the more comfortable choice, and it is what this course assumes.

Generate the pair with ssh-keygen. When it asks for a file location, pressing Enter accepts the default, which is what you want. When it asks for a passphrase you may leave it empty for convenience, though on a shared or lab computer you should set one — anybody who copies an unprotected private key can push to your repositories as you. Then copy the contents of the .pub file — the public one, never the other — into GitHub under Settings, then SSH and GPG keys.

# 1. Generate a key pair (ed25519 is the current recommendation)
ssh-keygen -t ed25519 -C "ananya@example.com"
#    Press Enter to accept the default path: ~/.ssh/id_ed25519

# 2. Start the agent and load the key
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

# 3. Print the PUBLIC key and copy the whole line
cat ~/.ssh/id_ed25519.pub
#    ssh-ed25519 AAAAC3Nza... ananya@example.com

# 4. Paste it into GitHub: Settings > SSH and GPG keys > New SSH key

# 5. Test it
ssh -T git@github.com
#    Hi ananya! You've successfully authenticated, but GitHub does not
#    provide shell access.