How to Install and Use Git on Windows

Okay, here’s a comprehensive article on installing and using Git on Windows, aiming for around 5000 words. This will cover everything from the very basics to more advanced usage, providing a strong foundation for anyone getting started with Git.

How to Install and Use Git on Windows: A Comprehensive Guide

Git is an indispensable tool for modern software development, and increasingly, for many other fields that involve managing versions of text-based files. It’s a distributed version control system (DVCS), meaning that every developer has a full copy of the project’s history, not just a snapshot of the latest version. This allows for offline work, easy branching and merging, and robust collaboration. This guide will walk you through every step of installing and using Git on Windows, from the initial download to performing complex operations.

Part 1: Installation and Setup

This section covers downloading, installing, and configuring Git on your Windows machine. We’ll also set up your user information and explore some initial customization options.

1.1 Downloading Git for Windows

The official website for Git is the best place to download the Windows installer: https://git-scm.com/

Navigate to the Downloads Section: On the homepage, you’ll likely see a prominent “Downloads” section. Click on the link for “Windows.” Alternatively, you can go directly to https://git-scm.com/download/win.
Choose the Correct Installer: The website should automatically detect your operating system (32-bit or 64-bit) and offer the appropriate download. If it doesn’t, or if you need a specific version, you can choose from the list of available installers. Most modern systems are 64-bit, so the 64-bit installer is usually the correct choice. Download the “64-bit Git for Windows Setup” if you have a 64-bit system.
Standalone Installer vs. Portable Version: You’ll generally want the standalone installer (the .exe file). The portable version is useful if you need to run Git from a USB drive or don’t have administrator privileges, but the standalone installer is recommended for most users.

1.2 Running the Installer

Once the download is complete, locate the downloaded .exe file (usually in your “Downloads” folder) and double-click it to start the installation process. You’ll likely be presented with a User Account Control (UAC) prompt asking if you want to allow the app to make changes to your device. Click “Yes.”

The Git installer offers a lot of options. We’ll go through the most important ones step-by-step.

License Information: The first screen displays the GNU General Public License. Read it if you wish, and then click “Next.”
Installation Location: The installer will suggest a default installation directory (usually C:\Program Files\Git). You can change this if you prefer, but the default location is generally fine. Click “Next.”
Component Selection: This is a crucial screen. Here’s a breakdown of the key options and recommendations:
- Additional icons:
  - On the Desktop: Check this if you want a Git Bash shortcut on your desktop. This is recommended for easy access.
- Windows Explorer integration:
  - Git Bash Here: This adds a “Git Bash Here” option to the right-click context menu in Windows Explorer. This is highly recommended as it allows you to quickly open a Git Bash terminal in any folder.
  - Git GUI Here: This adds a “Git GUI Here” option. The Git GUI is a graphical interface for Git. While useful for some, learning the command line is generally more powerful and flexible. You can leave this unchecked for now and install it later if needed.
