KONGU ENGINEERING COLLEGE, PERUNDURAI 638 060

TWO CREDIT MODEL EXAMINATION

(Regulations 2022)

Month and Year : DECEMBER 2023 Roll Number:

Programme : B.E/B.TECH Date :19.12.2023
Branch : CSD, AIDS, AIML, CHEMICAL, Time : 4.30 P.M TO 6.00 P.M
ECE,EIE, MECHNAICAL
Semester : 3
Course Code : 22VC007 Duration : 1 Hour 30 Minutes
Course Name : Git and GitHub for Version Control Max. Marks : 50

PART - A (10 × 2 = 20 Marks)

ANSWER ALL THE QUESTIONS

1. Which Git command changes where the HEAD pointer points and modifies the [CO1 [K
contents of the working directory? ] 1]

The `git checkout` command in Git is used to switch branches or restore files in the
working directory. It also changes where the HEAD pointer points depending on how
it's used:

1. **Switching Branches:** When you use `git checkout` followed by a branch name, it
switches the HEAD pointer to that branch, updating the contents of the working
directory to reflect the state of that branch.

Example:

```bash

git checkout main

```

This command switches to the `main` branch, updating the working directory to
match the state of the `main` branch.

2. **Checking Out Files:** You can also use `git checkout` to restore individual files or
directories to their state at a specific commit or branch.
 Example:

```bash

git checkout HEAD -- <file_name>

```

This command restores the `<file_name>` to the state it has in the latest commit
(`HEAD`), modifying the contents of the working directory for that specific file.

It's important to note that in Git, the `HEAD` pointer usually refers to the currently
active branch or commit, and `git checkout` helps to manipulate what the `HEAD`
points to, thus affecting the working directory contents accordingly.

2. Distinguish between git and GitHub. [CO1 [K

] 2]
Git and GitHub are related but serve different purposes:

**Git:**

Git is a distributed version control system. It's a tool that allows developers to manage
and track changes to their codebase. Key points about Git include:

1. **Version Control:** Git tracks changes to files over time, allowing users to revert to
specific versions, compare changes, and collaborate on projects efficiently.
2. **Distributed:** Every Git directory on a user's computer is a full-fledged repository
with complete history and version-tracking capabilities, independent of network access
or a central server.
3. **Command-Line Tool:** Git is primarily a command-line tool, although there are
also graphical user interface (GUI) clients available.
4. **Local Operations:** Most operations in Git are local, meaning they don't require a
network connection. This allows for faster branching, committing, merging, and more.

**GitHub:**

GitHub is a web-based hosting service for Git repositories. It provides a platform for
collaboration, sharing, and hosting Git repositories. Key points about GitHub include:

1. **Hosting Service:** GitHub hosts Git repositories remotely on its servers, making
it easy for developers to collaborate with others by pushing and pulling changes to and
from these repositories.
2. **Social Collaboration:** GitHub offers features for issue tracking, pull requests,
2
 code review, and project management. It facilitates collaboration among teams or
communities working on software projects.
3. **Web Interface:** While Git is primarily command-line-based, GitHub provides a
web interface that allows users to navigate repositories, view code, manage issues,
perform pull requests, and more.
4. **Additional Features:** GitHub offers various features beyond basic version
control, including wikis, actions (for CI/CD workflows), insights (such as analytics and
project management tools), and integrations with other services.

In summary, Git is a version control system, whereas GitHub is a platform built

around Git that offers hosting services for repositories, collaboration tools, and a web
interface to manage projects and code hosted on its platform. While Git can be used
without GitHub, GitHub leverages Git's capabilities and extends them with additional
features for collaboration and project management.

3. Recall the three different modes of reset command. [CO2 [K

] 1]
The `git reset` command is a powerful tool in Git used to reset the current state of the
repository to a specific point. It has three primary modes: soft, mixed, and hard. These
modes determine which elements of the commit history and working directory will be
affected by the reset operation.

1. **Soft Reset (`--soft`):**

- This mode moves the HEAD pointer to a specific commit without changing the
staging index or working directory.
- Changes from the commits between the current state and the reset commit will
remain staged but not committed.
- It's often used when you want to undo a commit but keep the changes ready to be
committed again or moved to a different branch.

Example:
```bash
git reset --soft HEAD~1
```
This command resets the HEAD pointer to the commit before the current HEAD,
keeping the changes staged.

