I decided to create a structured guide to Git fundamentals, tailored for cloud admins like myself. While I’ve been using Git for years, I never took the time to learn it in a systematic way or document my knowledge. This guide is my attempt to gather the most important concepts and practices in one place. I’m sharing it here on my blog in case others find it helpful.

Content

Content

About Git

Git is a version control system that lets you track changes in your code, collaborate with others, and revert to earlier versions if needed. It’s widely used in software development.

Git was created in 2005 by Linus Torvalds, the developer behind the Linux kernel, as a response to issues with the existing version control systems used by the Linux kernel community.

With the need for a new version control system, Torvalds set out to design something that would meet the demands of a project as large and complex as the Linux kernel:

Speed: Since kernel development involved many contributors and huge volumes of code, the system needed to be fast and scalable.
Distributed Model: Unlike centralized systems where a single server holds the “truth” of the codebase, Git uses a distributed model, meaning every user has a complete copy of the entire project’s history. This was important for Linux because contributors were spread across the globe.
Non-linear Development: Linux contributors needed a tool that supported branching and merging, allowing multiple lines of development to progress simultaneously and be merged as needed.

In April 2005, Torvalds and other contributors built the first version of Git in just a few days. The tool quickly gained traction within the Linux community, and in the same year, Linus handed over the project to Junio Hamano, who became Git’s main maintainer. Hamano’s stewardship brought numerous improvements and refinements, making Git more user-friendly and powerful.

Setting Up Git

Install Git: Download from git-scm.com.
Configure Git: After installing, set up your user details (mandatory configuration):

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

Git Fundamentals

Understanding how Git works fundamentally revolves around a few key concepts, so let’s break them down one by one.

1. Repositories (Repos)

A Git repository is essentially the database where Git tracks and manages your project files and history. When you initialize a Git repo in a directory with git init, Git creates a hidden .git folder to store all the tracking information, snapshots, and changes.
Repositories can be either local (on your machine) or remote (like GitHub, GitLab, or Azure DevOps), which enables collaboration by synchronizing code changes across different computers.

In Git, origin is the default name used for a remote repository when you clone a repository to your local machine. It acts as a shorthand or alias for the URL of the remote repository. The name origin is just a convention, not a requirement. You can rename it or add additional remotes with different names. Commands like git pull and git push will interact with origin by default unless you specify a different remote.

To see the URL associated with origin:

git remote get-url origin

2. Working Tree

The working tree (or working directory) is the area where you do your actual work. When you edit files, you’re making changes in the working tree.
Git tracks changes in three places:
1. Working Directory: Files you’re currently editing.
2. Staging Area: Files you’ve prepared for committing.
3. Repository: Files you’ve committed (permanently saved).

3. Stages of Changes

Git uses three stages to manage your code changes:
- Untracked: Files that Git doesn’t yet track.
- Staged: Files that have been added to the staging area (using git add) and are ready for a commit.
- Committed: Files that have been saved to the repository, making a record of your changes.

4. Commits

A commit is a snapshot of changes in your repo at a particular point in time. Each commit has:
- A unique hash ID (SHA-1), making it identifiable.
- A commit message that describes what was changed.
Commits are organized into a commit history, which lets you revert to previous versions and see the evolution of your code over time.
Example of making a commit:

git add <filename> # Stages the file
git commit -m "Description of changes"

5. Branches

Git uses branches to allow multiple lines of development within a project. By default, you start on a branch called main (or master in older setups).
Branches let you experiment or develop new features independently. You can create a new branch, work on it, and then merge it back into the main branch once you’re done.
Creating and switching branches:

git branch <new-branch> # Creates a new branch
git checkout <new-branch> # Switches to the new branch

Merging branches lets you combine changes from one branch into another.

6. Push and Pull

Push: When you’re ready to share your changes with others, you can push them to a remote repository (e.g., GitHub).

git push origin <branch-name> # Sends changes in your branch to the remote repo

Pull: To bring in changes from the remote repository, you pull the latest updates. Pulling is a combination of fetching (downloading changes) and merging (integrating them into your branch).

git pull origin <branch-name> # Retrieves changes and merges them into your branch

7. Pull Requests (PRs)

A Pull Request (PR) is a feature of platforms like GitHub, GitLab, or Azure DevOps and isn’t technically part of Git itself, but it has become an essential workflow in collaborative development.
With a PR, you request that others review and approve your changes before they’re merged into a main or shared branch. It helps teams review code, comment on changes, and maintain quality.
PRs involve:
- Creating the PR: After pushing your changes, you go to the platform (like GitHub) to create a PR, detailing what changes are made and why.
- Reviewing and Approving: Team members can comment, suggest edits, and approve or request changes.
- Merging: Once approved, the PR can be merged into the target branch.

8. Cloning

Cloning a repo means making a complete copy of a remote repository on your local machine. When you clone, you download all the project files along with the full commit history.

git clone <repo-url>

Putting It All Together in a Typical Workflow

Here’s a quick example of how a workflow might look using these Git concepts:

Clone the repository if it’s not already on your machine.

git clone <repo-url>

Create a Branch for your new feature or fix.

git checkout -b new-feature

Make Changes in your working directory and stage them.

git add .

Commit your changes with a message.

git commit -m "Add new feature"

Push the branch to the remote repository.

git push origin new-feature

Create a Pull Request on GitHub or GitLab for review.
Review and Merge the PR after approval, bringing it into the main branch.
Pull the latest changes if others have updated the main branch, keeping your local repo in sync.

Basic Git Commands

Initialize a Local Repository (rarely used): This creates a new Git repository in your project directory.

git init

Check Status: This shows the status of your files in the repo (modified, staged, or committed).

git status

Add Files to Staging: Prepares changes to be committed.

git add <filename> # or git add . to add all

Remove Files from Staging: Remove files if you don’t want to commit them anymore.

git reset <filename> # just git reset to remove all staged files

Commit Changes: Saves your staged changes with a message describing them.

git commit -m "Your commit message"

Undo Recent Commits: If you’ve already committed changes and want to “unstage” that commit.

git reset HEAD~1

Working with Remote Repositories

This is how to work with Remote Repositories (like thoes on GitHub or Azure DevOps).

Clone a Repo: Copy an existing Git repo from a server.

git clone <repo-url>

Push Changes: Send your committed changes to a remote repo.

git push origin <branch>

Pull Changes: Fetch and integrate changes from a remote repo.

git pull origin <branch>

Branches

Create a New Branch: Useful for working on separate features or bug fixes.

git branch <branch-name>
git checkout <branch-name> # Switch to the branch

Merge Branches: Integrate changes from one branch into another.

git checkout main # Go to main branch
git merge <branch-name> # Merge branch into main

Handling Conflicts

Handling conflicts in Git is an essential skill for managing collaborative work, especially when multiple developers are working on the same files. Conflicts occur when Git cannot automatically merge changes from different branches or contributors. Here’s a comprehensive guide on how to identify, resolve, and prevent conflicts.

When Do Conflicts Happen?

Conflicts typically arise in scenarios such as:

Merging branches: When two branches have changes in the same file and on the same lines.
Rebasing: When applying commits from one branch onto another conflicts with existing changes.
Cherry-picking: When manually applying a commit from one branch to another.
Pulling changes: When you pull from a remote branch and it has changes that conflict with your local modifications.

How to Handle Conflicts

Here’s a step-by-step process for resolving conflicts in Git:

1. Detecting a Conflict

When a conflict occurs, Git will:

Pause the operation (e.g., merge or rebase).
Mark the files in conflict with a status of CONFLICT in the terminal.
Provide a message indicating the conflicting files.

You can run git status to see the files with conflicts:

$ git status
# On branch main
# You have unmerged paths.
#   (fix conflicts and run "git commit")
#
# Unmerged paths:
#   (use "git add <file>..." to mark resolution)
#
#       both modified:   file.txt

2. Locate the Conflict

Open the conflicted file(s) in your code editor. Git will insert conflict markers like this:

<<<<<<< HEAD
Your changes (from the current branch)
=======
Changes from the branch you are merging or rebasing
>>>>>>> branch_name

The section between <<<<<<< HEAD and ======= shows your changes.
The section between ======= and >>>>>>> branch_name shows the incoming changes.

3. Resolve the Conflict

Decide how to handle the conflicting changes. There are three main approaches:

Keep Your Changes: Delete the incoming changes (the section after =======) and keep your changes.
Accept Incoming Changes: Delete your changes (the section before =======) and keep the incoming changes.
Combine Changes: Merge both changes manually to create a new, unified version.

After editing the file, remove the conflict markers (<<<<<<<, =======, >>>>>>>) and save the file.

4. Mark the Conflict as Resolved

Once you’ve resolved the conflict, stage the file:

git add file.txt

5. Complete the Merge or Rebase

After resolving all conflicts, complete the operation:

For a merge:git commit (Git auto-generates a commit message for the merge.)
For a rebase:git rebase --continue

Tools to Resolve Conflicts

Many tools and editors simplify conflict resolution. Some popular ones include:

1. Visual Studio Code (VS Code)

VS Code highlights conflicts visually, showing “Current Change” (your changes) and “Incoming Change” (from the branch being merged). You can:

Click “Accept Current Change”, “Accept Incoming Change”, or “Accept Both Changes” directly in the editor.
Use the built-in merge editor for a side-by-side comparison.

2. Git GUI Tools

GitKraken, Sourcetree, and GitHub Desktop provide GUI interfaces to resolve conflicts easily.
They display conflicts graphically and allow you to pick changes interactively.

3. Command-Line Merge Tools

Git integrates with tools like vimdiff, kdiff3, or meld for resolving conflicts via the command line.
To use one, run:

git mergetool

Best Practices for Avoiding Conflicts

