10.1 Version control (Git)

Version control is a crucial tool for developers, enabling collaboration and tracking changes over time. Git, a popular distributed version control system, offers powerful features like branching and merging, allowing teams to work on separate tasks simultaneously.

Git's workflow involves a working directory, staging area, and repository. Developers stage changes, commit them to create snapshots, and can push or pull from remote repositories. Best practices include frequent commits, descriptive messages, and regular syncing with remote branches.

Benefits of version control

• Version control systems (VCS) enable multiple developers to collaborate on the same codebase simultaneously, facilitating teamwork and parallel development
• VCS track changes made to files over time, creating a detailed history of modifications that can be reviewed, analyzed, and reverted if necessary
• In case of errors or undesired changes, version control allows developers to revert files or the entire project back to a previous state, providing a safety net and the ability to experiment without risk

Collaboration with others

• Version control systems provide a centralized repository where multiple developers can share and integrate their code changes
• Developers can work on separate branches, isolating their changes until they are ready to merge them into the main codebase
• VCS facilitate code reviews, allowing team members to examine and provide feedback on each other's changes before merging them

Tracking changes over time

• Version control systems maintain a complete history of all modifications made to files, including who made the changes, when they were made, and what specific changes were introduced
• This detailed change tracking enables developers to understand the evolution of the codebase, identify when and where bugs were introduced, and attribute changes to specific individuals
• VCS provide tools for comparing different versions of files, highlighting the differences between them, and making it easier to review and understand the changes

Reverting to previous versions

• In case of introducing bugs, making unintended changes, or discovering issues, version control allows developers to easily revert files or the entire project back to a previous stable state
• Reverting changes helps in troubleshooting and ensures that the codebase remains in a functional and reliable condition
• Version control systems provide mechanisms to selectively revert specific changes or files without affecting the entire project, giving developers fine-grained control over the reversal process

Git as version control system

• Git is a distributed version control system that has gained widespread popularity among developers and organizations
• As a distributed system, Git allows each developer to have a complete local copy of the repository, enabling offline work and reducing dependence on a central server
• Git focuses on speed, efficiency, and the ability to handle large projects with numerous contributors

Distributed version control

• In a distributed version control system like Git, each developer has a full copy of the repository, including the entire history of changes
• This distributed nature allows developers to work independently, making changes and committing them locally without the need for constant network connectivity
• Distributed version control enables collaboration across different locations and facilitates working with remote teams seamlessly

Snapshots vs differences

• Git treats data as a series of snapshots rather than storing differences between versions
• Each time a commit is made, Git takes a snapshot of the entire project at that point in time, capturing the complete state of all files
• By storing snapshots, Git can quickly and efficiently retrieve any version of the project without the need to calculate differences between versions

Speed and efficiency

• Git is designed to be fast and efficient, even for large-scale projects with extensive histories
• Git's architecture and data model allow for quick operations, such as branching, merging, and retrieving version history
• By storing data locally and using efficient algorithms, Git minimizes the need for network communication, enabling developers to work smoothly even with limited bandwidth or offline

Git repositories

• A Git repository is a data structure that stores all the files, directories, and version history of a project
• Repositories can be created locally on a developer's machine or hosted remotely on a server or a platform like GitHub or GitLab

Initializing new repositories

• To start version controlling a project with Git, a new repository needs to be initialized
• The git init command is used to create a new Git repository in the current directory
• Initializing a repository creates a hidden .git directory that contains all the necessary metadata and configuration for version control

Cloning existing repositories

• Instead of initializing a new repository, developers can clone an existing repository to obtain a local copy of the project
• The git clone command is used to create a copy of a remote repository on the local machine
• Cloning a repository downloads all the files, commits, and branches from the remote repository, allowing developers to start working with the project immediately

Local vs remote repositories