2. **Mixed Reset (`--mixed`):**

- This mode is the default behavior if no mode is specified. It moves the HEAD
pointer to a specific commit and resets the staging index (i.e., the changes are
unstaged).
- The working directory remains unchanged, keeping the changes made in the
commit that is being reset.
- It's useful when you want to unstage changes but keep them in the working
directory to review before committing again.

Example:
```bash
git reset HEAD~1
```
This command resets the HEAD pointer to the commit before the current HEAD,

3
 unstaging the changes.

3. **Hard Reset (`--hard`):**

- This mode moves the HEAD pointer to a specific commit, resets the staging index,
and reverts the working directory to match the state of the commit being reset to.
- It removes all changes made after the reset commit in both the staging index and
the working directory.
- **Caution:** This mode can result in the loss of uncommitted changes in the
working directory, so it should be used carefully.

Example:
```bash
git reset --hard HEAD~1
```
This command resets the HEAD pointer to the commit before the current HEAD,
discarding all changes made after that commit.

Remember, while these `git reset` modes are powerful for managing commit history,
caution is necessary, especially with `--hard` resets, as they can discard changes
irreversibly. Always ensure you're resetting to the correct commit to avoid losing
valuable work.

4. State the significance of git log. [CO2 [K

] 1]
`git log` is a command used in Git to display a chronological history of commits in a
repository. Its significance lies in several key aspects that aid developers in understanding
the history and evolution of the codebase:

1. **Commit History:** It shows a chronological list of commits made in the repository.

Each commit includes details such as the commit hash, author, date, commit message, and
possibly other information depending on the log options used.

2. **Visualizing Commits:** `git log` provides a visual representation of the commit

history. It shows a commit graph (by default) displaying branching and merging, making it
easier to understand the branching structure and relationships between different commits
and branches.

3. **Understanding Changes:** Developers can view what changes were made in each
commit. Using flags like `-p` or `--patch` with `git log` displays the actual content changes
introduced in each commit, allowing for a detailed review of code modifications.

4. **Navigating Commit History:** It allows users to navigate through commit history

using various options such as specifying commit ranges, filtering commits by author,
excluding merges, and more. This functionality helps to focus on specific parts of the
history or find particular commits efficiently.

5. **Commit Metadata and Context:** `git log` displays metadata associated with each
commit, such as commit messages, author details, timestamps, and commit hashes. This
information provides context for understanding why changes were made and by whom.

6. **Finding Bugs or Issues:** Developers often use `git log` to trace the introduction of
4
 bugs or issues. By examining the commit history and changes, they can identify when a
bug was introduced, which commit caused it, and potentially track the changes that might
resolve it.

7. **Collaboration and Code Review:** When collaborating on projects or conducting code

reviews, `git log` helps in understanding the work done by team members, reviewing their
commits, and discussing changes made to the codebase.

Overall, `git log` is a fundamental command that provides a comprehensive view of the
history of a Git repository. It serves as a crucial tool for developers to understand the
evolution of the codebase, review changes, investigate issues, and navigate through commit
history efficiently.

5. Why does the C5 commit node point at both C3 and C4 in given Git repo? [CO3 [K
] 2]

6. Which error would you get if you try to push master-branch changes to a remote [CO3 [K
repository, and someone else pushed changes to that same branch while you were ] 2]
making your changes?

If you attempt to push changes to the master branch of a remote repository and
someone else has pushed changes to the same branch before you, you would
typically encounter a "rejected - non-fast-forward" error

7. Write the procedure for creating a remote repository with named ‘Remote 1’along with [CO4 [K
Readme.md file. ] 3]

To create a remote repository named 'Remote 1' along with a `Readme.md` file, follow
these steps:

1. **Create a New Repository on a Remote Service (e.g., GitHub, GitLab, Bitbucket):**

- Go to the website of the remote service provider (e.g., GitHub, GitLab).