Pull Changes Frequently: Regularly pull changes from the remote branch to minimize divergence between your branch and the main branch.
- git pull origin main
Use Smaller Commits: Break your work into smaller, focused commits. This makes conflicts easier to resolve if they arise.
Communicate with Your Team: Coordinate with teammates to avoid working on the same files or sections of code simultaneously.
Use Feature Branches: Develop features in isolated branches and merge them back when ready.
Rebase Before Merging: If you’re working on a long-lived branch, rebase it onto the main branch before merging to minimize conflicts.
- git rebase main

Example Conflict Resolve Workflow

Scenario: You are merging a feature branch into `main`.

Switch to the Main Branch:
- git checkout main
Pull Latest Changes:
- git pull origin main
Merge the Feature Branch:
- git merge feature-branch
Resolve Conflicts (if any):
- Open conflicted files in VS Code or your preferred tool.
- Edit the file to resolve conflicts, then stage the changes:
  - git add resolved-file.txt
Complete the Merge:
- git commit
Push the Changes:
- git push origin main

Handling conflicts can initially seem challenging, but with practice and the right tools, it becomes manageable.

The .git Folder

The .git folder is the hidden directory in your project folder that Git uses to store all the information about your repository, including configurations, history, and metadata. It’s the “brain” of the repository, where all the tracking happens. Let’s break down its main components.

Main Contents of the `.git` Folder

HEAD
- The HEAD file is a pointer to the current branch’s latest commit. It tells Git which branch or commit you’re currently working on.
- For example, if you’re on the main branch, HEAD will point to refs/heads/main.
config
- The config file stores repository-specific configurations, such as remote repository URLs and specific settings. You can modify this manually, but usually, you configure these settings with git config.
index
- Also known as the “staging area,” this file is where Git temporarily stores information about staged changes (added files) before committing them. Git uses this to track what changes will be included in the next commit.
hooks/
- The hooks/ folder contains scripts that Git runs at specific points in the workflow. These can include tasks like:
  - Pre-commit: Runs checks before a commit, such as formatting or linting.
  - Pre-push: Ensures tests pass before pushing code to a remote repository.
- You can customize these scripts to automate tasks or enforce rules on commits and pushes.
objects/
- The objects/ folder is where Git stores all your data: commits, files, and trees (which represent directories).
- Git saves data as “blobs” (binary large objects), each with a unique SHA-1 hash. The objects/ directory’s structure is organized by hash, e.g., an object 3f45c is stored in objects/3f/45c....
- This is the foundation of Git’s snapshot model, where each object represents a specific state of a file or directory, rather than tracking line-by-line changes.
refs/
- The refs/ folder stores pointers to commits in the form of:
  - heads/: Each branch’s latest commit.
  - tags/: Points to specific points in history that are often used for releases or versioning.
  - remotes/: Keeps track of remote branches, so you know the last commit state of each remote branch (e.g., origin/main).
logs/
- The logs/ folder stores logs of every movement of HEAD and each branch, tracking branch checkouts, resets, and other actions.
- This is helpful for recovering lost commits if you accidentally reset a branch since it maintains a history of branch states.
description
- Primarily used in older Git setups and non-GitHub hosted repositories, this file stores a short description of the repository. It’s not used in most setups nowadays.
info/
- The info/ directory contains additional configuration options, such as a exclude file, which is a repository-level ignore file similar to .gitignore but local to only this repository and not usually committed.
packed-refs

Over time, Git might consolidate the references in refs/ into a single packed-refs file to improve performance. Instead of having individual files for each reference, this file holds them all together, which is faster to read for large repositories.

Summary of How These Work Together

When you make changes in a repository, Git uses the index to track staged files, which are then committed into the objects directory, creating blobs for each file. Each commit, stored in objects, points to a previous commit, forming a history chain. The refs keep track of the latest commit in each branch, and the logs file tracks every change made to HEAD, making it easy to review past actions.

Each file or subfolder in .git serves a specific purpose, but together, they enable Git to manage everything from staging to history tracking and syncing with remote repositories. Let me know if you’d like to dive into any of these components further!

The .gitignore File – Exclude Files and Folders

The .gitignore file is an important part of Git that lets you tell Git which files or directories to ignore in a repository. This is helpful for excluding files that shouldn’t be tracked, such as temporary files, build artifacts, or sensitive information like configuration files with API keys.

The .gitignore file is typically created in the root directory of your Git repository (not the .git folder). This is where it will be most effective at ignoring files and folders throughout the entire project.

When you add patterns to a .gitignore file, Git checks each file against those patterns before adding it to the staging area. Files matching the .gitignore rules will not be tracked or staged. If you later decide to track these files, you’ll need to update .gitignore and un-ignore the files.

Example:

# Ignore all .log files
*.log

# Ignore the node_modules directory
node_modules/

# Ignore a specific config file
config/settings.json

Azure DevOps

Azure DevOps is a cloud-based service from Microsoft that provides a suite of development tools for planning, building, testing, and delivering software. It enables teams to work together efficiently on projects, especially when managing code, tasks, and deployments. Azure DevOps integrates tightly with Git, allowing for streamlined version control, CI/CD pipelines, and project management.

