Everything You Need to Know About GIT

Introduction

Version control is an essential part of modern software development, and Git is the most widely used version control system. Whether you're a student, developer, or DevOps engineer, understanding Git deeply can elevate your productivity and collaboration skills.

Installing Git

• For Linux:

  Updates the package list and installs Git on your Linux system.

  sudo apt update

  sudo apt install git

• For macOS:

  Installs Git using the Homebrew package manager.

  brew install git

• For Windows:

• Provides a graphical interface for installing Git on Windows.

• Download the installer from git-scm.com.

• Follow the installation wizard with default options.

Basic Git Configuration

Sets your name and email globally so Git can associate them with your commits.

git config --global user.name "Your Name"

git config --global user.email "yourname@gmail.com"

Displays all your Git configuration settings.

git config --list

Initializing and Cloning Repositories

Creates a new Git repository in your current directory (locally in your system).

git init

Downloads the entire repository from a remote server (from GitHub website).

git clone https://github.com/user/repo.git

Basic Git Workflow

Shows the current state of your working directory and staging area.

git status

Adds changes to the staging area in preparation for committing.

git add file.txt. # Stage a specific file

git add . # Stage all changes once

Shows the differences between your working directory and the staging area. Use this to review what has changed before staging.

git diff

Shows the differences between the staged changes and the last commit. Use this to review what will be committed.

git diff --staged

Removes a file from the staging area while keeping the changes in the working directory. This allows you to modify it further or exclude it from the next commit.

git reset file.txt

Records the staged changes in the repository with a commit message.

git commit -m "Your message"

Displays a list of all previous commits.

git log

Understand and Use the Staging Area

The staging area in Git is called as the index. Use the staging area to prepare your changes before committing them.

1. Edit your files in the working directory.

2. Stage only the changes you want using:

   git add <file1.txt> This tells Git: “Include this file in the next commit.”

3. Leave unneeded changes unstaged if you're not ready to commit them and Check what’s staged vs. unstaged with:

   git status

Working with Branches

git branch

It list all your branches and * will appear next to the currently active branch.

git branch header

Creates a new branch named header.

git checkout header

Switches to the branch named header.

git checkout -b footer

It creates a new branch and immediately switches to the new branch.

git checkout main

git merge header

In order to merge two branches. First we need to be in the main branch then we need to merge the secondary branch (header) into the main branch. Otherwise things will go crazy.

Git Remotes

Links your local repository to a remote repository hosted on GitHub.

git remote add origin https://github.com/username/samplerepository.git

Uploads your changes to the main branch on the remote (GitHub).

git push origin main

Downloads and integrates changes from the main branch of the remote repository.

git pull origin main

Merge Conflicts

A merge conflict occurs when Git can’t automatically reconcile differences between two commits or branches. This typically happens when:

• Two branches modify the same line in a file.

• One branch edits a file that another deletes.

• Changes happen in overlapping lines of code in the same file.

Git needs your help to decide which change should keep and which change to delete.

Example Scenario

Suppose you and a teammate both edit app.js:

• You change line 10 to:
  console.log("Hello from main!");

• He change line 10 to:
  console.log("Hello from feature!");

When you try to merge feature branch into main branch, Git will stop and alert you of a conflict in app.js.

Git marks the conflicting area like this:

<<<<<<< HEAD console.log("Hello from main!");

=======

console.log("Hello from feature!");

>>>>>>>feature

• Everything between <<<<<<< and ======= is your version (usually from the current branch).

• Everything between ======= and >>>>>>> is from the branch you're merging.

How to Resolve It?

Manually edit the file to choose the correct code or combine both the codes:

Remove the conflict markers (<<<<<<<, =======, >>>>>>>).

Stage the resolved file using git add app.js and then commit the file.

Tips for Avoiding Conflicts

• Pull and merge frequently to stay up to date.

• Communicate with teammates when working on shared files.

• Keep your commits small and focused.

• Prefer feature branches over working directly on main.

Advanced Concepts

1. Stashing

   Scenario: If you're working on a new feature, but suddenly need to switch to another branch to fix a bug without losing your current work.

   git stash

   This command saves your uncommitted changes and reverts your working directory to match the last commit.

   Switch the branches and fix the bug then come back and reapply your stashed changes.

   git stash apply

   Run git stash list to see all stashes, and git stash pop to apply and delete in one step.

2. Reflog

   Scenario: You accidentally reset or deleted a commit and think it’s lost.

   git reflog

   Shows a history of everything your HEAD pointer has referenced including resets, rebases, checkouts, etc..,

   Output should show something like below

   f3e6a7d HEAD@{0}: reset: moving to HEAD~1

   d1f4a2c HEAD@{1}: commit: Added login feature

   Recover the lost commit using

   git checkout d1f4a2c

3. Rebase

   Scenario: You want to update your feature branch with the latest commits from main, but want a clean, linear history.

   git checkout feature

   git rebase main

How git rebase is different from git merge?

Both merge and rebase are used to integrate changes from one branch into another, but they do it in fundamentally different ways.

git merge:

When you use git merge, Git creates a new “merge commit” that combines the histories of both branches. It keeps the commit history, preserving the actual timeline of events.

git rebase:

When you git rebase, Git takes the commits from your branch and “replays” them on top of another branch, as if they happened later.

When to Use What?

Use merge when:

• Working in teams.

• You want to preserve all commit history.

• Merging feature branches into main.

Use rebase when:

• You’re working solo on a branch.

• You want to clean up history before merging.

• You want a linear log for better readability (git log).