Modern Version Control_

Core Idea

Unlike older Centralized VCS (like SVN or CVS) where developers checked out files from a single central server, DVCS provides each user with a complete, independent copy (clone) of the entire repository history.

Key Advantages

• Offline Work: Commit, branch, view history, and merge without needing a network connection.
• Performance: Most operations (commit, branch, merge, diff) are local and thus significantly faster.
• Redundancy: Every clone is effectively a full backup of the repository.
• Workflow Flexibility: Enables complex branching strategies and collaboration models (e.g., pull requests).
• Collaboration: Easily share changes between any two repositories, not just client-server.

Shift from Centralized

The move to DVCS addressed key limitations of CVCS, particularly around branching/merging complexity, performance bottlenecks, and reliance on network connectivity.

What it Contains

A repository stores all the files belonging to a project, plus the complete history of modifications made to those files over time. This history is typically stored as a series of commits.

Local vs. Remote

• Local Repository: The full copy residing on your own computer. This is where you do your work: edit files, commit changes, create branches.
• Remote Repository: A copy hosted on a server (e.g., GitHub, GitLab, a company server). Used for collaboration, backup, and sharing code. A common conventional name for the primary remote is origin.

Operations

You typically clone a remote repository to create your local copy, pull changes from a remote, and push your local changes to a remote. Fetch retrieves changes without merging.

Purpose

Commits are the fundamental building blocks of a project's history. They represent saved states that you can reference, revert to, or compare against.

Components

• Snapshot: Records the state of all tracked files at that moment. Git stores this efficiently, only recording changes relative to previous commits.
• Metadata: Author, committer, timestamp, and a unique identifier (a SHA-1 hash in Git).
• Parent(s): Points to the preceding commit(s). A standard commit has one parent; a merge commit has two or more.
• Commit Message: A description explaining the changes. Crucial for understanding history.

Workflow (Git)

Typically, you modify files, stage the changes you want to include (git add), and then commit them with a message (git commit).

Concept

Think of a branch as a movable pointer to a specific commit. When you create a branch, you create a new pointer. As you make commits, the pointer moves forward with your changes.

Why Use Branches?

• Isolation: Develop features, experiment, or fix bugs without destabilizing the main line.
• Parallel Development: Multiple people work on different features simultaneously.
• Organization: Keep related changes grouped (e.g., a feature/user-login branch).
• Workflow Enablement: Basis for Gitflow, GitHub Flow, etc., often involving Pull/Merge Requests.

Common Operations (Git)

Create (git branch feature-x), switch (git switch feature-x), commit, then merge back.

Goal

To integrate work done on a separate branch (e.g., a feature branch) into another (e.g., main).

How it Works

• Fast-Forward Merge: If the target branch hasn't diverged, its pointer simply moves forward to the source's latest commit. Linear history.
• Three-Way Merge (Merge Commit): If both diverged, the VCS finds a common ancestor and combines changes since then, creating a new merge commit with two parents.

Merge Conflicts

Occur when both branches modified the same part of the same file differently. The VCS can't auto-decide, requiring manual resolution before completing the merge.

Alternatives

Rebasing (git rebase) rewrites one branch's history on top of another for a linear result — but avoid it on already-shared branches.

Common Strategies

• Gitflow: Dedicated main, develop, feature/*, release/*, hotfix/* branches. Good for scheduled releases; can be complex.
• GitHub Flow: main always deployable; feature branches merge via PR and deploy immediately.
• GitLab Flow: Adds environment/release branches, bridging continuous deployment and versioned releases.
• Trunk-Based Development: Very short-lived branches or direct commits to main; relies on feature flags, automated testing, robust CI/CD.

The best strategy depends on team size, release cadence, deployment practices, and discipline.

Process Overview

1. Create a feature branch, commit locally, push to the remote.
2. Open a PR (GitHub/Bitbucket/Azure) or MR (GitLab) targeting the integration branch.
3. Reviewers examine the diff, comment, request changes.
4. CI/CD checks (builds, tests, linters, scans) report status to the PR/MR.
5. Discussion + updates continue until approved and green.
6. An authorized user merges into the target branch, closing the PR/MR.

Benefits

• Code Quality: Peer review catches bugs, enforces standards.
• Knowledge Sharing: Team learns context across the project.
• Gatekeeping: Ensures changes pass checks before critical branches.
• Discussion Record: Durable history of decisions.

Continuous Integration (CI)

Frequently merge working copies to a shared mainline; each merge triggers an automated build + tests.

• Trigger: On push, or on PR/MR updates to key branches.
• Goal: Detect integration/build/test failures early.
• Benefit: Fast feedback; less "merge hell."

Continuous Delivery / Deployment (CD)

• Delivery: Auto build/test/prepare; final production deploy needs manual approval.
• Deployment: Every validated change auto-deploys to production — requires high test confidence.
• Trigger: After CI succeeds on specific branches or on tag creation.

Role of VCS & Platforms

VCS events act as pipeline triggers. Platforms provide integrated CI/CD (Actions, GitLab CI, Pipelines) or integrate with Jenkins/CircleCI. Pipeline definitions live as YAML in the repo.