What Azure DevOps Is

Azure DevOps is a set of services for managing the entire software development lifecycle (SDLC). It’s designed to support DevOps practices, which aim to unify software development (Dev) and IT operations (Ops) to improve the speed, quality, and reliability of software releases.

Key Services in Azure DevOps

Azure Repos
- This is Azure DevOps’ version control system, where Git repositories are hosted. It provides a place to store and manage code, track changes, and collaborate.
- Azure Repos supports both Git (distributed version control) and Team Foundation Version Control (TFVC), though Git is more common.
Azure Pipelines
- Pipelines support Continuous Integration (CI) and Continuous Delivery (CD), automating the building, testing, and deployment of applications.
- CI/CD pipelines are crucial for DevOps, as they reduce manual intervention, automate testing, and provide fast feedback loops for code changes.
Azure Boards
- Boards is a project management tool that supports Agile workflows, including Kanban, Scrum, and custom workflows.
- It helps teams manage work items, track progress, and collaborate using backlogs, sprint planning, and dashboards.
Azure Test Plans
- Test Plans offer manual and exploratory testing tools, helping teams ensure quality throughout the SDLC.
- It supports test case management, testing configurations, and tracking test results, both for automated and manual tests.
Azure Artifacts
- Artifacts provide a way to manage dependencies by hosting package feeds like NuGet, npm, and Maven.
- This service makes it easier to share and reuse code packages across projects, which can improve consistency and reduce duplication.

Key Capabilities of Azure DevOps

Code Collaboration: With Azure Repos, developers can collaborate using pull requests, code reviews, and branch policies, ensuring that only reviewed and tested code gets merged.
Automated Builds and Deployments: Azure Pipelines allows for automation of the build, test, and deploy phases, enabling faster and more reliable releases.
Work Item Tracking: Azure Boards manages project tasks, bugs, and other work items, allowing teams to plan, track, and manage development progress.
Testing Integration: Azure Test Plans integrate testing into the development lifecycle, supporting both manual and automated tests.
Artifact Management: With Azure Artifacts, teams can create and share libraries, manage dependencies, and standardize package management across the organization.

How Azure DevOps Relates to Git

Version Control with Git: Azure DevOps uses Git as its primary version control system through Azure Repos. Each repository in Azure Repos is a Git repository, where developers can:
- Commit code changes
- Create branches for feature development or bug fixes
- Use pull requests to review and approve changes
- Push and pull changes between local Git repositories and Azure Repos
CI/CD Pipelines with Git Triggers: Azure Pipelines can automatically trigger builds and deployments based on Git events like commits, merges, or pull requests.
- This automation ensures that every code change is built, tested, and potentially deployed to staging or production environments.
- For example, you can set up a pipeline to run tests every time a pull request is opened, giving you immediate feedback on the quality of new code.
Branching Policies: Azure DevOps supports policies for Git branches, such as requiring pull request reviews or running specific checks before allowing a branch to be merged.
- These policies help maintain high code quality and prevent bugs from entering the main codebase.
Integration with GitHub: Azure DevOps can also integrate with GitHub, allowing teams that use GitHub for code hosting to connect to Azure DevOps for CI/CD pipelines, work tracking, and more.

When to Use Azure DevOps

Azure DevOps is ideal for teams that need an all-in-one solution for managing their SDLC. It’s particularly useful for:

Agile teams that need structured project tracking and visibility into development progress.
Organizations looking to implement DevOps practices, such as CI/CD and automated testing.
Teams working in cloud or hybrid cloud environments, especially those already using Azure services.

Example Workflow with Azure DevOps

Planning: Use Azure Boards to create tasks, plan sprints, and manage work items.
Coding: Store code in Azure Repos, using Git for version control. Developers create branches, make commits, and open pull requests.
Building & Testing: Azure Pipelines automatically builds the code and runs tests whenever changes are pushed to a branch or a pull request is opened.
Deploying: After tests pass, Azure Pipelines can deploy code to staging or production environments.
Monitoring & Feedback: Use dashboards in Azure Boards or integration with Azure Monitor to track progress, monitor application performance, and gather user feedback.

Azure DevOps streamlines the process from code to deployment, making it a powerful tool for teams working with Git and pursuing DevOps practices.

GitHub

GitHub is a widely used platform for hosting and managing Git repositories. Acquired by Microsoft in 2018, GitHub has evolved to include powerful tools for version control, collaboration, and DevOps, making it a central tool for many developers and teams.

What GitHub Is

GitHub is a cloud-based service that provides Git repository hosting along with tools for version control, collaboration, project management, and CI/CD. It’s designed to help teams work together on code, track changes, and deliver high-quality software. GitHub offers both free and paid plans and can be hosted on-premises with GitHub Enterprise.

Key Features of GitHub

