Okay, here is a detailed article on installing Git and Git Bash on Windows, aiming for the requested length and detail.

The Ultimate Guide to Installing Git & Git Bash on Windows: From Zero to Hero

In the landscape of modern software development, collaboration, and even personal project management, Version Control Systems (VCS) are not just helpful; they are fundamental. Among the plethora of VCS options available, Git stands as the undisputed champion. Developed by Linus Torvalds (the creator of Linux) in 2005, Git is a distributed version control system designed for speed, efficiency, data integrity, and support for distributed, non-linear workflows.

Whether you’re a seasoned developer joining a new Windows-based team, a student learning to code, a data scientist tracking experiments, or even a writer managing complex documentation, understanding how to install and use Git on your Windows machine is a crucial skill.

This comprehensive guide aims to walk you through every step of installing Git on Windows, including the powerful Git Bash terminal emulator. We won’t just show you what buttons to click; we’ll explain why, delving into the configuration options presented during installation so you can make informed decisions tailored to your needs. Prepare for a deep dive – by the end of this article, you’ll have Git successfully installed and configured, ready to start tracking your projects like a pro.

Understanding the Essentials: What is Git and Why Do You Need It?
- The Core Concept: Version Control
- Centralized vs. Distributed VCS
- Key Benefits of Using Git
- Why Git Dominates the Landscape
Introducing Git Bash: Your Linux-Style Command Line on Windows
- What is a Shell or Command-Line Interface (CLI)?
- What is Git Bash Specifically? (MinTTY, MSYS2)
- Why Use Git Bash instead of CMD or PowerShell?
- Basic Linux Commands You’ll Use in Git Bash
Pre-Installation Checklist
- System Requirements
- Checking for Existing Git Installations
- Administrator Privileges
Downloading the Git for Windows Installer
- Navigating to the Official Git Website
- Choosing the Right Installer (32-bit vs. 64-bit, Standalone vs. Portable)
The Installation Process: A Detailed Step-by-Step Walkthrough
- Running the Installer
- Step 1: GNU General Public License: Understanding the Terms
- Step 2: Select Destination Location: Choosing Where to Install Git
- Step 3: Select Components: Dissecting the Options
  - Additional Icons (Desktop)
  - Windows Explorer Integration (Git Bash Here / Git GUI Here)
  - Git LFS (Large File Support)
  - Associate .git* configuration files with the default text editor
  - Associate .sh files to be run with Bash
  - Use a TrueType font in all console windows
  - Check daily for Git for Windows updates
- Step 4: Select Start Menu Folder: Organizing Your Start Menu
- Step 5: Choosing the Default Editor Used by Git: Critical Configuration
  - Vim (The Default – Use with Caution!)
  - Nano
  - Notepad++
  - Visual Studio Code (Recommended if installed)
  - Sublime Text
  - Atom
  - Notepad
  - Choosing Other Editors
- Step 6: Adjusting the Name of the Initial Branch in New Repositories: master vs. main
  - Historical Context and The Shift to main
  - Let Git Decide vs. Override
  - Recommendation
- Step 7: Adjusting your PATH Environment: The Most Crucial Step
  - Option 1: Use Git from Git Bash Only
  - Option 2: Git from the Command Line and also from 3rd-party software (Recommended)
  - Option 3: Use Git and optional Unix tools from the Command Prompt
  - Detailed Explanation and Recommendation
- Step 8: Choose SSH Executable: Connecting Securely
  - Use bundled OpenSSH
  - Use external OpenSSH
  - Recommendation
- Step 9: Choose HTTPS Transport Backend: Secure Connections Over the Web
  - Use the OpenSSL library (Recommended)
  - Use the native Windows Secure Channel library
  - Explanation and Recommendation
- Step 10: Configure Line Ending Conversions: Handling Windows vs. Unix Line Endings
  - The CRLF vs. LF Problem Explained
  - Option 1: Checkout Windows-style, commit Unix-style line endings (Recommended)
  - Option 2: Checkout as-is, commit Unix-style line endings
  - Option 3: Checkout as-is, commit as-is
  - Deep Dive and Justification for Recommendation
- Step 11: Configure the Terminal Emulator to Use with Git Bash: MinTTY vs. Windows Console
  - Use MinTTY (the default terminal of MSYS2) (Recommended)
  - Use Windows’ default console window (cmd.exe)
  - Why MinTTY is Preferred
- Step 12: Choose the Default Behavior of git pull: Merging vs. Rebasing
  - Default (fast-forward or merge) (Recommended for beginners)
  - Rebase
  - Only ever fast-forward
  - Understanding the Implications
- Step 13: Choose a Credential Helper: Managing Passwords and Tokens
  - Git Credential Manager Core (Recommended)
  - None
  - The Importance of a Credential Helper
- Step 14: Configure Extra Options: Performance and Features
  - Enable file system caching (Recommended)
  - Enable symbolic links
  - Explanation
- Step 15: Configuring Experimental Options: Use with Caution
  - Enable experimental support for pseudo consoles
  - Enable experimental built-in file system monitor
  - Recommendation: Leave unchecked unless needed
- Step 16: Completing the Git Setup Wizard: Finalizing Installation
Post-Installation Verification
- Opening Git Bash
- Running git --version in Git Bash
- Running git --version in Command Prompt / PowerShell (if PATH was adjusted)
Essential First-Time Git Configuration
- Setting Your Username (git config --global user.name "Your Name")
- Setting Your Email Address (git config --global user.email "[email protected]")
- Checking Your Configuration (git config --list)
- Understanding --global vs. Local Configuration
Getting Started with Git Bash: Basic Usage
- Navigating the File System (pwd, ls, cd)
- Creating Files and Directories (touch, mkdir)
- A Simple Git Workflow Example (git init, git status, git add, git commit, git log)
Integrating Git with Other Tools
- IDEs (Visual Studio Code, JetBrains IDEs, etc.)
- Graphical Git Clients (SourceTree, GitKraken, GitHub Desktop)
Troubleshooting Common Installation Issues
- git command not found
- Firewall or Antivirus Interference
- Issues with SSH Keys
- Problems with the Default Editor
- Line Ending Conflicts
Updating Git for Windows
- Using the Installer
- Using git update-git-for-windows in Git Bash
Uninstalling Git for Windows
Conclusion: Your Journey with Git Begins
Glossary of Key Git Terms

1. Understanding the Essentials: What is Git and Why Do You Need It?

