Unit 5: Version Control - Subjective Questions

Version control is a system that records changes made to files over time. It allows developers to review earlier versions and restore them when necessary.

Importance of version control:

• Maintains a complete history of file changes.
• Identifies who made each change and when it was made.
• Allows earlier versions of files to be restored.
• Supports collaboration among multiple developers.
• Enables developers to work on separate features without disturbing the main project.
• Reduces the risk of permanently losing working code.

Git is a free, open-source, distributed version control system used to track changes in files and coordinate work among developers.

Main features of Git:

• Distributed operation: Every developer can have a complete copy of the repository and its history.
• Change tracking: Git records changes through commits.
• Branching: Developers can create independent lines of development.
• Merging: Changes from different branches can be combined.
• Offline work: Most Git operations can be performed without an internet connection.
• Speed and reliability: Git handles project history efficiently and protects stored data using checksums.

GitHub is an online platform that hosts Git repositories and provides tools for collaboration and project management.

Relationship between Git and GitHub:

• Git is the version control software installed on a local computer.
• GitHub is a web-based service that stores Git repositories remotely.
• Git tracks changes and creates commits locally.
• GitHub makes those commits accessible through the internet.
• Developers use commands such as git push and git pull to exchange changes with GitHub.

Git can be used without GitHub, and GitHub repositories can be managed through Git or through GitHub's web interface.

In summary, Git manages versions, while GitHub hosts and helps teams collaborate on Git repositories.

Steps to install and verify Git:

1. Visit the official Git website at https://git-scm.com/.
2. Download the installer suitable for the operating system.
3. Run the installer and select the required installation options.
4. Complete the installation process.
5. Open Terminal, Command Prompt, PowerShell, or Git Bash.
6. Run the following command:

git --version

7. If Git is installed correctly, the command displays the installed Git version, such as git version 2.x.x.

On Linux, Git can also be installed through the system package manager, for example with sudo apt install git on Debian-based systems.

After installation, a user should configure the name and email address that Git will attach to new commits.

Configuration commands:

• Set the user name: git config --global user.name "Student Name"
• Set the email address: git config --global user.email "student@example.com"
• View the saved configuration: git config --global --list

The --global option applies the settings to all repositories used by that account on the computer. Without it, the settings apply only to the current repository when configured locally.

Why configuration is necessary:

• It identifies the author of each commit.
• It creates a clear and accountable project history.
• Using the email linked to GitHub helps GitHub associate commits with the correct profile.

Creating a GitHub account and profile:

1. Open https://github.com/ and select the sign-up option.
2. Enter a valid email address, password, and unique username.
3. Complete any verification challenge and submit the registration form.
4. Verify the email address using the message sent by GitHub.
5. Sign in and open the profile settings.
6. Add appropriate profile information, such as a display name, biography, location, profile picture, and website.
7. Review email visibility and notification preferences.
8. Enable two-factor authentication to improve account security.
9. Add an SSH key or configure another authentication method if Git will communicate with GitHub from the command line.

A complete profile helps collaborators identify the account owner, while secure authentication protects repositories and personal information.

A Git repository is a project directory whose files and revision history are managed by Git.

Local repository:

• Stored on the user's computer.
• Supports operations such as staging, committing, branching, and merging.
• Can usually be used without an internet connection.
• Contains a hidden .git directory that stores Git metadata and history.

Remote repository:

• Stored on a server or hosting platform such as GitHub.
• Provides a shared location for collaboration and backup.
• Is accessed using commands such as git fetch, git pull, and git push.

A local repository and a remote repository can be connected so that changes can be exchanged between them.

Procedure for creating a local Git repository:

1. Open a terminal or command-line application.
2. Create a project directory with mkdir sample-project.
3. Enter the directory with cd sample-project.
4. Initialize the repository with git init.
5. Check its state with git status.

The git init command creates a hidden .git directory. This directory stores configuration, references, objects, and the complete version history of the repository.

After initialization, project files can be created, staged, and committed. The .git directory should not be manually edited or deleted because deleting it removes the repository's Git history and configuration.

git init and git clone both create local repositories, but they are used in different situations.

git init:

• Initializes Git inside a new or existing local directory.
• Creates an empty repository history when used for a new project.
• Does not automatically connect to a remote repository.
• Use it when starting a project locally from the beginning.

git clone:

• Downloads an existing repository from a remote location.
• Copies project files, commit history, and branches.
• Usually configures the source repository as a remote named origin.
• Use it when joining an existing GitHub project.

Example commands are git init for a local project and git clone https://github.com/user/project.git for an existing remote project.

Steps to add a new file:

1. Enter the repository directory.
2. Create a file, such as README.md, using a text editor.
3. Save meaningful content in the file.
4. Run git status to confirm that the file is shown as untracked.
5. Stage the file with git add README.md.
6. Run git status again to verify that it is ready to be committed.
7. Commit it with git commit -m "Add project README".

The git add command does not permanently record the file in the project history. It places the current version of the file in the staging area. The subsequent commit records that staged version.

