Skip to main content

Version Control

Motivation to Use a Version Control System​

  • Tracks changes to code over time, enabling collaboration and rollback.
  • Prevents loss of work due to accidental deletion or corruption.
  • Facilitates teamwork by allowing multiple developers to work on the same project without conflicts.
  • Provides a history of changes, helping in debugging and understanding project evolution.
  • Supports branching and merging, allowing parallel development efforts.

Evolution of Version Control Systems​

Version control systems have evolved through several stages:

  1. Local Version Control: Early systems stored different versions of files as separate copies, leading to inefficiencies.

local

  1. Centralized Version Control Systems (CVCS): Introduced a central repository to manage changes but had a single point of failure.
  2. Distributed Version Control Systems (DVCS): Allowed each developer to have a full repository copy, improving collaboration and redundancy.
  3. Modern Cloud-Based VCS: Services like GitHub, GitLab, and Bitbucket provide remote hosting, continuous integration, and enhanced collaboration tools.

What is a Version Control System?​

A Version Control System (VCS) is a tool that helps developers manage changes to source code over time. It keeps track of modifications, stores different versions, and allows users to revert to previous states when necessary. It is essential for collaboration, ensuring that changes made by multiple developers do not conflict.

Types of Version Control Systems​

  1. Local Version Control Systems - Simple databases that track file changes locally.
  2. Centralized Version Control Systems (CVCS) - A single server stores all versions of a project, and users check out files to work on them.
  3. Distributed Version Control Systems (DVCS) - Every developer has a full copy of the repository, enabling offline work and faster collaboration.

cvd

Centralized Version Control Systems (CVCS)​

  • Example: Subversion (SVN), Perforce.
  • Uses a central server to store all versions of a project.
  • Developers check out and commit changes to a central repository.
  • If the central server fails, history can be lost.

Distributed Version Control Systems (DVCS)​

  • Example: Git, Mercurial.
  • Each developer has a complete copy of the repository, including the full history.
  • Supports offline work and improves redundancy.
  • Encourages branching and merging for more flexible development workflows.

Git​

  • A widely used DVCS created by Linus Torvalds.
  • Designed for speed, efficiency, and scalability.
  • Uses a distributed approach to version control, allowing multiple users to work independently.
  • Supports powerful branching and merging strategies.

Basic Git Commands​

  • git init - Initializes a new Git repository.
  • git clone <repository-url> - Clones an existing repository.
  • git add <file> - Stages a file for commit.
  • git commit -m "message" - Commits staged changes with a message.
  • git status - Shows the working directory and staging area status.
  • git log - Displays commit history.
  • git branch - Lists available branches.
  • git checkout <branch> - Switches to a different branch.
  • git merge <branch> - Merges a branch into the current branch.
  • git pull - Fetches and integrates changes from a remote repository.
  • git push - Pushes local commits to a remote repository.

Git vs. GitHub​

  • Git: A distributed version control system that manages source code history.
  • GitHub: A cloud-based platform that provides Git repository hosting with collaboration features like pull requests, issue tracking, and CI/CD integration.

Other Remote Repository Hosting Services​

  • GitLab - Provides CI/CD pipelines and DevOps features.
  • Bitbucket - Supports Git and Mercurial, integrated with Jira.
  • Azure DevOps - Microsoft's cloud-based DevOps solution with Git support.
  • SourceForge - Older platform for open-source project hosting.

Best Practices When Working with Git​

  • Use meaningful commit messages - Clearly describe what changes were made.
  • Commit frequently - Small, incremental commits make it easier to track changes.
  • Use branches - Work on features in separate branches and merge them when ready.
  • Pull before pushing - Avoid conflicts by syncing with the remote repository before pushing.
  • Avoid committing sensitive information - Never commit credentials or API keys.
  • Use .gitignore - Exclude unnecessary files from version control.
  • Review changes before committing - Use git diff to inspect modifications.
  • Rebase responsibly - When updating feature branches, prefer rebasing over merging to keep history clean.
  • Tag releases - Use tags to mark important versions of the codebase.

By following these principles, teams can ensure efficient collaboration and maintain a clean, manageable codebase.

Disclaimer: Generative AI was used in part to generate these lecture notes.