• Git distinguishes between local and remote repositories
• A local repository resides on the developer's machine and is where changes are made and committed locally
• A remote repository is hosted on a server or a platform like GitHub and serves as a central point for collaboration and sharing code
• Developers push their local changes to the remote repository to make them available to others and pull changes made by other developers from the remote repository to keep their local copy up to date

Git workflow

• The Git workflow involves three main areas: the working directory, the staging area, and the repository
• The working directory is where developers make changes to files and create new ones
• The staging area, also known as the index, is an intermediate area where changes are prepared before committing them to the repository
• The repository is the final destination where committed changes are permanently stored

Working directory, staging area, repository

• When a developer makes changes to files in the working directory, those changes are initially untracked by Git
• To include changes in the next commit, the developer needs to stage the modified files using the git add command, moving them from the working directory to the staging area
• Once the desired changes are staged, the developer can create a new commit using the git commit command, which permanently stores the changes in the repository

Git status command

• The git status command is used to check the current state of the working directory and the staging area
• It provides information about which files have been modified, which files are staged, and which files are untracked
• The output of git status helps developers understand the current state of their repository and guides them on the next steps, such as staging changes or committing them

Ignoring files with .gitignore

• In some cases, developers may want to exclude certain files or directories from version control, such as build artifacts, temporary files, or sensitive information
• The .gitignore file allows developers to specify patterns or file names that should be ignored by Git
• By adding entries to the .gitignore file, developers can prevent unwanted files from being tracked or committed accidentally

Staging and committing changes

• Staging and committing changes are fundamental operations in the Git workflow
• Staging allows developers to selectively choose which changes they want to include in the next commit
• Committing creates a new snapshot of the project, permanently recording the staged changes in the repository

Git add command

• The git add command is used to stage changes, moving them from the working directory to the staging area
• Developers can stage individual files, multiple files, or even entire directories
• The git add command takes a file path as an argument, specifying which files to stage (e.g., git add file.txt or git add directory/)

Git commit command

• The git commit command is used to create a new commit, permanently storing the staged changes in the repository
• When executing git commit, Git prompts the developer to provide a commit message describing the changes made in that commit
• The commit message should be concise yet informative, summarizing the purpose and scope of the changes

Writing informative commit messages

• Writing clear and informative commit messages is crucial for maintaining a readable and understandable project history
• A good commit message should briefly describe what changes were made, why they were made, and any relevant context
• It is recommended to use the imperative mood in commit messages, as if giving a command or instruction (e.g., "Fix bug in login functionality" instead of "Fixed bug in login functionality")
• Commit messages should be concise, typically limited to 50 characters for the subject line, and provide additional details in the body if necessary

Branching in Git

• Branching is a powerful feature in Git that allows developers to create separate lines of development within a repository
• Branches enable developers to work on different features, bug fixes, or experiments independently without affecting the main codebase
• Git branches are lightweight and fast, making it easy to create, switch between, and merge branches

Purpose of branches

• Branches serve several purposes in Git:
  • Isolating new features or changes until they are ready to be merged into the main codebase
  • Enabling parallel development, where multiple developers can work on different tasks simultaneously
  • Providing a safe environment for experimentation and testing without impacting the stable version of the project
  • Facilitating collaboration and code reviews by separating changes into manageable units

Creating and switching branches

• To create a new branch, the git branch command is used followed by the desired branch name (e.g., git branch new-feature)
• To switch to a different branch, the git checkout command is used followed by the branch name (e.g., git checkout new-feature)
• The git checkout -b command combines branch creation and switching into a single step (e.g., git checkout -b new-feature)

Merging branches

• Once the work on a branch is complete and tested, it can be merged back into the main branch (usually named "master" or "main")
• The git merge command is used to integrate the changes from one branch into another
• When merging, Git automatically attempts to combine the changes from both branches, creating a new commit that represents the merge

Resolving merge conflicts