- Git LFS (Large File Storage): Check this if you plan to work with large files (e.g., videos, large datasets) in your Git repositories. Git LFS is an extension that handles large files more efficiently. If you’re unsure, you can leave it unchecked and install it later if needed.
- Associate .git* configuration files with the default text editor: Check this. It makes it easier to edit Git configuration files.
- Associate .sh files to be run with Bash: Check this. This allows you to run shell scripts directly from Windows Explorer.
- Use a TrueType font in all console windows: Check this. It will provide a better look for your windows.
- Check daily for Git for Windows updates: This is optional but recommended to keep your Git installation up-to-date.
Click “Next” after making your selections.
Start Menu Folder: The installer will create a Start Menu folder for Git. You can change the name or choose not to create a Start Menu folder, but the default is fine. Click “Next.”
Choosing the Default Editor Used by Git: This is very important. Git often needs to open a text editor for things like commit messages. The default is Vim, which, while powerful, has a steep learning curve. Here are some better options for beginners:
- Use Nano editor by default: Nano is a simpler, more user-friendly terminal-based editor. This is a good choice for beginners.
- Use Visual Studio Code as Git’s default editor: If you have Visual Studio Code (VS Code) installed, this is an excellent option. VS Code is a popular, powerful, and free code editor.
- Use Notepad++ as Git’s default editor: Notepad++ is another good, lightweight text editor.
- Use another editor: You can choose any text editor you have installed.
Select your preferred editor and click “Next.”
Adjusting your PATH environment: This is another critical setting. The PATH environment variable tells Windows where to find executable files. There are three main options:
- Use Git from Git Bash only: This is the safest option, as it won’t modify your system’s PATH. You’ll only be able to use Git from the Git Bash terminal.
- Git from the command line and also from 3rd-party software: This is the recommended option. It adds Git to your PATH, allowing you to use Git from the Windows Command Prompt, PowerShell, and Git Bash. It also allows other programs to use Git. This is the most convenient and versatile option.
- Use Git and optional Unix tools from the Command Prompt: This option adds both Git and a set of Unix tools to your PATH. This can be useful, but it can also cause conflicts with existing Windows tools. Only choose this option if you understand the implications.
Select “Git from the command line and also from 3rd-party software” and click “Next.”
Choosing the SSH executable: Git uses SSH for secure communication with remote repositories (like GitHub, GitLab, or Bitbucket). You have a few choices:
- Use bundled OpenSSH: This is the recommended option. Git comes with its own version of OpenSSH, which is generally the easiest and most reliable option.
- Use external OpenSSH: You can use a different OpenSSH installation if you have one, but this is usually unnecessary.
Select “Use bundled OpenSSH” and click “Next.”
Choosing HTTPS transport backend: This determines how Git handles HTTPS connections.
- Use the OpenSSL library: This is the recommended option. It uses the widely used OpenSSL library for secure connections.
- Use the native Windows Secure Channel library: This uses the Windows built-in secure channel library. This can work, but the OpenSSL option is generally more reliable.
Select “Use the OpenSSL library” and click “Next.”
Configuring the line ending conversions: This is crucial for cross-platform compatibility. Windows, macOS and Linux, all uses different characteres for line endings.
- Checkout Windows-style, commit Unix-style line endings: This is the recommended option for most Windows users. It converts line endings to Windows-style (CRLF) when you check out files, and converts them to Unix-style (LF) when you commit. This helps prevent issues when collaborating with developers on other operating systems.
- Checkout as-is, commit Unix-style line endings: This option only converts line endings to Unix-style (LF) on commit.
- Checkout as-is, commit as-is: This option doesn’t do any line ending conversions. This is generally not recommended unless you have a specific reason.
  Select “Checkout Windows-style, commit Unix-style line endings” and click “Next”.
Configuring the terminal emulator to use with Git Bash: This determines the terminal emulator used for Git Bash.
- Use MinTTY (the default terminal of MSYS2): This is the recommended option. MinTTY is a good terminal emulator that works well with Git Bash.
- Use Windows’ default console window: This uses the standard Windows Command Prompt window. This is generally not recommended as it has limited features and can have display issues.
Select “Use MinTTY” and click “Next.”
Choose the default behavior of git pull:
- Default (fast-forward or merge): This is the recommended option. Git will try to fast-forward the branch if possible, otherwise it will create a merge commit.
- Rebase: This option rebases your local branch onto the remote branch. Rebase can create a cleaner history, but it can also be more complex and potentially dangerous if not used carefully.
- Only ever fast-forward: This option only allows fast-forward merges. If a fast-forward is not possible, the pull will fail.
  Select “Default (fast-forward or merge) ” and click “Next.”
Configuring extra options:
- Enable file system caching: This is recommended. It improves performance by caching file system data.
- Enable Git Credential Manager: This is highly recommended. It securely stores your Git credentials (username and password/token) so you don’t have to enter them every time you interact with a remote repository.
- Enable symbolic links: This allows you to use symbolic links in your Git repositories. This is generally safe to enable, but if you don’t know what symbolic links are, you can leave it unchecked.
Check “Enable file system caching” and “Enable Git Credential Manager” and click “Next.”
Configuring experimental options:
- Enable experimental support for pseudo consoles: This is an experimental feature that can improve compatibility with some programs. It’s generally safe to leave it unchecked unless you encounter issues.
- Enable experimental built-in file system monitor: This is an experimental feature that can improve performance. It’s generally safe to leave it unchecked unless you encounter issues.
Click “Install” to begin the installation.
Completing the Installation: Once the installation is complete, you may see options to view the release notes or launch Git Bash. You can uncheck these if you wish. Click “Finish.”