Git Repository Hosting
- GitHub hosts Git repositories, allowing you to store, manage, and share your code with others. Each repository can contain files, folders, branches, and commit history, making it easy to collaborate and keep track of project changes.
- GitHub uses Git’s distributed nature, allowing users to clone repositories, work offline, and sync changes back to GitHub.
Pull Requests (PRs)
- Pull requests are central to GitHub’s collaboration model. They allow developers to propose changes to a codebase by creating branches, making modifications, and then asking others to review and merge these changes.
- PRs include features like code reviews, discussions, and automated checks (tests, linting) to ensure code quality before merging.
Issues and Project Boards
- GitHub provides an issue tracking system for managing tasks, bugs, and feature requests.
- GitHub Projects adds a layer of project management with Kanban-style boards, helping teams organize tasks, plan sprints, and track progress.
GitHub Actions
- GitHub Actions is GitHub’s built-in CI/CD and automation tool, allowing you to automate workflows directly within GitHub.
- You can use Actions to set up pipelines that build, test, and deploy code based on events like pushes, pull requests, or schedule triggers.
Code Spaces and Development Environments
- GitHub Codespaces allows you to spin up a cloud-based development environment directly within GitHub. This is helpful for teams who want a consistent environment without setup hassle.
- It integrates Visual Studio Code and supports custom configurations.
Packages
- GitHub Packages allows you to host and manage code packages in formats like Docker, npm, and Maven.
- You can use GitHub Packages to share libraries, binaries, or dependencies privately within your organization or publicly with the GitHub community.
Security and Compliance Tools
- GitHub includes a range of security tools like Dependabot for dependency vulnerability scanning, secret scanning, and code scanning for identifying security issues.
- These tools are part of GitHub Advanced Security and help teams protect code and ensure compliance.

How GitHub Relates to Git

Version Control with Git: GitHub’s core functionality is built around Git, the version control system. You can:
- Push code changes from your local Git repository to GitHub to share with collaborators.
- Pull code from GitHub to sync changes made by others.
- Create and manage branches for feature development, bug fixes, and more.
- Use pull requests to review, discuss, and merge changes.
GitHub Flow and Git Flow: GitHub’s workflow typically follows either GitHub Flow (a simpler model where you create branches for features, merge to the main branch, and deploy frequently) or Git Flow (a more structured branching model that includes main, develop, feature, release, and hotfix branches).
- GitHub Flow is especially popular for teams practicing continuous integration and continuous deployment (CI/CD).
GitHub Actions for Git-Based CI/CD: GitHub Actions provides automated CI/CD capabilities, enabling users to trigger workflows based on Git events like push or pull request.
- This makes GitHub a powerful DevOps tool, as Actions can automate testing, building, and deploying code upon every Git event.
GitHub CLI: The GitHub Command Line Interface (CLI) allows users to interact with GitHub directly from the terminal, providing commands to create and manage pull requests, issues, repositories, and more.

When to Use GitHub

GitHub is ideal for open-source development, small and large teams, and organizations looking for a collaborative coding platform that also supports CI/CD and project management. It’s particularly beneficial when:

Teams are distributed and need a central code repository.
Developers need to collaborate on code, review changes, and track issues.
Open-source projects need a platform to manage contributors, documentation, and releases.
Organizations want to automate testing, building, and deployment pipelines with GitHub Actions.

Example Workflow with GitHub

Planning: Use GitHub Issues to track tasks, and set up a GitHub Project board for sprint planning.
Coding: Each developer clones the repository, creates a new branch for their work, and pushes changes to GitHub.
Reviewing: Developers open a pull request for review, where other team members review the code, run checks, and approve changes.
Testing and Deployment: With GitHub Actions, automated workflows build and test the code. If all checks pass, the code is merged and may even be automatically deployed.
Tracking and Monitoring: Use GitHub Insights and Actions logs to track build status, recent activity, and project metrics.

Key Differences Between GitHub and Azure DevOps

While GitHub and Azure DevOps have similar capabilities, here are some key distinctions:

Project Management: Azure DevOps Boards offer more advanced Agile tools than GitHub’s Project boards, making it better suited for Agile workflows.
CI/CD: GitHub Actions is tightly integrated with GitHub and is great for Git-centric workflows. Azure Pipelines, meanwhile, is more flexible in supporting multiple repositories and languages outside of Git.
Collaboration: GitHub is often the go-to choice for open-source projects due to its community focus, while Azure DevOps may be preferred by enterprises for its integration with other Microsoft products like Azure and Teams.

GitHub provides a rich set of tools for version control, collaboration, CI/CD, and project management, making it a powerful option for teams practicing DevOps and open-source development.

Visual Studio Code

Visual Studio Code (VS Code) is a powerful, lightweight code editor developed by Microsoft. It’s widely used for software development due to its flexibility, extensive extensions library, and seamless integration with various development tools and services, including Git. This integration allows developers to perform version control tasks directly from the editor, making VS Code a popular choice for working with Git repositories.

What VS Code Is

VS Code is an open-source, cross-platform code editor available on Windows, macOS, and Linux. It supports a broad range of programming languages and offers powerful features like debugging, IntelliSense (contextual code suggestions), extensions, and built-in terminal access.

How VS Code Integrates with Git