• In some cases, when merging branches, conflicts may arise if the same lines of code have been modified in both branches
• Merge conflicts occur when Git cannot automatically resolve the differences between the branches
• When a merge conflict happens, Git marks the conflicting lines in the affected files and prompts the developer to manually resolve the conflicts
• Developers need to review the conflicting files, make the necessary changes, and then stage and commit the resolved files to complete the merge

Remote repositories

• Remote repositories are hosted on servers or platforms like GitHub, GitLab, or Bitbucket
• They serve as a central location for storing and sharing the codebase among team members
• Remote repositories facilitate collaboration, backup, and deployment of the project

Adding remote repositories

• To connect a local repository to a remote repository, the git remote add command is used followed by a name for the remote (usually "origin") and the URL of the remote repository
• For example, git remote add origin https://github.com/username/repository.git adds a remote named "origin" pointing to the specified GitHub repository

Pushing changes to remote

• After committing changes locally, developers can push those changes to the remote repository using the git push command
• The git push command sends the local commits to the remote repository, making them available to other team members
• For example, git push origin master pushes the local "master" branch to the "origin" remote repository

Pulling changes from remote

• To retrieve the latest changes made by other team members from the remote repository, the git pull command is used
• The git pull command fetches the changes from the remote repository and automatically merges them into the current local branch
• For example, git pull origin master pulls the changes from the "master" branch of the "origin" remote repository and merges them into the current local branch

Collaboration with remote repositories

• Remote repositories enable seamless collaboration among team members
• Developers can push their local changes to the remote repository, making them accessible to others
• Other team members can pull those changes from the remote repository, integrating them into their local repositories
• Remote repositories also facilitate code reviews, issue tracking, and project management through platforms like GitHub or GitLab

Git best practices

• Following best practices when using Git helps maintain a clean and organized repository, improves collaboration, and reduces the likelihood of conflicts and errors

Commit early and often

• It is recommended to make small, frequent commits rather than waiting until a large amount of work is completed
• Committing early and often allows for better tracking of progress, easier identification of issues, and more granular reversion if needed
• Regular commits also make it easier to understand the history of changes and collaborate with others

Use descriptive commit messages

• Writing clear and descriptive commit messages is crucial for maintaining a readable and understandable project history
• Commit messages should concisely summarize the changes made in each commit
• Well-written commit messages help other developers (and future self) understand the purpose and context of the changes

Avoid committing large files

• Git is designed to handle text-based files efficiently, but large binary files (such as images, videos, or compiled binaries) can cause performance issues and bloat the repository
• It is recommended to avoid committing large files directly to the repository
• Alternative solutions like Git Large File Storage (LFS) or using separate storage systems can be used to handle large files

Regularly pull from remote

• Before starting work on a new feature or making changes, it is important to pull the latest changes from the remote repository
• Regularly pulling from the remote ensures that the local repository is up to date and reduces the chances of conflicts when pushing changes later
• It is a good practice to pull changes frequently, especially when collaborating with others on the same codebase

Advanced Git features

• Git provides several advanced features that can enhance productivity and streamline the development workflow

Git stash for temporary changes

• The git stash command allows developers to temporarily save changes that are not ready to be committed
• Stashing is useful when switching between branches or when needing to quickly switch context without committing incomplete work
• Stashed changes can be later retrieved and applied using the git stash apply command

Git rebase for linear history

• Git rebase is an alternative to merging for integrating changes from one branch into another
• Rebasing allows developers to maintain a linear history by replaying the commits of one branch onto another
• Rebasing can help keep the commit history clean and easier to understand, especially in long-running branches

Git tags for marking versions

• Git tags are used to mark specific points in the repository history, typically for releasing versions of the software
• Tags provide a way to give meaningful names to important commits, such as release versions (e.g., "v1.0.0")
• The git tag command is used to create, list, and manage tags in the repository

Git submodules for nested repositories

• Git submodules allow developers to include one Git repository within another as a nested repository
• Submodules are useful when a project depends on external libraries or when managing multiple related repositories together
• Submodules maintain their own separate Git history and can be updated independently of the parent repository