- Log in to your account (if you haven't already).

5
 - Look for an option/button to create a new repository.

- Name the repository 'Remote 1'.

- Optionally, you may add a description and choose whether to make it public or
private.

- It's often possible to initialize the repository with a `Readme.md` file directly from
the web interface. You can select an option during the repository creation process to
add this file.

2. **Create a Local Git Repository and Set the Remote:**

Open your terminal or command prompt and navigate to the directory where you
want to create your local repository.

- Initialize a new local Git repository:

```bash

git init

```

- Link your local repository to the remote repository you just created (replace
`<remote_repository_URL>` with the URL provided by your remote service):

```bash

git remote add origin <remote_repository_URL>

```

3. **Create a `Readme.md` file:**

- Create a `Readme.md` file in your local repository:

```bash

echo "# Remote 1" >> Readme.md

```

6
 - Add and commit the `Readme.md` file:

```bash

git add Readme.md

git commit -m "Add Readme.md file"

```

4. **Push the Initial Commit to Remote Repository:**

- Push the `Readme.md` file to the `master` branch of the remote repository:

```bash

git push -u origin master

```

The `-u` flag sets the upstream branch, linking your local `master` branch to the
`origin/master` branch on the remote repository.

5. **Verify on Remote Service:**

Go back to the remote service website (e.g., GitHub, GitLab) and refresh the
repository page. You should see the `Readme.md` file and the initial commit reflected
in your 'Remote 1' repository.

This process creates a new remote repository named 'Remote 1', initializes a local Git
repository, adds a `Readme.md` file, and pushes it to the remote repository's `master`
branch. Adjust the steps based on the specific remote service you're using and any
variations in their interface or repository creation process.

8. Compare git fetch with git pull. [CO4 [K

`git fetch` and `git pull` are both Git commands used to update your local repository ] 2]
with changes from a remote repository. However, they work differently:

- **`git fetch`:**
- Fetches changes from the remote repository to your local repository.
- Updates your remote tracking branches (e.g., `origin/master`, `origin/main`) to

7
 reflect the state of the remote repository.
- Does not automatically merge or modify your local branches. It only brings the
changes into your local repository, allowing you to inspect and integrate them later.
- Fetching doesn't affect your working directory or local changes.

Example:
```bash
git fetch origin
```

- **`git pull`:**
- Pulls changes from a remote repository and integrates them into the current branch.
- Automatically fetches the changes (like `git fetch`) and then merges the changes into
your current branch, updating your working directory.
- It's a combination of `git fetch` followed by `git merge` or `git rebase` based on your
repository's configuration (default is `git merge`).
- Can potentially cause conflicts if there are changes both locally and remotely on the
same files/lines.

Example:
```bash
git pull origin master
```

**Key Differences:**

1. **Automatic Integration:** `git pull` automatically incorporates the fetched changes

into your current branch, while `git fetch` only downloads the changes to your local
repository, leaving it up to you to decide how to integrate them.

2. **Potential Conflicts:** `git pull` can cause conflicts if there are conflicting changes
between your local branch and the remote branch being pulled. `git fetch` doesn't
directly modify your local branch, so it avoids immediate conflicts.

3. **Control and Inspection:** `git fetch` gives you more control and time to review
changes before merging them into your working branch. It allows you to inspect the
changes fetched from the remote repository separately from your local changes.

In summary, `git fetch` is used to download changes from a remote repository to your
local repository, while `git pull` is used to download changes and automatically merge
them into your current branch. `git pull` is a more automatic and immediate way to
update your local branch with the latest changes from a remote repository but may
lead to potential conflicts that need resolution.

9. Show the steps for creating a webpage and hosting it in Github. [CO4 [K
] 3]
10. Identify the features supported by fork command. [CO4 [K
] 2]
Part – B (3 × 10 = 30 Marks)
ANSWER ANY THREE QUESTIONS
11. i) Demonstrate the three-tire architecture of git workflow with a neat sketch. (6) [CO2 [K
As a text-based AI, I can't create visual sketches directly. However, I can ] 2]
describe the three-tier architecture of a typical Git workflow:
8
 1. **Local Repository (First Tier):**
- This tier represents your local environment where you perform most of your
work.
- It includes your local Git repository, where you can create branches, make
changes, stage those changes, commit them, and manage your version control.
- All these operations occur on your local machine without needing a network
connection.

2. **Remote Repository (Second Tier):**

- This tier represents the centralized or remote repository, often hosted on a
service like GitHub, GitLab, Bitbucket, or a company's internal server.
- It mirrors your local repository and serves as a shared location for
collaboration.
- It stores the central copy of the project, allowing multiple developers to push
their changes and pull changes made by others.

3. **Developer's Workspaces (Third Tier):**

- This tier represents the workspaces of multiple developers working on the
project.
- Each developer has their local repository (first tier) on their respective
machines.
- They clone the remote repository (second tier) to their local machines to
work on the project collaboratively.
- Developers make changes in their local repositories, then push those
changes to the remote repository to share their work with others.
- They can also pull changes made by other team members to keep their local
repository up-to-date.

In essence, the three-tier architecture involves developers working on their

local repositories, syncing changes with the remote repository hosted on a
server, and collaborating with others by pushing and pulling changes between
local and remote repositories.

For a visual representation, you can draw three tiers:

1. **Top Tier:** Label it as "Remote Repository" and represent it as a central

server (e.g., GitHub, GitLab).
2. **Middle Tier:** Label it as "Developer Workspaces" and represent multiple
computers or machines, each with its local repository.
3. **Bottom Tier:** Label it as "Local Repository" and represent it as the
individual developer's local environment.

Arrows between tiers can illustrate actions like pushing changes from the local
repository to the remote repository and pulling changes from the remote
repository to the local repository.

ii) Illustrate the concept git clone with an example. (4) [CO2 [K
Certainly! The `git clone` command is used to create a copy of a remote ] 3]
repository onto your local machine. Here's an example to illustrate how `git
clone` works:

Let's say there's a remote repository hosted on GitHub containing a project you
want to work on. The repository URL is
`https://github.com/exampleuser/example-repository.git`.

9
 To clone this remote repository to your local machine, follow these steps:

1. Open your terminal or command prompt.

2. Navigate to the directory where you want to place the cloned repository. For
example:
```bash
cd /path/to/desired/location
```

3. Use the `git clone` command followed by the URL of the remote repository:
```bash
git clone https://github.com/exampleuser/example-repository.git
```

4. Press Enter to execute the command. Git will clone the entire repository from
GitHub to your local machine.

5. Once the cloning process is complete, you will have a new directory created in
your current location named `example-repository` (assuming that was the name
of the repository). This directory contains a copy of all the files and the entire
commit history of the remote repository.

6. You can navigate into this newly created directory:

```bash
cd example-repository
```

Now, you have successfully cloned the remote repository onto your local
machine. This cloned repository is linked to the original remote repository,
allowing you to fetch updates, make changes, and interact with the remote
repository by pushing your changes or pulling updates made by others.

In summary, the `git clone` command creates a copy of a remote repository,

including all branches and commit history, onto your local machine, providing
you with a local working copy of the project to collaborate on or work with
independently.

12. Create a local repository and execute the following git commands and show the
result

● Create a new local repository ‘Repo 1’ (10 [CO3 [K

) ] 3]
● Create two files named ‘f1.txt’, ‘f2.txt’

● Stage the created files one by one

● Unstage ‘f2.txt’

● Commit the changes

● Create two more files ‘f3.txt’, ‘f4.txt’

● Stage all (‘f3.txt’, ‘f4.txt’) files with single command

10
 ● Commit the changes

● Update the contents of staged file ‘f4.txt’

● Stage the updated file ‘f4.txt’

● Commit the changes

● Show the history of commits

Sure, here are the steps to execute the Git commands you provided:

1. **Create a new local repository 'Repo 1' and navigate to it:**

```bash

mkdir "Repo 1"

cd "Repo 1"

git init

```

2. **Create two files named 'f1.txt' and 'f2.txt':**

```bash

echo "File 1 content" > f1.txt

echo "File 2 content" > f2.txt

```

3. **Stage the created files one by one:**

```bash

git add f1.txt

git add f2.txt

```

11
4. **Unstage 'f2.txt':**

```bash

git reset HEAD f2.txt

```

5. **Commit the changes:**

```bash

git commit -m "Committing f1.txt and un-staging f2.txt"

```

6. **Create two more files 'f3.txt' and 'f4.txt':**

```bash

echo "File 3 content" > f3.txt

echo "File 4 content" > f4.txt

```

7. **Stage all ('f3.txt', 'f4.txt') files with a single command:**

```bash

git add .

```

8. **Commit the changes:**

```bash

git commit -m "Committing f3.txt and f4.txt"

```

12
 9. **Update the contents of staged file 'f4.txt':**

```bash

echo "Updated content for File 4" > f4.txt

```

10. **Stage the updated file 'f4.txt':**

```bash

git add f4.txt

```

11. **Commit the changes:**

```bash

git commit -m "Updating f4.txt content"

```

12. **Show the history of commits:**

```bash

git log --oneline

```

These commands will create a local repository named 'Repo 1', perform the
specified operations with different files, commit those changes at each step, and
finally display the commit history using `git log --oneline` command, showing a
concise view of the commits made in the repository.

13. i) Create a local repository ‘Repo 1’ and perform two commits then reflect the (5) [CO4 [K
changes of local repository with remote repository. ] 3]
To perform this task, you'll create a local repository named 'Repo 1', make two
ii)
commits in the local repository, and then synchronize these changes with a
remote repository. (5) [CO4 [K
] 3]
13
Here are the step-by-step commands to accomplish this:

1. **Create a new local repository 'Repo 1' and navigate to it:**

```bash
mkdir "Repo 1"
cd "Repo 1"
git init
```

2. **Create some files and make changes:**

Let's create some files and add content to them.
```bash
echo "Content for File 1" > file1.txt
echo "Content for File 2" > file2.txt
```

3. **Stage and commit the changes:**

```bash
git add .
git commit -m "Initial commit - Adding file1.txt and file2.txt"
```

4. **Make further changes and commit again:**

Let's update one of the files.
```bash
echo "Updated content for File 1" > file1.txt
```

Stage and commit the changes:

```bash
git add file1.txt
git commit -m "Second commit - Updated file1.txt"
```

5. **Reflect changes to a remote repository:**

- First, create a new empty repository on a hosting service like GitHub,
GitLab, etc.
- Get the URL of the remote repository you've just created.

6. **Link your local repository to the remote repository:**

Replace `<remote_repository_URL>` with the URL of your remote repository.
```bash
git remote add origin <remote_repository_URL>
```

7. **Push changes from local repository to remote repository:**

Push the commits from your local repository to the remote repository.
```bash
git push -u origin master
14
 ```
The `-u` flag sets the upstream branch, linking your local `master` branch to
the `origin/master` branch on the remote repository.

This sequence of commands will create a local repository, make two commits,
and then link and push these changes to a remote repository. Ensure you have
the necessary permissions to push changes to the remote repository. Adjust the
URLs and branch names as needed for your specific remote repository setup.