VS Code has built-in support for Git, allowing you to manage your repository directly from the editor. Here’s an overview of how it integrates:

Source Control Panel:
- The Source Control panel in VS Code provides a summary of Git changes, including tracked, untracked, staged, and unstaged files.
- You can open this panel by clicking the Source Control icon (often represented by a branch or Git icon) on the left sidebar or by using the shortcut Ctrl+Shift+G (Windows/Linux) or Cmd+Shift+G (macOS).
Staging and Unstaging Changes:
- VS Code allows you to stage or unstage files individually or in bulk, which prepares them for committing.
- Simply click the + icon next to each file to stage it, or click the – to unstage.
Commits:
- You can commit changes directly from VS Code by entering a commit message in the Source Control panel and pressing Ctrl+Enter (Windows/Linux) or Cmd+Enter (macOS).
- If you have staged changes, this action will commit them. If nothing is staged, it will prompt you to commit all changes, offering flexibility.
Branch Management:
- VS Code makes it easy to create, switch, and manage branches.
- The branch selector, located in the lower-left corner, lets you switch to another branch, create a new branch, or even publish branches to a remote repository.
- You can also merge branches, rebase, or pull changes from this branch menu.
Pull, Push, and Sync:
- The editor allows you to pull changes from a remote repository, push local commits, and sync your changes easily.
- These options appear in the status bar, and the Source Control panel provides additional options, like fetching changes from the remote repository.
Pull Requests with GitHub Extension:
- If you use GitHub, the GitHub Pull Requests and Issues extension adds features like opening pull requests, reviewing changes, and commenting directly within VS Code.
- This is especially useful for teams that manage pull requests on GitHub and want to perform reviews and discussions without leaving the editor.
GitLens Extension:
- For more advanced Git functionalities, VS Code supports the GitLens extension, which enhances Git integration by providing insights into commit history, code annotations, branch comparisons, and much more.
- It’s ideal for developers who want in-depth Git details or need help tracking complex code histories.
Built-In Diff Tool:
- VS Code includes a diff tool that highlights changes between your working directory, the staged area, and previous commits.
- It displays a side-by-side view of changes, making it easy to see what was modified, added, or deleted.
Terminal Integration:
- VS Code has an integrated terminal, allowing you to run Git commands directly from the editor.
- This is especially useful if you need to perform Git tasks that may not be supported by the GUI or if you’re comfortable with command-line Git commands.

Example Git Workflow in VS Code

Clone a Repository: Use the command palette (Ctrl+Shift+P or Cmd+Shift+P), type Git: Clone, and paste the URL of your Git repository. VS Code will clone the repo and open it in the editor.
Make Changes: Edit files in your repository as needed. Modified files appear in the Source Control panel.
Stage and Commit: Once changes are made, stage them by clicking the + icon next to each file (or click the Stage All Changes button). Then, enter a commit message and press Ctrl+Enter or Cmd+Enter to commit.
Push to Remote: When ready, push your commits to the remote repository by clicking the Push button in the Source Control panel or the status bar.
Pull Updates: If there are changes in the remote repository, use Pull to fetch and merge these changes into your local branch.
Create a Pull Request (GitHub Only): If you’re on GitHub and want to merge changes to the main branch, you can use the GitHub Pull Requests and Issues extension to create a pull request without leaving VS Code.

Benefits of Using VS Code with Git

All-in-One Development Environment: VS Code combines code editing, Git management, and terminal access, so you can handle all development tasks without switching tools.
Enhanced Productivity: Features like inline diff views, branch management, and GitLens make it easy to track changes and maintain code quality.
Collaborative Features: The GitHub extension brings GitHub pull requests, issues, and comments into the editor, making team collaboration easier.
Customizability: You can extend VS Code’s Git capabilities with extensions like GitLens, Git Graph, and Git History, tailoring your Git workflow.

VS Code and GitHub Integration

VS Code has built-in support for GitHub, making it easy to:

Clone repositories directly from GitHub.
Create and review pull requests with the GitHub Pull Requests and Issues extension.
Manage issues by viewing, creating, and commenting on GitHub issues from within VS Code.
Collaborate in real-time with GitHub Codespaces, which allows you to develop in a cloud-based version of VS Code.

Overall, VS Code’s Git integration provides a smooth and efficient way to manage source control tasks, making it a versatile tool for developers working with Git repositories.

Git Security Risks

Using Git can pose security risks if not managed carefully, particularly in collaborative environments or when dealing with sensitive data. Below are the key security risks associated with Git and how to mitigate them:

Key Security Risks with Git

1. Accidentally Committing Sensitive Data

Risk: Sensitive information like passwords, API keys, private keys, or other credentials may be inadvertently committed to the repository.
Example: Including a .env file with secrets in the commit history.
Impact:
- Exposes credentials publicly if the repository is public.
- Even in private repositories, internal threats or leaks can occur.

Mitigation:

Use .gitignore to exclude sensitive files (e.g., .env, config.yml).
Scan repositories for secrets using tools like GitGuardian, truffleHog, or git-secrets.
Rotate credentials immediately if they are exposed.

