Limitations of Version control

Before Git, developers relied on centralized version control system. It had limitations like single points of failure and restricted offline work. Developers cannot have their own copy of the repository and hence, cannot work offline independently.

Single Point of Failure: If the central server crashes, all version history and collaboration are lost unless backups exist.
Requires Constant Connectivity: Developers must be connected to the central server to commit changes or access previous versions.
Limited Offline Work: Unlike DVCS, developers cannot work independently without access to the central repository.
Slower Performance: Every operation requires communication with the central server, which can slow down workflows.
Risk of Data Loss: If the central repository is corrupted or compromised, all data could be lost unless proper backups are maintained.

These drawbacks led to the rise of Git, which offers a distributed approach for better flexibility and resilience. Git was created to address the challenges of managing code efficiently, especially in large-scale projects with multiple contributors.

What was the need of git?

Distributed Version Control: Unlike older systems, Git allows every developer to have a full copy of the repository, enabling offline work and reducing dependency on a central server.
Efficient Collaboration: Developers can work on different features simultaneously using branches, then merge their changes without disrupting the main codebase.
Tracking Changes: Git maintains a detailed history of modifications, making it easy to revert to previous versions if needed.
Performance & Speed: Git is optimized for handling large projects efficiently, ensuring quick operations even with extensive codebases.
Security & Integrity: Every change is securely stored using cryptographic hashing, preventing accidental or malicious alterations.

What is git?

Git is a distributed version control system that helps developers track changes in their code, collaborate efficiently and manage different versions of a project. Git was initially developed by Linus Torvalds in 2005 for managing the Linux kernel, but its advantages quickly made it the industry standard for version control.

Here is why it is widely used:

Version Control: It keeps a history of all changes, allowing developers to revert to previous versions if needed.
Branching & Merging: Developers can create separate branches to work on new features or fixes, then merge them back into the main project.
Collaboration: Git enables multiple developers to work on the same project without overwriting each other’s changes.
Performance: It is fast and efficient, even for large projects.

Meaning of distributed

In Git, distributed means that every developer has a complete copy of the repository, including its entire history, on their local machine. Unlike centralized version control systems, where a single server holds the main repository, Git allows developers to work independently without needing constant access to a central server.

Git vs Github?

Git is the engine, while GitHub is the garage where teams collaborate.

Git is a distributed version control system that helps developers track changes in their code, collaborate efficiently, and manage different versions of a project. It runs locally on a developer’s machine and allows offline work
GitHub is a web-based platform that hosts Git repositories, providing additional collaboration tools like pull requests, issue tracking, and project management.

Key Differences:

Feature	Git	GitHub
Type	Software	Hosting Service
Function	Version control	Repository management
Installation	Local	Cloud-based
Collaboration	Command-line based	Web inteface with additional tools
Ownership	Open-source (Linux foundation)	Owned by Microsoft

Alternatives:

GitLab: A complete DevOps platform with built-in CI/CD and issue tracking.
Bitbucket: Ideal for teams using Atlassian tools like Jira and Trello.
SourceForge: Supports multiple version control systems, including Git and SVN.
Gitea: A lightweight, self-hosted Git service.
Beanstalk: Offers version control with built-in code review and deployment tools.

Git Lifecycle

Stash

git stash = Stash current changes.
git stash list = View stashed changes.
git stash pop = Apply and remove the latest stash.
git stash apply = Apply the latest stash without removing it.
git stash drop = Delete a specific stash.

A temporary locker — Temporarily save changes which we’re not ready to commit.

Workspace or
Working Directory

git status = Show changes in the working directory and staging area.
git diff = View unstaged changes.
git checkout --<_filename_> = Discard changes in a file.
git clean -fd = Remove untracked files and directories.

This is where we create or modify files. Changes here are not yet tracked by Git.

Index or
Staging Area

git status = Show changes in the working directory and staging area.
git add <_filenme_> = Stage a file
git add . = Stage all changes
git reset <_filename_> = Unstage a file
git diff --cached = View staged changes

Where we prepare changes before committing.

Local Repository

git commit -m "commit_message" = Commit staged changes
git log = View commit history
git reset --soft Head^ Undo last commit, keep changes staged.
git reset --hard Head Reset to last commit, discard all changes

Where committed changes are stored locally.

Upstream or
Remote Repository

git remote -v = Show remote URLs
git fetch = Get changes from remote without merging
git pull = Fetch and merge changes from remote
git push = Push local commits to remote
git clone <_url_> = Clone a remote repository

Shared repository for collaboration (e.g., GitHub).

Explanation:

Stash: Temporarily save changes when we’re not ready to commit. It’s especially handy when we’re in the middle of something, but need to quickly switch tasks or branches without losing the current work.

Example:

Scenario: We're working on a new feature, but suddenly need to fix a bug on the main branch. Want to stash your current work, switch branches, fix the bug, and then return to the feature.