Demonstrate the synchronization between local and remote repository with the
following.
● Create a new file ‘rf1.txt’ and ‘Readme.md’ in remote repo

● Clone the remote repo to local repo

● Update ‘rf1.txt’file in local repo

● Create a new file ‘1f1.txt’in local repo and commit the changes in local
repo
● Push the changes from local repo to remote repo
Certainly! Here are the steps to demonstrate synchronization between a
local and remote repository:

1. **Create new files 'rf1.txt' and 'Readme.md' in the remote repository:**

You can manually create these files in your remote repository on a

hosting service like GitHub, GitLab, etc.

2. **Clone the remote repository to the local repository:**

Open your terminal or command prompt and navigate to the directory

where you want to clone the repository.

```bash
git clone <remote_repository_URL>
```

Replace `<remote_repository_URL>` with the URL of your remote

repository.

3. **Update 'rf1.txt' file in the local repository:**

Make changes to 'rf1.txt' in your local repository.

4. **Create a new file '1f1.txt' in the local repository and commit the
changes:**

Create the file and commit the changes in your local repository.

15
 ```bash
echo "Content for 1f1.txt" > 1f1.txt
git add 1f1.txt
git commit -m "Add 1f1.txt to local repository"
```

5. **Push the changes from the local repository to the remote

repository:**

Push the committed changes from your local repository to the remote
repository.

```bash
git push origin master
```

This command pushes the changes from the local `master` branch to the
remote repository (`origin`). It will update the 'rf1.txt' file if changes were made
in the local repository and also add the new file '1f1.txt' to the remote
repository.

These steps demonstrate how changes made in the local repository

('rf1.txt' update and '1f1.txt' addition) can be pushed to the remote repository,
ensuring synchronization between both repositories. Adjust the commands and
file names according to your actual scenario and repository setup.

14. i). Draw the AFTER-execution state of the pictured repository after a Git
commit operation (make up a hash). [CO3 [K
(5) ] 3]
Before:

ii). Draw the AFTER-execution state of the pictured repository after running the
following commands.
$ git checkout master Before:
$ git merge myfix

(5) [CO3 [K
] 3]

Bloom’s Taxonomy Remembering Understanding Applying Analysing Evaluating Creating

Level (K1) (K2) (K3) (K4) (K5) (K6)
Percentage 10 33 57 - - -

16
17