2. Exposing History Through Public Repositories

Risk: Sensitive information committed to Git, even if removed later, remains in the repository history.
Example: A password committed and then removed still exists in the Git commit history.
Impact:
- Attackers can retrieve sensitive information from history by cloning the repository.

Mitigation:

Use git filter-repo or BFG Repo-Cleaner to rewrite history and remove sensitive data.
Avoid pushing changes until you are sure no sensitive data is included.

3. Misconfigured Permissions on Repositories

Risk: Providing overly broad access to repositories or teams.
Example: Giving “write” or “admin” access to untrusted collaborators.
Impact:
- Unauthorized users can push malicious code, steal data, or disrupt development.

Mitigation:

Use least privilege access: only provide the necessary permissions.
Regularly audit repository permissions.
Use organization-wide rules in platforms like GitHub or Azure DevOps.

4. Vulnerabilities in Dependencies

Risk: Including insecure or outdated dependencies in your repository.
Example: Committing vulnerable third-party libraries to a project.
Impact:
- Can lead to attacks like dependency confusion or supply chain attacks.

Mitigation:

Use dependency scanning tools like Dependabot, Snyk, or WhiteSource.
Regularly update dependencies and review their security advisories.

5. Insufficient Protection of Remote Access

Risk: Using insecure protocols or leaving repositories accessible without authentication.
Example: Using HTTP instead of HTTPS for Git remotes or SSH keys without passphrases.
Impact:
- Man-in-the-middle attacks or unauthorized repository access.

Mitigation:

Always use HTTPS or SSH for accessing remote repositories.
Use SSH keys with passphrases for additional security.
Enforce two-factor authentication (2FA) on platforms like GitHub.

6. Exposed `.git` Directory

Risk: Hosting .git directories on public web servers.
Example: Deploying a website that inadvertently includes the .git folder.
Impact:
- Attackers can clone the repository and retrieve sensitive information.

Mitigation:

Never upload the .git directory to production servers.
Use web server configurations to block access to .git directories (e.g., .htaccess for Apache or nginx rules).

7. Unverified Commits and Tags

Risk: Accepting unverified code changes or tags.
Example: Merged code or tags signed by unauthorized users.
Impact:
- Could introduce malicious code or result in dependency confusion.

Mitigation:

Use GPG signing for commits and tags to verify authenticity.
Require commit signing in protected branches (available in GitHub or GitLab).

8. Inadequate Branch Protection

Risk: Allowing direct commits or force pushes to critical branches like main.
Example: An unintentional git push --force overwrites shared changes.
Impact:
- Data loss or the introduction of bad code.

Mitigation:

Enable branch protection rules:
- Require pull requests for changes.
- Disallow force pushes.
- Require status checks and reviews before merging.

9. Lack of Audit Logs

Risk: Inability to track who made changes to critical branches or repositories.
Example: A malicious user pushes bad code, and no one knows who did it.
Impact:
- Harder to identify the source of issues in collaborative environments.

Mitigation:

Use Git platforms with logging and auditing features (e.g., GitHub, GitLab, Azure DevOps).
Implement CI/CD pipelines for automated checks.

Risk: Attackers may impersonate trusted contributors or maintainers.
Example: Receiving a malicious pull request or email with a forged commit.
Impact:
- Could lead to introducing malware or compromising systems.

Mitigation:

Verify contributors’ identities, especially for high-impact repositories.
Educate teams on phishing and social engineering risks.

Summary Table of Risks and Mitigation

Risk	Impact	Mitigation
Committing sensitive data	Credential exposure	Use `.gitignore`, rotate keys, scan for secrets.
Exposed Git history	Leaks sensitive data from history	Use `git filter-repo` or BFG to clean history.
Misconfigured permissions	Unauthorized access	Enforce least privilege and audit permissions.
Vulnerabilities in dependencies	Supply chain attacks	Use dependency scanning tools like Dependabot.
Insecure remote access	Unauthorized repository access	Use HTTPS/SSH, enable 2FA.
`.git` directory exposure	Full repository download	Block `.git` in web servers.
Unverified commits or tags	Potentially malicious code	Require GPG-signed commits and tags.
Inadequate branch protection	Data loss or bad code in critical branches	Enable branch protection rules.
Lack of audit logs	Difficult to trace issues	Use platforms with audit logging.
Phishing/social engineering	Malicious code introduction	Verify contributors and educate team members.

Git Command Reference Table

Here’s a comprehensive Git Command Reference Table organized with the columns: Command, Description, and Example. It includes essential commands for everyday use as well as some advanced operations.

