Version Control (also called Source Code Management) is a system that records changes to files over time so that specific versions can be recalled later.

Key Benefits:

• History Tracking: Maintains a complete history of every change, who made it, and why (via commit messages).
• Collaboration: Multiple developers can work on the same codebase simultaneously without overwriting each other's work.
• Reversibility: Enables reverting to a previous stable version if a bug is introduced.
• Branching & Experimentation: Developers can create isolated branches to test features without affecting the main code.
• Backup & Redundancy: Distributed systems like Git keep a full copy of the repository on every machine.
• Accountability: Every change is attributed to an author, improving traceability.

Without version control, teams risk losing work, creating conflicting file copies (e.g., final_v2_FINAL.doc), and struggling to coordinate changes.

Centralized Version Control System (CVCS):

• A single central server stores all versioned files.
• Clients check out files from the central server.
• Examples: CVS, Subversion (SVN), Perforce.
• Drawback: If the central server fails, no one can collaborate or save versioned changes. Single point of failure.

Distributed Version Control System (DVCS):

• Every client fully mirrors the repository, including its complete history.
• Examples: Git, Mercurial, Bazaar.
• Advantages: Works offline, every clone is a full backup, faster operations, better branching.

Conclusion: DVCS (like Git) is now the industry standard due to its resilience and flexibility.

A Git Repository is a data structure that stores metadata and object database for a project, including the complete history of all changes. It is typically stored inside a hidden .git directory.

Local Repository:

• Resides on the developer's own machine.
• Contains the working directory, staging area, and the .git database.
• Allows committing, branching, and viewing history offline.

Remote Repository:

• Hosted on a server or cloud platform (e.g., GitHub, GitLab, Bitbucket).
• Acts as a shared central point for collaboration.
• Developers push their local changes to it and pull others' changes from it.

Interaction Flow:

Local Repo --push--> Remote Repo
Local Repo <--pull-- Remote Repo

A repository is created locally using git init or by cloning a remote using git clone <url>.

Basic Git Operations:

• git init

  • Initializes a new, empty Git repository in the current directory.
  • Creates the hidden .git folder.

• git add <file>

  • Moves changes from the working directory to the staging area (index).
  • git add . stages all changes.

• git commit -m "message"

  • Records the staged changes permanently into the local repository history.
  • Each commit gets a unique SHA-1 hash.

• git push

  • Uploads local commits to a remote repository.
  • Example: git push origin main.

• git pull

  • Fetches changes from the remote and merges them into the current local branch.
  • Equivalent to git fetch + git merge.

Typical Workflow:

git init
git add .
git commit -m "Initial commit"
git push origin main

Git tracks files across three main states, corresponding to three areas:

1. Modified (Working Directory):

• The file has been changed but not yet marked for the next commit.
• Lives in the working directory.

2. Staged (Staging Area / Index):

• The modified file has been marked to go into the next commit snapshot.
• Achieved using git add.

3. Committed (Git Directory / Repository):

• The data is safely stored in the local .git database.
• Achieved using git commit.

Flow Diagram:

Working Directory --(git add)--> Staging Area --(git commit)--> Repository

Additionally, files can be:

• Untracked: New files Git is not yet tracking.
• Tracked: Files known to Git (committed or staged).

Understanding these states is crucial for controlling exactly what goes into each commit.

A commit is a snapshot of the repository at a specific point in time. It permanently records the staged changes into the project history.

Anatomy of a Commit:

• SHA-1 Hash: A unique 40-character identifier (e.g., a1b2c3d...) generated from the commit's contents.
• Author & Committer: Name and email of who made the change.
• Timestamp: Date and time of the commit.
• Commit Message: A description of what changed and why.
• Parent Commit(s): Reference to the previous commit, forming a chain (a merge commit has two parents).
• Tree: A pointer to the snapshot of the directory structure.

Role of SHA-1 Hash:

• Ensures data integrity — any change in content produces a different hash.
• Uniquely identifies each commit across the entire repository.
• Enables Git to detect corruption and link commits reliably.

Best Practices for Commit Messages:

• Use a concise summary line (<50 chars).
• Write in the imperative mood (e.g., "Fix login bug").