Start from feature branch (current work). We're now in our workspace, editing files like login.js and style.css.
```
git checkout -b feature/login-form
```
Make some changes. Modified both files but haven’t committed anything yet. Shows modified files in the workspace.
```
git status
```
Stage one file. Now login.js is in the staging area, while style.css is still in the workspace.
```
git add login.js
```
Stash both stages and unstaged changes. This saves our progress (both staged and unstaged) and resets the working directory to match the last commit.
```
git stash push -m "WIP: login form"
```

Switch to main and fix the bug. This commit is now in our local repository.

git checkout main
# Fix the bug in app.js
git add app.js
git commit -m "Fix: crash on login redirect"

Push the fix to remote. Now our fix is in the remote repository (e.g., GitHub)
```
git push origin main
```
Return to the feature branch
```
git checkout feature/login-form
```
Reapply the stashed changes. Our changes to login.js and style.css are restored to the workspace and staging area as they were.
```
git stash pop
```

Summary:

Git Area	What happened
Workspace	Edited files like login.js and style.css.
Staging Area	Staged login.js before stashing.
Stash	Saved both staged and unstaged changes temporarily.
Local Repository	Committed the bug fix to the local repo.
Remote Repository	Pushed the fix to GitHub (or another remote).

Download and Installation

Go to Git Downloads.
Based on your operating system, select the platform (macOS/Windows/Linux).
However, based on your operating system, it will show the platform recommendation with the latest release.
Now you can download and install it as per your operating system/platform.

Configuration

Step1: Generating SSH key pair

Open a terminal (Git Bash on Windows, Terminal on macOS/Linux).
Run the following command to generate a new RSA key pair:
```
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
```
Replace "your_email@example.com" with your GitHub email.
When prompted, press Enter to accept the default file location (~/.ssh/id_rsa).
Optionally, enter a passphrase for added security.

Step2: Add the SSH Key to the SSH Agent

Start the SSH agent:
```
eval "$(ssh-agent -s)"
```
Add your private key to the SSH agent:
```
ssh-add ~/.ssh/id_rsa
```

Step3: Add the SSH Key to GitHub

Copy the public key:
```
cat ~/.ssh/id_rsa.pub
```
Log in to GitHub and go to Settings → SSH and GPG keys.
Click New SSH Key, paste the copied key, and save.

Step4: Test the connection

Run:

ssh -T git@github.com

If successful, will see a message like:

Hi username! You've successfully authenticated, but GitHub does not provide shell access.

First Configurations

Purpose	Commands
Set Identity Git requires a username and email for commits.	`git config --global user.name "Your Name" git config --global user.email "your_email@example.com"`
Configure Default Branch Name By default, Git initializes repositories with the master branch. Can change it to main:	`git config --global init.defaultBranch main`
Configure Line Endings (Windows/Linux Compatibility)	If on Windows, set up automatic line ending conversion: `git config --global core.autocrlf true` For macOS/Linux: `git config --global core.autocrlf input`
Set Default Editor Choose preferred text editor for Git commit messages.	`git config --global core.editor "code --wait" # VS Code git config --global core.editor "vim" # Vim git config --globalcore.editor "nano" # Nano`
Enable Credential Caching To avoid entering credentials repeatedly.	`git config --global credential.helper cache`
View All Configurations To check current Git settings	`git config --list --show-origin`

Use Cases

Connecting with Remote-repository

Here we're assuming that you already have a repository on github and you're ready with the url.

Step1:Cloning the repository

In your pc/laptop go to the folder where you want to clone the repository(download all files from github).
Open the cmd/terminal at the location
Run the below command. Replace your-organization/repository-name with the actual GitHub repository URL.
```
git clone https://github.com/your-organization/repository-name.git
```

Step2: Navigate to the Repository

Move into the cloned repository:

cd repository-name

Step3: Set Up the Remote

Ensure the remote is correctly set:

git remote -v

If needed, add the remote:

git remote add origin https://github.com/your-organization/repository-name.git

Step4: Pull Updates Regularly

To keep local repository updated with the latest changes. Replace main with the default branch name if it's different

git pull origin main

Step5: Handle Merge Conflict

If there are conflicts, resolve them manually, then commit the changes

git add .
git commit -m "Resolved merge conflicts"
git push origin main

Synchronizing local to Remote-repository

Synchronization is very much required when working in a collaborative environment. It ensures that your local changes are up-to-date with the remote repository and that the contributions are integrated with the work of others.

Step1: Check the Status

Before pushing, let's check which files have been modified.

git status

Step2: Add Changes to Staging

Stage all modified files.

git add .

Or, to add specific files

git add filename

Step3: Commit the Changes

Commit the changes with a meaningful message.

git commit -m "Updated files with latest changes"

Step4: Pull Latest Changes from Remote

Ensure that the local branch is up to date before pushing. Replace main with the branch name if different

git pull origin main --rebase

Step5: Push Changes to Remote

Push the updates to the remote repository.

git push origin main

Step6: Verify the Push

Check if the changes are successfully pushed

git log --oneline -n 5

Git

History & Basics

History

What is version control?

Table of Contents

Git References