🔄DevOps and Continuous Integration Unit 2 – Version Control Systems

What's Version Control?

• Version control is a system that records changes to a file or set of files over time
• Enables you to recall specific versions later and revert files back to a previous state
• Allows you to compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when
• Makes it easy to collaborate with others on a project by allowing multiple people to work on the same files simultaneously without overwriting each other's changes
• Acts as a backup mechanism by storing all versions of a file in a separate location (repository) which can be restored if needed
• Provides transparency into the history of a project making it easier to understand how the project has evolved and who has contributed to it
• Helps to prevent conflicts when multiple people are working on the same files by automatically merging changes when possible and flagging conflicts when they occur

Why Use Version Control?

• Version control allows you to revert selected files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when
• When you mess up or lose files, you can easily recover
• Enables collaboration with others on a project without the risk of overwriting each other's changes
• Provides a complete long-term change history of every file which can be used to understand how a project has evolved over time and who has contributed to it
• Makes it easy to experiment with new features or ideas without impacting the main project by creating branches
• Helps to prevent conflicts when multiple people are working on the same files by automatically merging changes when possible and flagging conflicts when they occur
• Acts as a backup mechanism by storing all versions of a file in a separate location (repository) which can be restored if needed

Key Concepts in Version Control

• Repository: The database that stores all the versions of the files being tracked by the version control system
• Commit: A snapshot of the changes made to the files at a particular point in time, along with a message describing the changes
  • Each commit has a unique identifier (hash) that can be used to reference it later
  • Commits are typically made after a logical chunk of work is completed
• Branch: A separate line of development that allows you to work on new features or bug fixes without impacting the main project
  • Branches can be merged back into the main project when the work is complete
• Merge: The process of integrating changes from one branch into another
  • Merging can be done automatically by the version control system if there are no conflicts
  • If there are conflicts (e.g. the same line of code was modified in both branches), they need to be resolved manually
• Push: The process of sending your local commits to a remote repository so that others can access them
• Pull: The process of fetching the latest changes from a remote repository and merging them into your local repository

Popular Version Control Systems

• Git: A distributed version control system that is widely used for software development
  • Git is known for its speed, flexibility, and strong support for non-linear development (branching and merging)
  • Many popular code hosting platforms like GitHub, GitLab, and Bitbucket are built around Git
• Subversion (SVN): A centralized version control system that was widely used before the rise of Git
  • SVN uses a client-server model where all the version history is stored on a central server
  • It has a simpler branching model compared to Git but is still used by many organizations
• Mercurial: Another distributed version control system that is similar to Git in many ways
  • Mercurial has a reputation for being easier to learn and use compared to Git
  • It has a built-in web interface for browsing repositories
• Perforce: A centralized version control system that is popular in the gaming and automotive industries
  • Perforce is known for its scalability and ability to handle large binary files (assets)
  • It has a unique branching model that is optimized for large-scale development

Basic Version Control Operations

• Initialize a new repository: Create a new repository to start tracking changes to your files
  • In Git, this is done using the

    git init

    command
• Add files to the repository: Tell the version control system which files you want to track
  • In Git, this is done using the

    git add

    command
• Commit changes: Create a new commit with the changes you've made to the files
  • In Git, this is done using the

    git commit

    command
  • You need to provide a commit message describing the changes you've made
• View the commit history: See a list of all the commits that have been made to the repository
  • In Git, this is done using the

    git log

    command
• Checkout a previous version: Go back to a previous version of the files in the repository
  • In Git, this is done using the

    git checkout

    command
  • You can checkout a specific commit by its hash or a branch by its name
• Push changes to a remote repository: Send your local commits to a remote repository so that others can access them
  • In Git, this is done using the

    git push

    command
• Pull changes from a remote repository: Fetch the latest changes from a remote repository and merge them into your local repository
  • In Git, this is done using the

    git pull

    command

Branching and Merging Strategies

• Feature branches: Create a new branch for each new feature or bug fix you're working on
  • This allows you to work on the feature without impacting the main project
  • When the feature is complete, you can merge it back into the main branch
• Release branches: Create a new branch for each release of your project
  • This allows you to prepare the release without impacting the main development branch
  • Bug fixes can be made on the release branch and then merged back into the main branch
• Hotfix branches: Create a new branch for each critical bug fix that needs to be made to a released version of the project
  • This allows you to fix the bug without impacting the main development branch
  • The fix can then be merged back into the main branch and the release branch
• Gitflow: A branching model that defines a strict branching structure and workflow
  • The main branch is always in a releasable state
  • Development happens on a separate develop branch
  • Feature branches are created from the develop branch and merged back in when complete
  • Release branches are created from the develop branch and merged into both the main and develop branches when ready for release
• Trunk-based development: A branching model where all development happens on a single main branch (trunk)
  • Short-lived feature branches are created from the trunk and merged back in when complete
  • This model emphasizes continuous integration and delivery

Collaboration with Version Control

• Code hosting platforms: Websites that provide a centralized place to store and manage Git repositories
  • Examples include GitHub, GitLab, and Bitbucket
  • These platforms provide additional features like issue tracking, pull requests, and continuous integration/deployment
• Pull requests: A way to propose changes to a repository and request that they be merged into the main branch
  • Pull requests allow for code review and discussion before the changes are merged
  • They are a key part of the collaboration workflow on platforms like GitHub
• Code review: The process of having other developers review your code changes before they are merged into the main branch
  • Code review helps to catch bugs, improve code quality, and share knowledge among the team
  • Many code hosting platforms have built-in tools for conducting code reviews on pull requests
• Continuous integration/deployment: The practice of automatically building, testing, and deploying code changes
  • Continuous integration (CI) involves automatically building and testing code changes on every commit or pull request
  • Continuous deployment (CD) involves automatically deploying code changes to production if they pass all the tests
  • Many code hosting platforms have built-in support for CI/CD or integrate with external tools like Jenkins or Travis CI

Version Control Best Practices

• Commit often: Make small, focused commits that are easy to understand and review
  • Each commit should represent a single logical change
  • Avoid committing unfinished or broken code
• Write good commit messages: Provide a clear and concise summary of the changes in each commit
  • The first line should be a short summary of the change
  • The body of the message should provide more detail on the reasoning behind the change
  • Use imperative mood (e.g. "Add feature" instead of "Added feature")
• Use branches: Use branches to isolate work on new features or bug fixes
  • Avoid making changes directly on the main branch
  • Merge branches back into the main branch when the work is complete and has been reviewed
• Follow a consistent branching strategy: Agree on a branching strategy with your team and stick to it
  • Document the strategy in a README file or wiki
  • Use consistent naming conventions for branches (e.g. feature/, bugfix/, release/)
• Keep the main branch stable: The main branch should always be in a releasable state
  • Only merge changes into the main branch that have been thoroughly tested and reviewed
  • If a bug is discovered on the main branch, create a hotfix branch to fix it and then merge it back in
• Use pull requests: Use pull requests to propose changes and request feedback from your team
  • Don't merge your own pull requests without review
  • Respond to feedback and make changes as needed before merging
• Conduct code reviews: Review each other's code changes before merging them
  • Look for bugs, performance issues, and code style inconsistencies
  • Provide constructive feedback and suggestions for improvement
• Use a .gitignore file: Specify which files and directories should not be tracked by Git
  • This typically includes build artifacts, log files, and local configuration files
  • Use a service like gitignore.io to generate a .gitignore file for your project's language and framework