Branching in Git allows you to diverge from the main line of development and continue working independently without affecting the main codebase.

Importance of Branching:

• Isolation: Develop new features or fix bugs without disturbing stable code.
• Parallel Development: Multiple developers can work on different branches simultaneously.
• Experimentation: Try risky changes safely; discard the branch if it fails.
• Release Management: Maintain separate branches for production, development, and features.

Key Concept: A branch is simply a lightweight, movable pointer to a commit. The default branch is usually main or master.

Common Commands:

git branch feature-login      # Create a new branch
git checkout feature-login    # Switch to the branch
# OR (modern syntax)
git switch feature-login

git checkout -b feature-login # Create and switch in one step

git branch                    # List all branches
git branch -d feature-login   # Delete a branch

Because branches are just pointers, they are extremely fast and cheap to create in Git.

Merging is the process of combining changes from one branch into another, typically integrating a feature branch back into the main branch.

Command:

git checkout main
git merge feature-branch

1. Fast-Forward Merge:

• Occurs when the target branch has not diverged — there are no new commits on main since the feature branch was created.
• Git simply moves the main pointer forward to the feature branch's latest commit.
• No new merge commit is created.

Before: A---B---C (main, then feature adds D-E)
After: A---B---C---D---E (main)

2. Three-Way Merge:

• Occurs when both branches have diverged (new commits exist on both).

• Git uses the two branch tips and their common ancestor to create a new merge commit with two parents.

  D---E (feature)
  / \
  A---B---C---M (main)

A Merge Conflict occurs when Git is unable to automatically reconcile differences between two branches — typically when the same lines of the same file are changed differently in both branches.

When Conflicts Occur:

• Two branches edit the same line differently.
• One branch deletes a file while another modifies it.

Conflict Markers in a File:

<<<<<<< HEAD
Current branch changes

Incoming branch changes

feature-branch

Steps to Resolve:

1. Run git merge; Git reports the conflicting files.
2. Open each conflicted file and locate the markers (<<<<<<<, =======, >>>>>>>).
3. Manually edit the file to keep the desired code and remove the markers.
4. Stage the resolved file: git add <file>.
5. Complete the merge: git commit.

Helpful Commands:

• git status — shows conflicted files.
• git merge --abort — cancels the merge and returns to the pre-merge state.
• Merge tools (e.g., git mergetool) can assist visually.

Tagging in Git is used to mark specific points in the repository history as important — most commonly to indicate release versions (e.g., v1.0.0).

Two Types of Tags:

1. Lightweight Tag:

• A simple pointer to a specific commit (like a branch that doesn't move).
• Stores no extra metadata.
• Command: git tag v1.0-lw

2. Annotated Tag:

• Stored as a full object in the Git database.
• Contains extra metadata: tagger name, email, date, and a message.
• Can be verified with GPG signatures.
• Command: git tag -a v1.0 -m "Release version 1.0"

Common Tag Commands:

git tag                 # List tags
git show v1.0           # Show tag details
git push origin v1.0    # Push a tag to remote
git push origin --tags  # Push all tags

Recommendation: Use annotated tags for public releases.

Rebasing is the process of moving or replaying a series of commits from one branch onto the tip of another branch, creating a linear history.

Command:

git checkout feature
git rebase main

How it Works: Git takes the commits unique to feature, temporarily saves them, moves the branch base to the latest commit of main, and re-applies the saved commits on top.

Rebase vs. Merge:

The Golden Rule of Rebasing:

Never rebase commits that have been pushed to a shared/public branch.

Because rebasing rewrites commit history (new SHA-1 hashes), doing so on shared branches forces others' histories to diverge, causing serious collaboration problems. Rebase only local, unpublished commits.

Git Stashing temporarily shelves (or stashes) uncommitted changes in your working directory so you can switch context without committing incomplete work.

Use Cases:

• You're mid-way through a feature but need to switch branches to fix an urgent bug.
• You want to pull remote changes but have local uncommitted edits that would conflict.
• You need a clean working directory temporarily.

How it Works: Stashing saves your modified tracked files onto a stack and reverts the working directory to the last commit (HEAD).

Common Commands:

git stash                # Stash current changes
git stash save "message" # Stash with a description
git stash list           # View all stashes
git stash apply          # Reapply most recent stash (keeps it in list)
git stash pop            # Reapply and remove from stash list
git stash drop           # Delete a specific stash
git stash clear          # Delete all stashes
git stash -u             # Include untracked files

Note: Stashes are stored as a LIFO stack (stash@{0}, stash@{1}, ...).

GitHub Flow is a lightweight, branch-based workflow ideal for teams practicing continuous deployment. It keeps the main branch always deployable.

Main Steps:

1. Create a Branch: Branch off main with a descriptive name (e.g., add-search-feature).
2. Add Commits: Make changes and commit them to the branch.
3. Open a Pull Request (PR): Start a discussion about the changes with the team.
4. Review & Discuss: Team members review code, suggest changes, and run automated tests (CI).
5. Deploy (optional): Test the branch in a staging/production-like environment.
6. Merge: Once approved, merge the PR into main.

Advantages:

• Simplicity: Only one long-lived branch (main).
• Continuous Deployment friendly: main is always production-ready.
• Collaboration: PRs encourage code review and discussion.
• Fast iteration: Suited for web apps deployed frequently.

Core Principle: Anything in the main branch is deployable at any time.

Feature Branch Workflow is a Git strategy where all feature development takes place in dedicated branches instead of the main branch. This keeps main free of broken code.

Key Ideas:

• Each new feature gets its own branch (e.g., feature/login).
• Developers work in isolation on their feature branch.
• Once complete, the branch is merged into main (often via a Pull Request after review).
• The main branch always contains stable, working code.

Workflow Steps:

git checkout -b feature/payment main
# ... work and commit ...
git push origin feature/payment
# Open PR -> Review -> Merge

Comparison with GitHub Flow:

Note: GitHub Flow is essentially a streamlined form of the Feature Branch Workflow with emphasis on always-deployable main and PR-based collaboration.

GitHub Issues are a built-in tracking tool used to report bugs, request features, and manage tasks within a repository. They serve as the project's to-do list and discussion hub.

Purpose:

• Bug Tracking: Report and document defects.
• Feature Requests: Propose new functionality.
• Task Management: Track work items and to-dos.
• Collaboration: Enable discussion between contributors and maintainers.

Key Features:

• Title & Description: Markdown-supported description of the issue.
• Labels: Categorize issues (e.g., bug, enhancement, documentation).
• Assignees: Assign issues to specific team members.
• Milestones: Group issues toward a release goal.
• Comments: Threaded discussion on the issue.
• References: Link issues to commits and Pull Requests (e.g., Closes #12 auto-closes the issue when merged).
• Mentions: Tag users with @username.

Benefit: Issues create a transparent, searchable record of all reported problems and planned work.

A Pull Request (PR) is a mechanism to propose changes from one branch (or fork) and request that they be reviewed and merged into another branch (usually main).

Importance:

• Code Review: Team members inspect changes before merging.
• Quality Assurance: Automated tests (CI) run on the PR.
• Discussion: Provides a space for inline comments and feedback.
• Documentation: Records the reasoning behind changes.

Lifecycle of a Pull Request:

1. Create Branch & Push: Developer pushes a feature branch to the remote.
2. Open PR: Compare the feature branch against the base branch, describing the changes.
3. Automated Checks: CI/CD pipelines run tests and linters.
4. Review: Reviewers comment, request changes, or approve.
5. Update: Developer pushes new commits to address feedback.
6. Approval: Reviewers approve the PR.
7. Merge: PR is merged (merge commit, squash, or rebase) into the base branch.
8. Cleanup: The feature branch is deleted.

Merge Options:

• Merge commit — preserves all commits.
• Squash and merge — combines into one commit.
• Rebase and merge — linear history.

GitHub Discussions is a collaborative communication forum built into a repository, designed for open-ended conversations that are not necessarily actionable tasks.

Purpose of Discussions:

• Q&A: Community members ask and answer questions.
• Ideas & Brainstorming: Share and discuss proposals before formal work.
• Announcements: Share news with the community.
• General Conversation: Build community around a project.

Key Features:

• Categories: Organize discussions (Q&A, Ideas, General, etc.).
• Marked Answers: In Q&A, the best answer can be highlighted.
• Threaded Replies: Nested conversation structure.
• Upvotes/Reactions: Community can react to posts.

Discussions vs. Issues:

In short: Use Issues for concrete, actionable work items and Discussions for broader conversations and community engagement.

A complete remote workflow involves obtaining a copy of a repository, working locally, and synchronizing with the remote for collaboration.

Step 1: Clone the Repository

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

Downloads the full repository and sets up `origin` as the remote.

Step 2: Create a Feature Branch

git checkout -b feature/new-widget

Isolates your work from `main`.

Step 3: Make Changes and Commit

git add .
git commit -m "Add new widget component"

Step 4: Keep Branch Updated (Fetch/Pull)

git checkout main
git pull origin main       # Get latest changes
git checkout feature/new-widget
git merge main             # or git rebase main

Step 5: Push the Branch

git push -u origin feature/new-widget

Step 6: Open a Pull Request

• On GitHub, open a PR from feature/new-widget into main.
• Reviewers review, discuss, and approve.

Step 7: Merge and Clean Up

git checkout main
git pull origin main       # Get the merged changes
git branch -d feature/new-widget

Key Remote Commands Summary:

• git remote -v — list remotes.
• git fetch — download changes without merging.
• git pull — fetch + merge.
• git push — upload commits.

This workflow ensures organized, reviewed, and conflict-minimized collaboration.

Both merging and rebasing integrate changes from one branch into another, but they do so differently and produce different histories.

1. Merging

Combines two branches by creating a new merge commit that has two parents, preserving the exact branching history.

git checkout main
git merge feature

  D---E (feature)
 /     \

A---B---C---M (main) <- M is the merge commit

Advantages:

• Non-destructive: Existing commits are unchanged.
• Preserves true history of how work was done.
• Safe for shared/public branches.

Disadvantages:

• History can become cluttered with many merge commits.
• Harder to read a linear project history.

2. Rebasing

Moves the feature branch commits to begin on top of the latest main, producing a linear history.

git checkout feature
git rebase main

A---B---C (main)
\
D'---E' (feature, replayed commits)

Advantages:

• Clean, linear history — easy to follow.
• No unnecessary merge commits.

Disadvantages:

• Rewrites history (new SHA-1 hashes).
• Dangerous on shared branches (violates the Golden Rule).
• Conflicts may need resolving multiple times.

Comparison Table:

When to Use:

• Use Merge: For integrating shared/public branches and preserving history (e.g., merging PRs into main).
• Use Rebase: For cleaning up local commits before sharing, keeping a tidy history.

Golden Rule: Never rebase commits already pushed to a shared branch.

Scenario: Two developers edit the same line in config.js. Alice changes the port to 3000 on main; Bob changes it to 8080 on feature/port-update. When Bob merges main, a conflict arises.

Step 1: Attempt the Merge

git checkout feature/port-update
git merge main

Git responds:

Auto-merging config.js
CONFLICT (content): Merge conflict in config.js
Automatic merge failed; fix conflicts and then commit the result.

Step 2: Inspect the Conflict

git status

Shows `config.js` as **both modified**. Opening the file reveals conflict markers:

javascript
const config = {
<<<<<<< HEAD
  port: 8080
=======
  port: 3000
>>>>>>> main
};

Step 3: Resolve Manually

The team decides 3000 is correct. Edit the file to:

const config = {
  port: 3000
};

All conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`) are removed.

Step 4: Stage the Resolved File

git add config.js

Step 5: Complete the Merge

git commit -m "Merge main into feature/port-update, resolve port conflict"

Step 6: Verify

git log --oneline --graph

Alternative Options:

• git merge --abort — cancel and restore the pre-merge state.
• git mergetool — launch a visual merge tool.
• git checkout --ours config.js / --theirs — accept one side entirely.

Best Practices to Avoid Conflicts:

• Pull frequently to stay in sync.
• Keep branches short-lived.
• Communicate about who edits which files.