Before we dive into the installation commands and configuration screens, it’s crucial to understand what Git is and why it’s become an indispensable tool.

The Core Concept: Version Control

Imagine you’re working on a complex document – a research paper, a novel, or a piece of code. You make changes, save them, make more changes, and maybe realize you made a mistake several steps back. How do you revert? You might have saved multiple copies like document_v1.docx, document_v2_final.docx, document_final_really_final.docx. This is a primitive form of version control, and it quickly becomes unmanageable, especially when multiple people are collaborating.

A Version Control System (VCS) automates this process. It tracks changes to files over time, allowing you to:

See History: View every change made to the project, when it was made, and by whom.
Revert Changes: Easily go back to any previous state of the project.
Compare Versions: See the exact differences between two points in the project’s history.
Branching and Merging: Work on new features or experiments in isolation (branches) without affecting the main project. Later, you can merge these changes back if they are successful.
Collaboration: Enable multiple people to work on the same project simultaneously without overwriting each other’s work, providing mechanisms to resolve conflicts when they arise.

Centralized vs. Distributed VCS

Centralized VCS (CVCS): Systems like Subversion (SVN) or CVS rely on a single central server that stores the entire project history. Developers “check out” files from this central server, make changes, and “check in” those changes.
- Pros: Simpler to understand initially, fine-grained access control.
- Cons: Single point of failure (if the server is down, nobody can collaborate or commit), requires a network connection for most operations.
Distributed VCS (DVCS): Systems like Git, Mercurial, or Bazaar take a different approach. Every developer has a complete copy (a “clone”) of the entire repository, including its full history, on their local machine.
- Pros:
  - Offline Work: You can commit, view history, create branches, and more without a network connection.
  - Speed: Most operations are local and therefore extremely fast.
  - Redundancy: No single point of failure; if the main server goes down, any developer’s clone can be used to restore it.
  - Flexible Workflows: Enables powerful branching and merging strategies suitable for complex projects.
- Cons: Slightly steeper learning curve initially compared to CVCS.

Git is a Distributed Version Control System. This distributed nature is a key reason for its power and popularity.

Key Benefits of Using Git

Complete History Tracking: Never lose a change again. Understand the evolution of your project.
Safe Experimentation with Branching: Create isolated environments (branches) to try out new ideas, fix bugs, or develop features without disrupting the stable version of your project.
Efficient Collaboration: Git provides robust tools for merging work from multiple contributors and resolving conflicts when changes overlap.
Data Integrity: Git uses cryptographic hashing (SHA-1) to ensure the integrity of your project history. Every commit, file, and object is checksummed.
Speed and Performance: Designed for performance, most Git operations are incredibly fast because they happen locally.
Open Source and Free: Git is free to use and modify under the GNU General Public License.
Industry Standard: Knowing Git is practically a requirement for most software development jobs and is widely used in countless open-source projects.

Why Git Dominates the Landscape

While other DVCS options exist, Git has become the de facto standard due to several factors:

Performance: It was designed with performance for large projects (like the Linux kernel) in mind.
Flexibility: Its branching and merging capabilities are exceptionally powerful.
Community and Ecosystem: A massive community contributes to Git’s development, and countless tools and services (like GitHub, GitLab, Bitbucket) are built around it.
Adoption: Its widespread adoption means more resources, tutorials, and collaborators are available.

Now that you appreciate the why, let’s look at a crucial companion tool for using Git effectively on Windows: Git Bash.

2. Introducing Git Bash: Your Linux-Style Command Line on Windows

When you install Git for Windows, you typically also install Git Bash. But what exactly is it?

What is a Shell or Command-Line Interface (CLI)?

A shell is a program that takes commands typed by the user and executes them by interacting with the operating system. It provides a Command-Line Interface (CLI), a text-based way to interact with your computer, as opposed to a Graphical User Interface (GUI) which uses icons, windows, and menus.

Windows has its own native CLIs:

Command Prompt (cmd.exe): The traditional Windows command-line interpreter.
PowerShell: A more modern, powerful, object-oriented shell and scripting language developed by Microsoft.

While you can run Git commands from CMD or PowerShell (if configured correctly during installation), many developers prefer a Linux-like environment.

What is Git Bash Specifically?

Git Bash is an application for Microsoft Windows environments which provides a Bash emulation used to run Git from the command line.

Bash (Bourne Again SHell): This is the default shell for most Linux distributions and macOS. It has a rich set of commands and scripting capabilities familiar to Unix/Linux users.
Emulation: Git Bash provides a layer that translates Bash commands and scripts into something Windows can understand. It does this using components from the MSYS2 project (a software distribution and building platform for Windows), which itself is based on Cygwin (a POSIX-compatible environment for Windows).
MinTTY: The default terminal window that Git Bash runs in is called MinTTY. It offers features often missing in the standard Windows console, like better resizing, font rendering, Unicode support, and a more Unix-like feel.

Essentially, Git Bash bundles:

The Git core executables.
A collection of common Unix/Linux utilities (like ls, cd, cp, mv, rm, grep, ssh, etc.).
The Bash shell itself.
The MinTTY terminal emulator.

Why Use Git Bash instead of CMD or PowerShell?

Consistency: If you work across different operating systems (Linux, macOS, Windows), using Git Bash provides a more consistent command-line experience for Git operations.
Unix Utilities: Access to standard Unix commands (ls instead of dir, rm instead of del, etc.) can be more intuitive for developers accustomed to Linux/macOS or following cross-platform tutorials.
Scripting: Bash scripting is powerful and widely used. Git Bash allows you to run shell scripts (.sh files) directly on Windows.
Tutorials and Documentation: Many Git tutorials and documentation examples use Bash syntax. Following along is easier in Git Bash.
SSH: Git Bash comes bundled with a functional OpenSSH client, essential for securely connecting to remote Git repositories (like GitHub or GitLab).

While PowerShell is very powerful, especially for Windows administration, Git Bash often feels more natural and efficient specifically for Git-related tasks and general Unix-like command-line work.

Basic Linux Commands You’ll Use in Git Bash

Even if you only use Git Bash for Git, knowing a few basic navigation commands is essential:

pwd (Print Working Directory): Shows the current directory you are in.
ls (List): Lists files and directories in the current directory (ls -la shows detailed info, including hidden files).
cd (Change Directory): Navigates between directories (e.g., cd Documents, cd .. to go up one level, cd ~ to go to your home directory).
mkdir (Make Directory): Creates a new directory (e.g., mkdir my-new-project).
touch (Touch): Creates an empty file or updates the timestamp of an existing file (e.g., touch README.md).
cp (Copy): Copies files or directories (e.g., cp file1.txt file2.txt, cp -r dir1 dir2).
mv (Move/Rename): Moves or renames files or directories (e.g., mv oldname.txt newname.txt, mv file.txt ../).
rm (Remove): Deletes files (rm file.txt). Use with caution! rm -r directory deletes a directory and its contents.
clear: Clears the terminal screen.

Having this context makes the installation choices, particularly regarding PATH and terminal emulators, much clearer.

3. Pre-Installation Checklist

Before downloading and running the installer, let’s ensure your system is ready.

System Requirements

Git for Windows is fairly lightweight. Generally, if your computer can run a modern version of Windows (Windows 7 SP1, 8, 8.1, 10, 11), it can run Git.

Operating System: Windows 7 SP1 or newer (32-bit or 64-bit).
Disk Space: The installer itself is around 50 MB. The installed footprint is typically around 300-500 MB, depending on the selected components. You’ll also need space for your actual Git repositories.
RAM: No specific high requirement; Git itself is efficient.

Checking for Existing Git Installations

It’s good practice to check if Git is already installed, perhaps by another development tool. Open Command Prompt (search for cmd) or PowerShell and type:

bash git --version

If Git is installed and accessible from your PATH, this command will output the installed version (e.g., git version 2.38.1.windows.1). If you get an error message like “git is not recognized as an internal or external command…”, Git is likely not installed or not configured correctly in your system’s PATH environment variable.

Even if Git is installed, you might want to install the latest version using this guide, as the installer handles updates and allows you to configure components cleanly.

Administrator Privileges

While Git can sometimes be installed for a single user without admin rights (using the portable version or changing the installation directory), the standard installation process, which modifies system settings like the PATH variable, typically requires administrator privileges. It’s recommended to run the installer as an administrator (right-click the installer file and choose “Run as administrator”).

4. Downloading the Git for Windows Installer

With the checks complete, let’s download the official installer.

Navigating to the Official Git Website

Open your web browser.
Go to the official Git website: https://git-scm.com/
The homepage usually detects your operating system and prominently displays a download button for Windows.

Alternatively, you can go directly to the download page for Windows: https://git-scm.com/download/win

Choosing the Right Installer (32-bit vs. 64-bit, Standalone vs. Portable)

The download page will typically automatically start downloading the recommended version for your system. However, you might see options for:

64-bit vs. 32-bit: Most modern Windows systems are 64-bit. The 64-bit version of Git is generally recommended for better performance, especially when working with large repositories. If you have a very old machine running a 32-bit version of Windows, you’ll need the 32-bit installer. To check your system type, go to Settings > System > About and look for “System type”.
Standalone Installer: This is the standard .exe installer that guides you through the setup process and installs Git system-wide (or for the current user). This is the recommended option for most users and the one this guide focuses on.
Portable (“Thumbdrive edition”): This is a .zip archive containing the Git executables and necessary files. You can extract it anywhere (like a USB drive) and run Git without a formal installation process. It doesn’t typically integrate with the system PATH or Windows Explorer automatically. Useful for restricted environments or testing, but less convenient for daily use.

Action: Download the latest 64-bit Standalone Installer unless you have specific reasons to choose otherwise. Save the .exe file to a convenient location, like your Downloads folder.

5. The Installation Process: A Detailed Step-by-Step Walkthrough

Now for the main event: running the installer and navigating its many configuration screens. We will go through each screen, explaining the options and providing recommendations. Remember that defaults are often sensible, but understanding the choices empowers you.

Action: Locate the downloaded Git installer (.exe file) and double-click it. If prompted by User Account Control (UAC), grant it permission to make changes to your device.

Step 1: GNU General Public License

Screen Purpose: Displays the open-source license under which Git for Windows is distributed (GNU GPL version 2).
Options: You must accept the license to proceed.
Recommendation: Read it if you wish, then click Next.

Step 2: Select Destination Location

Screen Purpose: Choose the folder where Git will be installed.
Options: The default location is usually C:\Program Files\Git. You can browse and select a different location if needed (e.g., on a different drive).
Recommendation: For most users, the default location is perfectly fine. If you change it, ensure the path doesn’t contain unusual characters or deep nesting that might cause issues. Click Next.

Step 3: Select Components

Screen Purpose: Allows you to customize which features and tools are installed alongside the Git core. This screen has several checkboxes.
Options & Recommendations:
- ☐ Additional Icons
  - ☐ On the Desktop: Adds a Git Bash shortcut to your desktop. Recommendation: Check if you want easy desktop access, otherwise leave unchecked to keep the desktop clean.
- ☑ Windows Explorer Integration
  - ☑ Git Bash Here: Adds an option to the right-click context menu in File Explorer, allowing you to quickly open Git Bash in the selected folder. Recommendation: Keep checked. Extremely useful.
  - ☑ Git GUI Here: Adds a context menu option to open the basic Git GUI tool in the selected folder. Recommendation: Keep checked. While basic, the GUI can be helpful occasionally, especially for beginners visualizing changes. (Note: Git GUI is a separate, simpler graphical interface, not to be confused with third-party clients like SourceTree or GitKraken).
- ☑ Git LFS (Large File Support): Installs support for Git Large File Storage, an extension for versioning large files (like audio, video, large datasets) efficiently. Recommendation: Keep checked. It doesn’t hurt to have, and you might need it later.
- ☑ Associate .git* configuration files with the default text editor: Makes Windows open files like .gitconfig in the editor you’ll choose later in the setup. Recommendation: Keep checked for convenience.
- ☑ Associate .sh files to be run with Bash: Allows you to run shell script files (.sh) directly by double-clicking them (they will execute in Git Bash). Recommendation: Keep checked if you plan to work with shell scripts on Windows.
- ☐ Use a TrueType font in all console windows: This tries to configure all console windows (like CMD and PowerShell, not just MinTTY/Git Bash) to use a modern TrueType font (like Consolas or Lucida Console) instead of legacy raster fonts. Recommendation: Leave unchecked unless you specifically want this system-wide change and understand its potential impact on other console applications. Git Bash/MinTTY uses its own font settings.
- ☐ Check daily for Git for Windows updates: Enables an automatic daily check for new Git versions. Recommendation: Check if you want Git to prompt you when updates are available. Leave unchecked if you prefer to update manually.
Action: Select components based on the recommendations or your preferences, then click Next. The defaults are generally sensible.