1.3 Verifying the Installation

After installation, it’s essential to verify that Git is installed correctly and accessible from your system.

Open Git Bash: You can open Git Bash in several ways:
- Click the Start button, type “Git Bash,” and press Enter.
- Right-click in any folder in Windows Explorer and select “Git Bash Here.”
- If you added a desktop icon, double-click it.
Check the Git Version: In the Git Bash terminal, type the following command and press Enter:

bash git --version

This should display the installed Git version (e.g., git version 2.42.0.windows.2). If you see the version number, Git is installed and accessible.
Check the PATH (Optional): You can also check if Git is in your PATH by opening a standard Windows Command Prompt (search for “cmd” in the Start menu) and typing git --version. If Git is in your PATH, you should see the same version number as in Git Bash.

1.4 Configuring Git

After installation, you need to configure your Git user information. This information will be associated with every commit you make.

Set Your Username: In Git Bash, run the following command, replacing "Your Name" with your actual name:

bash git config --global user.name "Your Name"
Set Your Email Address: Run the following command, replacing "[email protected]" with your email address:

bash git config --global user.email "[email protected]"
This email address should be the same one you use for services like GitHub, GitLab, or Bitbucket.
Verify Your Configuration: You can check your settings with:

bash git config --list

This will display all your Git configuration settings, including your username and email.
Setting the Default Text Editor (Again): While you chose a default editor during installation, it’s a good idea to double-check or change it using the git config command. For example, to set VS Code as your default editor:

bash git config --global core.editor "code --wait"
The --wait flag tells Git to wait for VS Code to close before continuing. For Nano, you would use:

bash git config --global core.editor nano
Credential Helper (Important): We enabled the Git Credential Manager during installation. This is important for securely storing your credentials. The first time you interact with a remote repository that requires authentication (e.g., pushing to GitHub), you’ll be prompted for your username and password (or personal access token, which is recommended for GitHub). The Credential Manager will store these credentials so you don’t have to enter them repeatedly.

Part 2: Basic Git Usage

Now that Git is installed and configured, let’s cover the fundamental commands and workflows.

2.1 Creating a New Repository

There are two main ways to start working with Git: creating a new repository or cloning an existing one. Let’s start with creating a new repository.

Create a Project Directory: First, create a new folder on your computer where you want to store your project files. For example, you might create a folder called my-project on your desktop.
Navigate to the Directory: Open Git Bash and use the cd (change directory) command to navigate to your project directory. For example:

bash cd Desktop/my-project
Alternatively, you can right-click inside the my-project folder in Windows Explorer and select “Git Bash Here.”
Initialize the Repository: Inside the project directory, run the following command to initialize a new Git repository:

bash git init

This command creates a hidden .git subdirectory within your project folder. This subdirectory contains all the necessary Git metadata and object database. You’ve now turned your regular folder into a Git repository!

2.2 The Git Workflow: Staging and Committing

The core of Git revolves around the concepts of the working directory, the staging area, and the repository.

Working Directory: This is where you edit your files. It’s your normal project folder.
Staging Area (Index): This is a “preview” area where you prepare changes before committing them. It’s like a draft of your next commit.
Repository: This is where Git stores the complete history of your project, including all commits.

The basic workflow is:

Modify Files: Make changes to files in your working directory.
Stage Changes: Add the changes you want to include in your next commit to the staging area.
Commit Changes: Create a snapshot of the staged changes, permanently recording them in the repository’s history.

Let’s illustrate this with an example.

Create a File: Inside your my-project directory, create a new text file called README.md. Add some text to the file, for example:

“`

My Project

This is a sample project for demonstrating Git.
“`
Check Status: In Git Bash, run the following command:

bash git status

This command shows the status of your working directory and staging area. You should see output similar to this:

“`
On branch master

No commits yet

Untracked files:
(use “git add …” to include in what will be committed)
README.md

nothing added to commit but untracked files present (use “git add” to track)
“`

This tells you that README.md is an “untracked file,” meaning Git is aware of it but isn’t tracking its changes yet.
Stage the File: Add the file to the staging area using the git add command:

bash git add README.md
Check Status Again: Run git status again:

“`
On branch master

No commits yet

Changes to be committed:
(use “git rm –cached …” to unstage)
new file: README.md
“`

Now the file is listed under “Changes to be committed,” indicating it’s in the staging area.
Commit the Changes: Create a commit with a descriptive message using the git commit command:

bash git commit -m "Add initial README file"

The -m flag allows you to provide a commit message directly on the command line. Commit messages should be clear and concise, explaining what changes were made and why.
Check Status (Again): Run git status one more time:

On branch master nothing to commit, working tree clean

This indicates that your working directory is clean (no uncommitted changes) and the staging area is empty. Your changes have been permanently recorded in the repository.

2.3 Viewing History with git log

The git log command allows you to view the commit history of your repository.

Basic Log: Run:

bash git log

This displays a list of commits, showing the commit hash (a unique identifier), author, date, and commit message.
One-Line Log: For a more compact view:

bash git log --oneline

This shows each commit on a single line, with a shortened commit hash and the commit message.
Other Options: git log has many options for filtering and formatting the output. For example:
- git log -p: Shows the changes (diff) introduced by each commit.
- git log --author="Your Name": Shows only commits by a specific author.
- git log --since="2 weeks ago": Shows commits from the last two weeks.
- git log --graph: Displays a text-based graph of the commit history, showing branches and merges.
- git log --pretty=format:"%h %s": Using format option to display the output as you want.
Explore the git log documentation ( git log --help) for a full list of options.

2.4 Working with Branches

Branches are a fundamental feature of Git, allowing you to work on different features or bug fixes in isolation without affecting the main codebase (usually the master or main branch).

List Branches: To see a list of existing branches:

bash git branch

This will show you the current branch (indicated by an asterisk *). Initially, you’ll only have the master (or main) branch.
Create a New Branch: To create a new branch, use the git branch command followed by the branch name:

bash git branch feature/add-new-feature
This creates the branch, but it doesn’t switch to it. The feature/ prefix is a common naming convention for feature branches, but you can use any valid branch name.
Switch to a Branch (Checkout): To switch to the new branch, use the git checkout command:

bash git checkout feature/add-new-feature
Or you can use the shortcut command, that creates and switches to a new branch in one go:

bash git checkout -b feature/add-new-feature
4. Make Changes and Commit: Now that you’re on the new branch, you can make changes to your files, stage them with git add, and commit them with git commit -m "Your message". These commits will be added to the feature/add-new-feature branch, leaving the master branch untouched.
Merge Branches: Once you’ve finished working on your feature and are ready to integrate it into the main branch, you’ll need to merge the branches.
First checkout to the destination branch:
bash git checkout master
Then merge the feature branch:
bash git merge feature/add-new-feature

This command merges the changes from feature/add-new-feature into the master branch. Git will try to perform an automatic merge.
Handle Merge Conflicts: If Git encounters conflicting changes between the two branches (i.e., the same lines in the same file were modified differently in both branches), it will create a merge conflict. You’ll need to manually resolve these conflicts before the merge can be completed.
- Identify Conflicts: Git will mark the conflicting sections in the affected files. The markers look like this:
  
  “`
  <<<<<<< HEAD
  This is the content from the current branch (e.g., master).
  =======
  This is the content from the branch being merged (e.g., feature/add-new-feature).
  
  feature/add-new-feature
  “`
- Resolve Conflicts: Edit the file to resolve the conflicts. Choose which version of the code to keep, or create a new version that combines the changes. Remove the conflict markers (<<<<<<<, =======, >>>>>>>).
- Stage and Commit: After resolving the conflicts, stage the modified files with git add and then create a merge commit with git commit -m "Merge feature/add-new-feature and resolve conflicts".
Delete a Branch: After a branch has been merged, you can delete it if it’s no longer needed:

bash git branch -d feature/add-new-feature

The -d flag deletes the branch only if it has been merged. If you want to force deletion (even if it hasn’t been merged), use -D (uppercase). Be careful with force deletion, as you could lose unmerged changes.

2.5 Undoing Changes