Git manages changes through three main areas:

• Working directory: This contains the files currently visible and editable in the project folder. New edits first exist here.
• Staging area: This is an intermediate area containing the changes selected for the next commit. The command git add copies a snapshot of selected changes into this area.
• Repository: This contains committed snapshots and project history inside the .git directory. The command git commit records staged changes here.

Typical workflow:

Edit files → git add → git commit

This design lets a developer choose exactly which changes should be included in a commit, even when several files have been modified.

A commit is a recorded snapshot of staged changes in a Git repository. It represents a meaningful point in the project's history.

A commit contains or references:

• A snapshot of the project's tracked files.
• A unique commit identifier called a hash.
• The author's name and email address.
• The date and time of the commit.
• A commit message.
• A reference to the previous commit or commits.

A good commit message should:

• Be short and specific.
• Explain the purpose of the change.
• Use a clear action phrase, such as Add login validation.
• Avoid vague descriptions such as Update files.

Focused commits and clear messages make project history easier to understand, review, and debug.

Complete commit workflow:

1. Modify or create the required project files.
2. Run git status to inspect untracked and modified files.
3. Run git diff to review unstaged changes.
4. Stage selected files using commands such as git add file1 file2.
5. Use git diff --staged to review what will be included in the commit.
6. Run git status again to confirm the staged files.
7. Create the commit with git commit -m "Describe the change clearly".
8. Inspect recent history with git log --oneline.
9. Examine the commit in detail with git show or git show <commit-hash>.

This process ensures that only intended and reviewed changes are recorded. Staging selected files also helps keep each commit focused on one logical task.

git add:

• Selects changes from the working directory.
• Places those changes in the staging area.
• Does not create a permanent history entry.

git commit:

• Records the staged changes in the local repository.
• Creates a commit hash and associates the change with an author and message.
• Does not automatically upload anything to GitHub.

git push:

• Sends local commits to a remote repository such as GitHub.
• Updates the corresponding remote branch.
• Requires a configured remote and suitable authentication.

The usual sequence is git add, followed by git commit, and then git push. Each command affects a different stage of the workflow.

A branch is an independent line of development represented by a movable reference to a commit. It allows work to continue separately from another branch, such as main.

Advantages of branches:

• Features can be developed without changing stable code.
• Bugs can be fixed in isolated branches.
• Multiple developers can work on different tasks simultaneously.
• Experimental changes can be tested safely.
• Changes can be reviewed before they are merged.
• Branches support organized workflows on GitHub through pull requests.

Branches are lightweight in Git because Git stores references to commits instead of creating complete duplicate copies of all project files.

Common branch operations:

• List local branches with git branch.
• Create a branch with git branch profile.
• Switch to it with git switch profile.
• Create and switch in one step with git switch -c profile.
• Confirm the current branch with git branch or git status.
• Return to the main branch with git switch main.
• Delete a fully merged branch with git branch -d profile.
• Force-delete an unmerged local branch, only when its work is no longer required, with git branch -D profile.

The equivalent older command for creating and switching is git checkout -b profile. Before deleting a branch, its required work should be committed and merged or otherwise preserved.

Creating and merging a profile branch:

1. Make sure the main branch is current and clean by running git status.
2. Create and switch to the new branch with git switch -c profile.
3. Create or edit a profile file, such as PROFILE.md.
4. Check the changes using git status and git diff.
5. Stage the file with git add PROFILE.md.
6. Commit it with git commit -m "Add user profile".
7. Return to the main branch with git switch main.
8. Merge the branch using git merge profile.
9. Verify the result with git log --oneline --graph --all.
10. Delete the merged branch with git branch -d profile if it is no longer needed.

If the branch must also appear on GitHub, publish it with git push -u origin profile. After merging, push the updated main branch with git push origin main.

Connecting and publishing a repository:

1. Sign in to GitHub and create a new repository.
2. If the local repository already contains files and commits, avoid initializing the GitHub repository with conflicting files.
3. Copy the repository's HTTPS or SSH URL.
4. In the local repository, add the remote with git remote add origin <repository-url>.
5. Confirm the remote using git remote -v.
6. Ensure the main branch has the desired name with git branch -M main.
7. Publish it using git push -u origin main.
8. Authenticate when requested.

The remote name origin is conventional but not mandatory. The -u option establishes an upstream relationship, allowing later commands such as git push and git pull to work without repeatedly specifying the remote and branch.

git status:

• Shows the current branch.
• Identifies staged, modified, and untracked files.
• Indicates whether the local branch differs from its upstream branch.

git log:

• Displays commit history.
• Shows commit hashes, authors, dates, and messages.
• Can provide a compact view through git log --oneline.

git diff:

• Displays changes that have not yet been staged.
• git diff --staged displays staged changes prepared for the next commit.

git branch:

• Lists local branches and marks the current branch.
• Can create or delete branches using suitable options.

Together, these commands help a developer inspect the repository before staging, committing, merging, or publishing changes.