Command	Description	Example
`git init`	Initialize a new Git repository.	`git init my-repo`
`git clone`	Clone a repository from a remote source.	`git clone https://github.com/user/repo.git`
`git status`	Show the working directory status, including untracked files.	`git status`
`git add`	Stage files for the next commit.	`git add file.txt` `git add .` (to stage all changes)
`git reset`	Unstage files or reset changes in the working directory.	`git reset file.txt` (unstage file) `git reset --hard HEAD` (discard changes)
`git commit`	Record changes in the repository.	`git commit -m "Commit message"`
`git log`	Show commit history.	`git log` `git log --oneline` (short format)
`git diff`	Show changes between commits, branches, or the working tree.	`git diff` `git diff HEAD file.txt`
`git branch`	List, create, or delete branches.	`git branch` (list branches) `git branch feature` (create branch)
`git checkout`	Switch branches or restore files.	`git checkout main` `git checkout file.txt` (restore file)
`git switch`	Switch to a different branch (modern alternative to checkout).	`git switch main`
`git merge`	Merge one branch into another.	`git merge feature-branch`
`git rebase`	Apply commits from one branch onto another.	`git rebase main`
`git pull`	Fetch and integrate changes from a remote repository.	`git pull origin main`
`git push`	Push local commits to a remote repository.	`git push origin main`
`git fetch`	Download changes from a remote repository without merging.	`git fetch origin`
`git stash`	Temporarily save changes without committing.	`git stash` (save changes) `git stash apply` (restore changes)
`git tag`	Create, list, or delete tags.	`git tag v1.0` `git tag -d v1.0`
`git remote`	Manage remote repositories.	`git remote add origin https://github.com/user/repo.git` `git remote -v` (list remotes)
`git show`	Show details about a commit, branch, or tag.	`git show HEAD`
`git rm`	Remove files from the working directory and staging area.	`git rm file.txt`
`git mv`	Move or rename a file.	`git mv old-name.txt new-name.txt`
`git blame`	Show who made changes to each line of a file.	`git blame file.txt`
`git clean`	Remove untracked files from the working directory.	`git clean -f` (files) `git clean -fd` (files and directories)
`git config`	Configure Git settings (global or local).	`git config --global user.name "Your Name"` `git config --global user.email "email"`
`git archive`	Create a tar or zip archive of a repository.	`git archive --format=zip HEAD > archive.zip`
`git cherry-pick`	Apply a specific commit to the current branch.	`git cherry-pick <commit-hash>`
`git revert`	Create a new commit that undoes changes in a previous commit.	`git revert <commit-hash>`
`git bisect`	Perform binary search to find the commit causing an issue.	`git bisect start` `git bisect bad` `git bisect good`
`git submodule`	Manage submodules within a repository.	`git submodule add <repo-url>` `git submodule update --init`
`git worktree`	Add multiple working directories for the same repository.	`git worktree add ../new-branch`
`git mergetool`	Use an external tool to resolve merge conflicts.	`git mergetool`
`git log --graph`	Visualize branch and merge history.	`git log --graph --oneline`
`git reflog`	View the history of HEAD movements (useful for recovery).	`git reflog`

Content

About Git

Setting Up Git

Git Fundamentals

1. Repositories (Repos)

2. Working Tree

3. Stages of Changes

4. Commits

5. Branches

6. Push and Pull

7. Pull Requests (PRs)

8. Cloning

Putting It All Together in a Typical Workflow

Basic Git Commands

Working with Remote Repositories

Branches

Handling Conflicts

When Do Conflicts Happen?

How to Handle Conflicts

1. Detecting a Conflict

2. Locate the Conflict

3. Resolve the Conflict

4. Mark the Conflict as Resolved

5. Complete the Merge or Rebase

Tools to Resolve Conflicts

1. Visual Studio Code (VS Code)

2. Git GUI Tools

3. Command-Line Merge Tools

Best Practices for Avoiding Conflicts

Example Conflict Resolve Workflow

Scenario: You are merging a feature branch into main.

The .git Folder

Main Contents of the .git Folder

Summary of How These Work Together

The .gitignore File – Exclude Files and Folders

Azure DevOps

What Azure DevOps Is

Key Services in Azure DevOps

Key Capabilities of Azure DevOps

How Azure DevOps Relates to Git

When to Use Azure DevOps

Example Workflow with Azure DevOps

GitHub

What GitHub Is

Key Features of GitHub

How GitHub Relates to Git

When to Use GitHub

Example Workflow with GitHub

Key Differences Between GitHub and Azure DevOps

Visual Studio Code

What VS Code Is

How VS Code Integrates with Git

Example Git Workflow in VS Code

Benefits of Using VS Code with Git

VS Code and GitHub Integration

Git Security Risks

Key Security Risks with Git

1. Accidentally Committing Sensitive Data

2. Exposing History Through Public Repositories

3. Misconfigured Permissions on Repositories

4. Vulnerabilities in Dependencies

5. Insufficient Protection of Remote Access

6. Exposed .git Directory

7. Unverified Commits and Tags

8. Inadequate Branch Protection

9. Lack of Audit Logs

10. Phishing and Social Engineering

Summary Table of Risks and Mitigation

Git Command Reference Table

Share this:

Published by Daniel Chronlund

Leave a comment

Scenario: You are merging a feature branch into `main`.

Main Contents of the `.git` Folder

6. Exposed `.git` Directory