Git provides several ways to undo changes, depending on what you want to revert and how far back you need to go.

Discarding Unstaged Changes: If you’ve modified a file but haven’t staged the changes yet, you can discard the changes and revert the file to its last committed state:

bash git checkout -- <file_name>
For example: git checkout -- README.md
Unstaging Changes: If you’ve staged changes but want to remove them from the staging area (without discarding the changes in the working directory):

bash git reset HEAD <file_name>
For example: git reset HEAD README.md
Amending the Last Commit: If you made a mistake in your last commit (e.g., forgot to include a file or made a typo in the commit message), you can amend the commit:

bash git commit --amend
This will open your text editor, allowing you to modify the commit message. You can also add files to the staging area before running git commit --amend to include them in the amended commit.
Reverting a Commit: If you want to undo a specific commit that’s already been made (creating a new commit that reverses the changes), use git revert:

bash git revert <commit_hash>
Replace <commit_hash> with the hash of the commit you want to revert. You can find the commit hash using git log. git revert creates a new commit that undoes the changes of the specified commit, preserving the history.
Resetting to a Previous Commit (Caution!): git reset is a powerful command that can move the HEAD pointer (and optionally the branch pointer) to a different commit. This can be used to “undo” commits, but it rewrites history, which can be dangerous if you’ve already pushed the commits to a remote repository. Use git reset with caution, especially on shared branches. There are three main modes:
- git reset --soft <commit_hash>: Moves the HEAD pointer to the specified commit, but leaves the staging area and working directory unchanged. This effectively “unstages” the commits after the specified commit.
- git reset --mixed <commit_hash> (or just git reset <commit_hash>): This is the default mode. It moves the HEAD pointer and resets the staging area to match the specified commit, but leaves the working directory unchanged. This effectively “unstages” the changes and removes them from the staging area.
- git reset --hard <commit_hash>: This is the most dangerous mode. It moves the HEAD pointer, resets the staging area, and resets the working directory to match the specified commit. This discards any uncommitted changes and any commits after the specified commit. Use this with extreme caution!

Part 3: Working with Remote Repositories

So far, we’ve been working with a local Git repository on your computer. The real power of Git comes from its ability to collaborate with others using remote repositories. Services like GitHub, GitLab, and Bitbucket provide hosting for Git repositories.

3.1 Cloning a Repository

To work with an existing remote repository, you need to clone it to your local machine. This creates a complete copy of the repository, including its entire history.

Get the Repository URL: On the website of the service hosting the repository (e.g., GitHub), find the repository’s URL. This is usually a URL that starts with https:// or git@. There will usually be a button to copy the URL to your clipboard.
Clone the Repository: Open Git Bash and navigate to the directory where you want to store the cloned repository. Then, use the git clone command followed by the repository URL:

bash git clone <repository_url>
For example:
bash git clone https://github.com/your-username/your-repository.git

This will create a new directory with the same name as the repository, containing all the files and history.

3.2 Adding a Remote

If you initialized a local repository first and then want to connect it to a remote repository (e.g., on GitHub), you need to add the remote.

Create the Remote Repository: First, create an empty repository on the remote service (e.g., GitHub). Do not initialize it with a README or other files.
Add the Remote: In your local repository (using Git Bash), use the git remote add command:

bash git remote add origin <repository_url>
origin is the conventional name for the primary remote repository, but you can use any name you like. Replace <repository_url> with the URL of your remote repository.

3.3 Pushing Changes

To upload your local commits to the remote repository, use the git push command.

bash git push origin <branch_name>

origin: The name of the remote repository (usually origin).
<branch_name>: The name of the branch you want to push (e.g., master, main, feature/my-feature).

For example, to push the master branch to the origin remote:

bash git push origin master

The first time you push to a new remote, you might need to use the -u (or --set-upstream) flag:

bash git push -u origin master

This tells Git to track the remote branch, so you can use simpler commands like git push and git pull in the future without specifying the remote and branch name.

3.4 Fetching and Pulling Changes

To get changes from the remote repository, you use git fetch and git pull.

git fetch: This command downloads the latest changes from the remote repository without merging them into your local branches. It updates your local tracking branches (e.g., origin/master). This is a safe way to see what’s changed on the remote without affecting your working directory.