Step 4: Select Start Menu Folder

Screen Purpose: Choose where the Git shortcuts will appear in your Start Menu.
Options: Default is Git. You can rename it or choose not to create a Start Menu folder.
Recommendation: Keep the default Git folder. Click Next.

Step 5: Choosing the Default Editor Used by Git

Screen Purpose: Select the text editor that Git will use for tasks requiring user input, such as writing commit messages (when not using -m), handling interactive rebases, or merging conflicts. This is an important choice.
Options: The installer lists detected editors and provides common defaults.
- Use Vim (the ubiquitous text editor) as Git’s default editor: Vim is a powerful but notoriously difficult-to-learn modal text editor common in Unix/Linux environments. It’s the historical default. Recommendation: Strongly discouraged for beginners unless you already know and love Vim. Getting stuck in Vim without knowing how to save and exit (:wq) is a common frustration.
- Use Nano as Git’s default editor: Nano is a much simpler, beginner-friendly command-line editor. Commands are usually displayed at the bottom of the screen (e.g., ^X for Exit, ^O for Write Out/Save). Recommendation: A good safe choice if you don’t have a preferred graphical editor installed or want a simple console editor.
- Use Notepad++ as Git’s default editor: Notepad++ is a popular free source code editor for Windows. If detected, this is a great option. Recommendation: Excellent choice if you have Notepad++ installed.
- Use Visual Studio Code as Git’s default editor: VS Code is a widely used, powerful, and free source code editor from Microsoft. If detected, this is arguably the best choice for many developers. It integrates well with Git. Recommendation: Highly Recommended if you have VS Code installed.
- Use Visual Studio Code Insiders as Git’s default editor: Same as above, but uses the “Insiders” (beta) build of VS Code. Recommendation: Use the stable VS Code option unless you specifically use Insiders.
- Use Sublime Text as Git’s default editor: Another popular, powerful text editor (commercial, but with an unlimited free trial). Recommendation: Good choice if you use Sublime Text.
- Use Atom as Git’s default editor: A free, hackable text editor developed by GitHub (though its development has slowed). Recommendation: Fine if you use Atom, but VS Code is generally more recommended now.
- Use Notepad as Git’s default editor: Uses the basic Windows Notepad. Recommendation: Discouraged. Notepad has poor support for Unix line endings (LF) and lacks features helpful for coding or commit messages (like syntax highlighting or line numbers).
- Select other editor…: Allows you to manually specify the path to an editor executable not listed.
Action: Choose the editor you are most comfortable with. VS Code or Notepad++ are highly recommended if available. Nano is a safe fallback for a console editor. Avoid Vim unless you know it. Click Next.

Step 6: Adjusting the Name of the Initial Branch in New Repositories

Screen Purpose: Configure the default name Git uses for the very first branch created in a new repository (using git init).
Options:
- Let Git decide: Uses Git’s own internal default, which historically was master but is now changing to main in newer Git versions to promote more inclusive language. The installer will use whatever the bundled Git version defaults to.
- Override the default branch name for new repositories: Allows you to explicitly set the name, typically to main (recommended) or stick with master if needed for legacy reasons or personal preference. The default input here is usually main.
Historical Context: The term master has connotations related to slavery, leading the software development community to move towards main as a neutral default. Platforms like GitHub now default to main.
Recommendation: Select Override the default branch name and ensure the text box contains main. This aligns with modern best practices and major platforms. Click Next.

Step 7: Adjusting your PATH Environment

Screen Purpose: This is arguably the most critical configuration step. It determines how Git and its bundled tools can be accessed from different command-line environments on your system. The PATH is a system variable that lists directories where executable programs are located.
Options:
- (Option 1) Use Git from Git Bash only:
  - What it does: Does not modify the Windows PATH environment variable. You can only use the git command from within the Git Bash terminal. You won’t be able to run git directly from Command Prompt, PowerShell, or third-party tools that rely on the system PATH (like IDEs or graphical clients).
  - Pros: Safest option, avoids potential conflicts with other software if you have tools with similar names (unlikely for git).
  - Cons: Least convenient. Restricts Git usage solely to Git Bash.
  - Recommendation: Generally not recommended unless you have a specific reason to isolate Git completely.
- (Option 2) Git from the command line and also from 3rd-party software:
  - What it does: Adds the directory containing the core Git executables (but not the extra Unix tools) to the Windows PATH. This allows you to run git commands from Git Bash, Command Prompt, PowerShell, and allows graphical clients and IDEs to find and use Git automatically.
  - Pros: Most versatile and convenient option. Makes Git widely accessible. This is the standard way most development tools expect Git to be available.
  - Cons: Minimal risk of PATH conflicts (very low for git itself).
  - Recommendation: Highly Recommended for almost all users. This provides the best balance of accessibility and safety.
- (Option 3) Use Git and optional Unix tools from the Command Prompt:
  - What it does: Adds both the Git executables directory and the directory containing the bundled Unix utilities (like find, sort, ls, rm) to the Windows PATH. This means you can run git and commands like ls directly from Command Prompt or PowerShell.
  - Pros: Provides a more Linux-like experience directly in Windows native shells.
  - Cons: Highest risk of conflicts. Windows has its own versions of some tools (e.g., find). Adding the Unix tools to the PATH can override the native Windows commands, potentially breaking existing scripts or workflows that expect the Windows behavior.
  - Recommendation: Generally not recommended unless you are an advanced user who specifically wants this behavior and understands the potential consequences.
Action: Select the second option (Recommended): Git from the command line and also from 3rd-party software. Click Next.

Step 8: Choose SSH Executable

Screen Purpose: Select which Secure Shell (SSH) client Git should use when connecting to repositories using the SSH protocol (e.g., [email protected]:user/repo.git). SSH provides a secure, encrypted connection.
Options:
- Use bundled OpenSSH: Git for Windows comes with its own version of OpenSSH, a widely used and trusted SSH client. This version is configured to work well with Git Bash and standard SSH key locations (~/.ssh).
- Use external OpenSSH: If you have another SSH client installed (perhaps from PuTTY, Cygwin, or the optional OpenSSH feature in Windows 10/11) and want Git to use that specific client, you can choose this. You’d typically only do this if you have complex existing SSH configurations you need to reuse.
Recommendation: Select Use bundled OpenSSH. It’s the simplest and most reliable option, ensuring compatibility with Git Bash and standard practices for managing SSH keys. Click Next.