bash git fetch origin
git pull: This command combines git fetch and git merge. It downloads the latest changes from the remote repository and merges them into your current branch.

bash git pull origin <branch_name>
For example:
bash git pull origin master

If you’ve set up tracking (using git push -u), you can often just use:

bash git pull

3.5 Working with Personal Access Tokens (PATs) on GitHub

GitHub (and other services) increasingly recommend using Personal Access Tokens (PATs) instead of passwords for authentication. PATs are more secure and allow you to control the level of access granted.

Generate a PAT on GitHub:
- Go to your GitHub account settings.
- Click on “Developer settings.”
- Click on “Personal access tokens.”
- Click on “Tokens (classic).”
- Click “Generate new token”.
- Click “Generate new token (classic).
- Give the token a descriptive name (e.g., “Git access from my Windows machine”).
- Select the scopes (permissions) you want to grant the token. For basic Git operations, you’ll likely need the repo scope.
- Click “Generate token.”
- Important: Copy the generated token immediately. You won’t be able to see it again.
Use the PAT: When you’re prompted for your password when interacting with a GitHub repository (e.g., during git push or git clone), use the PAT instead of your GitHub password. The Git Credential Manager should store the PAT, so you won’t have to enter it every time.

Part 4: Intermediate and Advanced Git Usage

This section covers some more advanced Git features that are useful for managing larger projects and collaborating effectively.

4.1 Stashing Changes

The git stash command allows you to temporarily save changes that you’re not ready to commit yet, allowing you to switch branches or perform other operations without losing your work.

Stash Changes:

bash git stash
This saves your uncommitted changes (both staged and unstaged) to a “stash,” a temporary storage area. Your working directory will be reverted to the state of the last commit.
List Stashes:

bash git stash list
This shows a list of your stashes.
Apply a Stash:

bash git stash apply
This applies the most recent stash ( stash@{0}) to your working directory. The stash remains in the stash list.

bash git stash apply stash@{2}
This applies a specific stash (in this case, stash@{2}).
Pop a Stash:

bash git stash pop
This applies the most recent stash and removes it from the stash list.

bash git stash pop stash@{2}
This pops a specific stash.
Drop a Stash:

bash git stash drop

This removes the most recent stash from the stash list without applying it.

bash git stash drop stash@{2}

This drops a specific stash.
Clear All Stashes:
bash git stash clear

4.2 Ignoring Files with .gitignore

The .gitignore file tells Git which files or directories to ignore, meaning they won’t be tracked by Git. This is useful for things like:

Build artifacts (e.g., compiled code, executables)
Temporary files
Log files
Files containing sensitive information (e.g., API keys, passwords)
Editor-specific configuration files
Create a .gitignore File: Create a file named .gitignore (note the leading dot) in the root directory of your Git repository.
Add Patterns: Add patterns to the .gitignore file to specify which files and directories to ignore. Each pattern should be on a separate line. Here are some common patterns:
- #: A line starting with # is a comment.
- *.log: Ignore all files with the .log extension.
- temp/: Ignore the temp directory and all its contents.
- !important.txt: Don’t ignore the file important.txt, even if it matches other patterns. The ! negates a pattern.
- /build/: Ignore the build directory in the root of the repository. The leading / matches only at the root.
- **/output/: Ignore any directory named output anywhere in the repository.
- [oO]bj/: Ignore directory with obj/ or Obj/
- Commit the .gitignore File: The .gitignore file itself should be tracked by Git, so add and commit it like any other file:
bash git add .gitignore git commit -m "Add .gitignore file"

4.3 Tagging

Tags are used to mark specific commits as important points in the project’s history, such as releases or milestones.

Create an Annotated Tag:

bash git tag -a v1.0.0 -m "Release version 1.0.0"
This creates an annotated tag named v1.0.0 associated with the current commit. The -a flag creates an annotated tag (which includes information like the tagger’s name and date), and the -m flag provides a tag message.
Create a Lightweight Tag:

bash git tag v1.0.0
This creates a lightweight tag, which is simply a pointer to a specific commit.
List Tags:

bash git tag
Show Tag Information:

bash git show v1.0.0
**Push

My Project

Leave a Comment Cancel Reply