Step 9: Choose HTTPS Transport Backend

Screen Purpose: Select the library Git should use for handling secure connections when interacting with repositories over HTTPS (e.g., https://github.com/user/repo.git).
Options:
- Use the OpenSSL library: Uses the widely adopted open-source OpenSSL library for handling TLS/SSL encryption (the ‘S’ in HTTPS). This library supports modern cryptographic standards and works well with various server configurations. It also uses a system-wide CA certificate store (ca-bundle.crt) that Git manages.
- Use the native Windows Secure Channel library: Uses Microsoft’s built-in Secure Channel (SChannel) library. This integrates with the Windows Certificate Store, which might be useful in corporate environments with custom root certificates managed via Group Policy. However, it has historically had quirks or limitations compared to OpenSSL in some scenarios.
Recommendation: Select Use the OpenSSL library. It’s generally more robust, cross-platform compatible, and easier to manage certificates for if needed. Click Next.

Step 10: Configure Line Ending Conversions

Screen Purpose: This is another very important setting, especially for cross-platform projects or collaboration between Windows and Linux/macOS users. It deals with how Git handles invisible characters that mark the end of a line in text files.
The CRLF vs. LF Problem Explained:
- Windows: Uses a Carriage Return followed by a Line Feed (CRLF, \r\n) to signify the end of a line.
- Linux and macOS: Use only a Line Feed (LF, \n) to signify the end of a line.
- The Issue: If developers on different systems work on the same text files, Git might see the entire file as changed simply because the line endings differ. Committing files with mixed line endings (CRLF and LF) can also cause problems for tools and scripts.
Options:
- (Option 1) Checkout Windows-style, commit Unix-style line endings:
  - What it does: When you check out (pull or clone) code from a repository, Git automatically converts LF line endings to CRLF in your working directory. When you commit (add and commit) files, Git automatically converts CRLF back to LF before storing them in the repository.
  - Pros: Ensures files have the native line endings (CRLF) for Windows tools when you’re working on them, but stores them consistently (LF) in the Git repository, which is the standard convention for cross-platform projects. Prevents spurious line ending changes in commits.
  - Cons: Files in your working directory will have different line endings than those stored in the Git database.
  - Recommendation: Highly Recommended for most Windows users, especially when collaborating or working on cross-platform projects. This is the safest default.
- (Option 2) Checkout as-is, commit Unix-style line endings:
  - What it does: When you check out code, Git leaves the line endings exactly as they are in the repository (likely LF for cross-platform projects). When you commit, it still converts CRLF to LF.
  - Pros: Better for projects that must preserve Unix-style endings even in the Windows working directory (e.g., certain shell scripts).
  - Cons: Windows tools (like basic Notepad) might display the files incorrectly (as one long line). Less convenient for general Windows development.
  - Recommendation: Suitable for specific use cases, but less common for general development than Option 1.
- (Option 3) Checkout as-is, commit as-is:
  - What it does: Git does not perform any line ending conversion. It checks out and commits line endings exactly as it finds them.
  - Pros: No “magic” conversions happening.
  - Cons: Not recommended for cross-platform projects. You are likely to encounter issues with inconsistent line endings polluting your commits and diffs. Can cause problems if different team members have different settings.
  - Recommendation: Generally discouraged unless all collaborators are on Windows and you fully understand the implications, or if you are working exclusively with binary files where line endings are irrelevant.
Action: Select the first option (Recommended): Checkout Windows-style, commit Unix-style line endings. Click Next.

Step 11: Configure the Terminal Emulator to Use with Git Bash

Screen Purpose: Choose the terminal application window that Git Bash will run inside.
Options:
- Use MinTTY (the default terminal of MSYS2):
  - What it does: Uses MinTTY, a terminal emulator designed for Cygwin/MSYS2 environments (which Git Bash is built upon).
  - Pros: Provides a better Unix/Linux-like terminal experience: good resizing, Unicode support, customizable fonts and colors, text selection often works better than the Windows console. Generally faster and more pleasant to use for command-line work.
  - Cons: It’s not a native Windows console application. This means native Windows console programs (like python run interactively, or Node.js REPL) might have some minor input/output quirks or limitations when run inside MinTTY, though this is less common now.
  - Recommendation: Highly Recommended. Provides the best experience for using Git Bash and its associated Unix tools.
- Use Windows’ default console window (cmd.exe):
  - What it does: Runs Git Bash inside the standard Windows Command Prompt window.
  - Pros: Better compatibility with interactive native Windows console programs. Uses the familiar CMD window.
  - Cons: Generally considered a worse terminal experience: poor resizing behavior, limited font/color options (though improved in newer Windows versions with Windows Terminal), potential issues with character encoding or display compared to MinTTY.
  - Recommendation: Generally not recommended unless you encounter specific compatibility issues with native console apps inside MinTTY and need the standard Windows console behavior.
Action: Select the first option (Recommended): Use MinTTY. Click Next.

Step 12: Choose the Default Behavior of `git pull`

Screen Purpose: Configure what happens when you run git pull to fetch changes from a remote repository and integrate them into your current local branch. This involves how Git handles situations where you have local commits that are not yet on the remote server.
Options:
- Default (fast-forward or merge):
  - What it does: If your local branch hasn’t diverged from the remote branch (i.e., you have no new local commits), it performs a “fast-forward” merge, simply moving your branch pointer forward. If your local branch has diverged (you have local commits), it creates a merge commit to combine the remote changes with your local ones.
  - Pros: Preserves the exact history of both branches, creating an explicit record of when divergent histories were combined. Easier for beginners to understand visually.
  - Cons: Can lead to a “messier” history graph with many merge commits, especially in active branches.
  - Recommendation: Recommended, especially for beginners. It’s the most straightforward and least “destructive” behavior.
- Rebase:
  - What it does: Instead of creating a merge commit when histories diverge, git pull --rebase temporarily removes your local commits, pulls down the remote changes, and then re-applies your local commits on top of the newly fetched commits.
  - Pros: Creates a cleaner, linear project history (no extra merge commits from pulling). Preferred by many experienced teams.
  - Cons: Rewrites history (your local commits get new commit IDs). Can be dangerous if you’ve already pushed the original local commits elsewhere. Can make resolving conflicts slightly more complex during the rebase process. Steeper learning curve.
  - Recommendation: Powerful, but not recommended as the default for beginners. Use git pull --rebase explicitly when you intend to rebase, rather than making it the default pull behavior initially.
- Only ever fast-forward:
  - What it does: Only allows the pull if it can be performed via a fast-forward (i.e., you have no local commits). If histories have diverged, the pull will fail, forcing you to manually fetch and then merge or rebase.
  - Pros: Prevents accidental merge commits or rebases during a pull. Forces explicit integration choices.
  - Cons: Less convenient, requires more manual steps when divergence occurs.
  - Recommendation: Suitable for specific workflows or users who want maximum control, but generally less convenient than the default.
Action: Select the first option (Recommended): Default (fast-forward or merge). Click Next.

Step 13: Choose a Credential Helper

Screen Purpose: Configure how Git stores your credentials (username/password or personal access tokens) when connecting to remote repositories over HTTPS. Without a helper, you’d have to type your credentials every time you push or pull.
Options:
- Git Credential Manager Core (or similar name, might vary slightly):
  - What it does: Uses the modern, cross-platform Git Credential Manager (GCM Core). Securely stores your credentials using the underlying operating system’s secure storage (e.g., Windows Credential Manager). It also handles multi-factor authentication prompts for services like GitHub, GitLab, Azure DevOps, etc.
  - Pros: Secure, integrates well with Windows, supports modern authentication flows (including browser-based logins or token generation). Actively maintained.
  - Cons: None significant for most users.
  - Recommendation: Highly Recommended. This is the modern, secure, and convenient way to manage Git credentials on Windows.
- (Older versions might show “Git Credential Manager” or “WinCred”): These are older helpers. GCM Core is the successor. If GCM Core is offered, choose it. WinCred uses the Windows Credential Vault but lacks features of GCM Core.
- None:
  - What it does: Disables any credential helper. Git will prompt you for your username and password/token every single time it needs to authenticate with a remote repository over HTTPS.
  - Pros: Most “secure” in the sense that credentials are never stored automatically (but highly inconvenient).
  - Cons: Extremely inconvenient for frequent operations. Increases the chance of typos.
  - Recommendation: Strongly discouraged unless you have very specific security requirements mandating no stored credentials.
Action: Select Git Credential Manager Core (or the most similar modern option available). Click Next.

Step 14: Configure Extra Options

Screen Purpose: Enable or disable some additional performance and feature options.
Options:
- Enable file system caching:
  - What it does: Enables caching of file system data in memory (core.fscache). This can significantly speed up Git operations (like git status) by reducing the amount of disk I/O needed to check file statuses.
  - Pros: Performance improvement, especially on larger repositories or slower disks.
  - Cons: Uses slightly more memory. There’s a very small theoretical risk of cache becoming stale in rare edge cases (though generally reliable).
  - Recommendation: Keep checked (Recommended). The performance benefit usually outweighs any minor drawbacks.
- Enable symbolic links:
  - What it does: Allows Git to create and recognize symbolic links (symlinks) within the repository. Symlinks are like shortcuts or pointers to other files or directories. Creating symlinks on Windows requires special privileges (or Developer Mode enabled on recent Windows versions).
  - Pros: Necessary if your project uses symlinks and you need Git to manage them correctly.
  - Cons: Requires appropriate permissions to create symlinks. Can sometimes cause issues if not handled carefully across different operating systems (though Git tries to manage this).
  - Recommendation: Leave unchecked unless you know your project specifically requires symlink support. Windows handling of symlinks can be tricky, and many projects avoid them for cross-platform compatibility. You can always enable this later via git config core.symlinks true if needed.
Action: Keep Enable file system caching checked. Leave Enable symbolic links unchecked unless needed. Click Next.

Step 15: Configuring Experimental Options

Screen Purpose: Allows enabling features that are still under development and might not be fully stable or polished.
Options (These might change between Git versions):
- Enable experimental support for pseudo consoles:
  - What it does: Relates to how Git Bash (MinTTY) interacts with native Windows console applications, potentially improving compatibility using newer Windows ConPTY APIs.
  - Pros: Might fix certain edge-case issues when running specific Windows console tools inside Git Bash.
  - Cons: Experimental – could potentially introduce new issues.
  - Recommendation: Leave unchecked unless you are experiencing specific known issues that this feature is intended to address.
- Enable experimental built-in file system monitor:
  - What it does: Integrates with newer Windows features (if available) to more quickly detect file system changes, potentially speeding up commands like git status even further, especially in very large repositories.
  - Pros: Potential significant performance boost for status checks in huge projects.
  - Cons: Experimental, relies on specific Windows features/versions, might have bugs.
  - Recommendation: Leave unchecked unless you work with exceptionally large repositories and want to experiment with potential performance gains, accepting the risk of instability.
Action: Leave both experimental options unchecked for a standard, stable installation. Click Install.

Step 16: Completing the Git Setup Wizard

Screen Purpose: Installation is in progress. Files are being copied and configured based on your selections. This may take a minute or two.
After Installation: Once complete, you’ll see a final screen.
Options:
- ☐ Launch Git Bash: Check this box if you want Git Bash to open immediately after closing the installer.
- ☐ View Release Notes: Check this box to open the release notes for the installed version in your web browser.
Action: Choose whether to launch Git Bash or view release notes. Click Finish.

Congratulations! You have successfully navigated the Git for Windows installer and installed Git and Git Bash on your system.

6. Post-Installation Verification

Let’s quickly confirm that the installation worked as expected.

Opening Git Bash

If you checked “Launch Git Bash” in the final installer step, it should already be open.
Otherwise, go to your Start Menu, find the “Git” folder (or whatever you named it), and click on “Git Bash”.
Alternatively, if you enabled the context menu integration, navigate to any folder in File Explorer, right-click inside the folder (not on a file), and select “Git Bash Here”.

You should see a terminal window open with a command prompt, typically showing your username, hostname, current directory, and often the current Git branch (if inside a repository). It might look something like this:

bash User@Hostname MINGW64 ~ $

User@Hostname: Your username and computer name.
MINGW64: Indicates you’re in the 64-bit MSYS2 environment.
~: Represents your home directory (e.g., C:\Users\YourUsername).
$: The prompt symbol, waiting for your command.

Running `git --version` in Git Bash

Inside the Git Bash window, type the following command and press Enter:

bash git --version

You should see output similar to git version 2.xx.x.windows.x, confirming Git is installed and accessible within Git Bash.

Running `git --version` in Command Prompt / PowerShell (if PATH was adjusted)

If you selected the recommended second option (“Git from the command line and also from 3rd-party software”) during the PATH configuration step, you should also be able to run Git from Windows native shells.

Open Command Prompt (search cmd) or PowerShell.
Type git --version and press Enter.

You should see the same version output as in Git Bash. If you get a “‘git’ is not recognized…” error here, it means the PATH environment variable wasn’t updated correctly, or you need to restart any already open CMD/PowerShell windows (or sometimes even log out and log back in) for the new PATH settings to take effect.

7. Essential First-Time Git Configuration

Before you start using Git to track projects, there’s one crucial configuration step: telling Git who you are. Every commit you make in Git is stamped with an author name and email address. This is essential for tracking contributions and collaboration.

You should configure these settings globally, meaning they will apply to all Git repositories on your system for your user account. Open Git Bash (or CMD/PowerShell if git works there) and run the following two commands, replacing "Your Name" and "[email protected]" with your actual name and email address. Use the email address you associate with coding platforms like GitHub or GitLab if applicable.

Setting Your Username

bash git config --global user.name "Your Name"
(Example: git config --global user.name "Alice Wonderland")

Press Enter. There will be no output if the command is successful.

Setting Your Email Address

bash git config --global user.email "[email protected]"
(Example: git config --global user.email "[email protected]")

Press Enter. Again, no output indicates success.

Checking Your Configuration

To verify that the settings were applied correctly, you can list your global configuration:

bash git config --global --list

Or check specific settings:

bash git config --global user.name git config --global user.email

You should see the name and email you just entered.

Understanding `--global` vs. Local Configuration

--global: Applies the configuration to your user account across all repositories on your machine. The settings are stored in a file named .gitconfig in your user’s home directory (e.g., C:\Users\YourUsername\.gitconfig). This is what you typically use for your name and email.
--local (or default if run inside a repository): Applies the configuration only to the current repository. These settings are stored in the .git/config file within that specific repository. This can be used to override global settings for a particular project (e.g., using a work email for a work project and a personal email for a personal project).
--system: Applies the configuration system-wide for all users. Requires administrator privileges. Settings are stored in Git’s installation directory (e.g., C:\Program Files\Git\etc\gitconfig). Less commonly used for user-specific settings like name and email.

Git reads configuration from system, then global, then local levels, with later levels overriding earlier ones.

With your identity configured, you’re ready to start using Git!

8. Getting Started with Git Bash: Basic Usage

Let’s perform a few basic actions in Git Bash to get comfortable.

Navigating the File System (`pwd`, `ls`, `cd`)

Open Git Bash. You start in your home directory (~).
See where you are:
bash pwd
(Output might be /c/Users/YourUsername – Git Bash uses Unix-style paths)
List files and folders:
bash ls ls -la # List all (including hidden) in long format
Create a project directory and navigate into it:
bash mkdir my-first-project # Create a directory named 'my-first-project' cd my-first-project # Change directory into it pwd # Verify you are inside the new directory

Creating Files and Directories (`touch`, `mkdir`)

Inside my-first-project:

Create an empty file:
bash touch README.md
Create a subdirectory:
bash mkdir src
List contents:
bash ls
(Should show README.md and src/)

A Simple Git Workflow Example

Now, let’s initialize a Git repository in this directory and make our first commit.

Initialize Git: Tell Git to start tracking this directory.
bash git init
(Output: Initialized empty Git repository in C:/Users/YourUsername/my-first-project/.git/)
Notice a hidden .git directory is created. This is where Git stores all its history and metadata. ls -a will show it.
Check the Status: See what Git knows about your project.
bash git status
(Output shows “On branch main”, “No commits yet”, and lists README.md and src/ under “Untracked files”)
Stage Changes: Tell Git you want to include README.md in the next commit (snapshot).
bash git add README.md
(You can also use git add . to stage all changes in the current directory and subdirectories)
Check Status Again:
bash git status
(Output now shows README.md under “Changes to be committed”. src/ is still untracked.)
Commit Changes: Save the staged snapshot to the project history with a descriptive message.
bash git commit -m "Add initial README file"
(-m allows you to provide the commit message directly. If omitted, Git would open the default editor you configured earlier.)
(Output confirms the commit, showing the branch, commit hash, and files changed.)
Check Status One Last Time:
bash git status
(Output now shows “On branch main”, “nothing to commit, working tree clean”, but still lists src/ as untracked because we never added it.)
View History: See the commit you just made.
bash git log
(Output shows the commit hash, author (your configured name/email!), date, and commit message.)

This simple exercise demonstrates the fundamental Git cycle: modify files, git add to stage changes, git commit to save snapshots.

9. Integrating Git with Other Tools

While Git Bash is powerful, you’ll often interact with Git through other applications as well. Thanks to selecting the recommended PATH option during installation, this integration is usually straightforward.

IDEs (Integrated Development Environments):
- Visual Studio Code: Has excellent built-in Git support. The Source Control panel (Ctrl+Shift+G) allows you to view changes, stage, commit, push, pull, manage branches, and more visually. It automatically detects Git if it’s in the PATH.
- JetBrains IDEs (IntelliJ IDEA, PyCharm, WebStorm, etc.): Also feature robust Git integration. They typically detect Git automatically. You can manage everything via the VCS menu or the Git tool window.
- Visual Studio: Provides integrated Git tooling through the Team Explorer or the dedicated Git Changes window.
Graphical Git Clients: These standalone applications provide a visual interface for managing Git repositories. They can be helpful for visualizing branch history, resolving complex merges, or for users who prefer GUIs over CLIs. Popular options include:
- SourceTree: Free Git GUI for Windows and Mac by Atlassian.
- GitKraken: Polished, cross-platform Git GUI (free for non-commercial use, paid for pro features).
- GitHub Desktop: Free, simplified client focused on GitHub workflows.
- Fork: A fast and friendly Git client for Mac and Windows (paid).

These tools generally rely on the command-line Git installation being accessible via the system PATH.

10. Troubleshooting Common Installation Issues

While the installation is usually smooth, here are some potential hiccups:

git command not found:
- Did you select the recommended PATH option (Option 2)? If not, git will only work in Git Bash. You might need to reinstall and choose the correct PATH option.
- Restart your terminal/IDE: Open command prompts, PowerShell windows, or IDEs after the installation finishes. They might not pick up the new PATH variable immediately.
- Restart your computer: Sometimes a full restart is needed for PATH changes to propagate system-wide.
- Verify PATH Manually: Search for “Edit the system environment variables”, click “Environment Variables…”, and check both the “User variables” and “System variables” for Path. Look for an entry pointing to Git’s cmd directory (e.g., C:\Program Files\Git\cmd).
Firewall or Antivirus Interference: Occasionally, security software might mistakenly flag parts of the Git installer or the bundled OpenSSH as suspicious. Try temporarily disabling them during installation if you encounter unexplained failures (but remember to re-enable afterwards). Ensure your security software allows Git and SSH operations if you have network issues later.
Issues with SSH Keys: If you have trouble connecting to remote repositories via SSH after installation, ensure your SSH keys (id_rsa, id_ed25519, etc.) are correctly generated and located in the ~/.ssh directory within your Git Bash home (usually C:\Users\YourUsername\.ssh). Check permissions on the .ssh folder and key files.
Problems with the Default Editor: If Git fails when trying to open an editor (e.g., for a commit message), ensure the editor you selected during installation is correctly installed and its path is accessible. You can change the default editor later using git config --global core.editor "path/to/your/editor.exe". For VS Code, the command might be git config --global core.editor "code --wait".
Line Ending Conflicts: If you collaborate and see entire files marked as changed unexpectedly, double-check that all collaborators have configured Git’s line ending handling appropriately (ideally, the recommended “Checkout Windows-style, commit Unix-style” on Windows, and letting Git handle it natively on Linux/macOS). Use .gitattributes files in your repository for fine-grained control over line endings per file type.

11. Updating Git for Windows

It’s good practice to keep your Git installation up-to-date to benefit from bug fixes, security patches, and new features.

Using the Installer: The simplest way is to download the latest installer from the Git website and run it. It will detect the existing installation and update it, preserving your selected components and settings.
Using git update-git-for-windows: If you allowed Git to check for updates or want to trigger a check manually, open Git Bash as Administrator (right-click the Git Bash shortcut and select “Run as administrator”). Then run the command:
bash git update-git-for-windows
It will check for a newer version and, if found, prompt you to download and install it.

12. Uninstalling Git for Windows

If you need to remove Git from your system:

Go to Windows Settings > Apps > Apps & features.
Search for “Git”.
Select the “Git” entry and click “Uninstall”.
Follow the uninstaller prompts. It will remove the application files and attempt to clean up system modifications like PATH entries and context menus.
You might want to manually check your Environment Variables and Start Menu afterwards to ensure everything related to Git was removed cleanly.
User configuration files (like .gitconfig, .ssh keys in your home directory) and your actual Git repositories will not be deleted by the uninstaller. You need to remove those manually if desired.

13. Conclusion: Your Journey with Git Begins

Installing Git and Git Bash on Windows is the first step into a larger world of efficient development, collaboration, and project management. While the installer presents many options, understanding them allows you to tailor the setup to your workflow. By choosing sensible defaults – particularly regarding the PATH environment, default editor, and line ending conversions – you establish a robust foundation.

You now have the industry-standard version control system at your fingertips, accessible through the versatile Git Bash terminal and integrated with your favorite development tools. Don’t stop here! The real power of Git lies in understanding its concepts:

The staging area (git add)
Committing snapshots (git commit)
Viewing history (git log, git diff)
Undoing mistakes (git reset, git checkout, git revert)
Branching and merging (git branch, git checkout, git merge, git rebase)
Working with remote repositories (git clone, git remote, git fetch, git pull, git push)

Explore these commands, experiment in safe repositories, and leverage online resources, tutorials, and documentation. The investment in learning Git will pay dividends throughout your technical career. Welcome to the world of version control!

14. Glossary of Key Git Terms

Repository (Repo): A directory containing your project files and the entire history of changes, stored in a hidden .git sub-directory.
Working Directory (or Working Tree): The set of files currently checked out from the repository that you are actively editing.
Staging Area (or Index): A file in the Git directory that stores information about what will go into your next commit. You use git add to add changes from the Working Directory to the Staging Area.
Commit: A snapshot of the Staging Area at a specific point in time, saved to the repository’s history. Each commit has a unique SHA-1 hash identifier, an author, an email, a timestamp, and a commit message.
Branch: An independent line of development. It acts like a movable pointer to a specific commit. The default branch is often named main (or master). Branches allow you to work on features or fixes in isolation.
HEAD: A pointer that usually points to the currently checked-out branch or commit. It represents your current location in the project history.
Clone: Creating a full copy of a remote repository onto your local machine, including all files, history, and branches. (git clone)
Remote: A reference to another copy of the repository, typically hosted on a server (like GitHub, GitLab, Bitbucket). (git remote)
Fetch: Downloading commits and objects from a remote repository to your local repository, but without automatically merging them into your Working Directory. (git fetch)
Pull: Fetching changes from a remote repository and immediately trying to merge (or rebase) them into your currently checked-out local branch. Essentially git fetch followed by git merge (or git rebase). (git pull)
Push: Uploading your local commits (from a specific branch) to a remote repository, sharing your changes with others. (git push)
Merge: Combining changes from different branches into a single branch. Git attempts to automatically merge changes, but may require manual intervention if conflicts occur. (git merge)
Conflict: A situation where Git cannot automatically merge changes from different branches because they modify the same part of the same file in different ways. You must manually resolve the conflict before completing the merge.
Rebase: An alternative to merging for integrating changes. It rewrites commit history by taking commits from one branch and reapplying them on top of another branch, creating a linear history. (git rebase)
Fork: (Primarily a platform concept, e.g., on GitHub) Creating a personal copy of someone else’s repository on the server. You can then clone your fork, make changes, and propose them back to the original repository via a Pull Request.
Pull Request (PR) / Merge Request (MR): (Platform concept) A request to merge changes from your branch (often in a fork or a feature branch) into another branch (often the main branch) of a repository. It allows for code review and discussion before merging.
Git Bash: A Bash emulation environment for Windows, bundled with Git for Windows, providing a Linux-like command-line experience and Unix utilities.
Git GUI: A simple, graphical Tcl/Tk-based interface for basic Git operations, bundled with Git for Windows.
CRLF / LF: Line ending characters (Carriage Return + Line Feed for Windows, Line Feed for Unix/macOS). Git can be configured to handle conversions automatically.
PATH: An environment variable that tells the operating system where to look for executable files when you type a command.