Subject Name: Source Code Management

Subject Code: 24CSE0106

Cluster: Alpha
Department: DCSE

Submitted By: Submitted To:

Name: Abhishek Sharma Dr. Srikanta Kumar Mohapatra
2410990012 Associate professor ||
G01 Department of Computer
Science & Engineering
Chitkara University Institute of
Engineering and Technology
Rajpura, Punjab
 Index Task 1.1

S. Program Title Page No.

No

To install and configure Git Client on your local system

1. 01
 Installing and configuring Git Client.
 Git lifecycle description and basic commands
Setting up GitHub Account and Adding Collaborators on GitHub
2. Repository 04
 Managing collaborators for collaborative work.

Push/Pull Using Git

3.  M To demonstrate push and pull operations in Git. 08
 Experiment 1

Aim: Setting up of Git Client

Theory:
GIT: It’s a Version Control System (VCS). It is a software e or we can say a server by which
we are able to track all the previous changes in the code. It is basically used for pushing and
pulling of code. We can use git and git-hub parallelly to work with multiple members or
individually. We can make, edit, recreate, copy or download any code on git hub using git.

Procedure:
We can install Git on Windows, using the most official build which is available for download
on the GIT’s official website or by just typing (scm git) on any search engine. We can go on
https://git-scm.com/download/win and can select the platform and bit-version to download.
And after clicking on your desired bit-version or ios it will start downloading automatically.

Snapshots of download:

Opted for “64-bit Git for Windows Setup”

Git and its files in downloads

Git Setup

Git Installation
 Git Bash launched

Git Lifecycle:
1. Untracked: New files not added to Git.
o git status: Shows untracked files.
2. Unstaged: Files modified but not yet staged.
o git add <file>: Stage changes.
3. Staged: Files prepared for commit.
o git commit -m "message": Commit changes.
4. Committed: Changes saved in the local repository.
o git log: View commit history.
5. Pushed: Changes pushed to remote.
o git push: Upload commits.
6. Pulled: Changes fetched from remote.
o git pull: Download and merge changes.

Basic Git Commands:

 git init: Initialize a new repo.
 git status: View file status.
 git add <file>: Stage a file.
 git commit -m "message": Commit changes.
 git push: Push to remote.
 git pull: Fetch from remote.
 git log: View commit history.
 Experiment 2
Aim: Setting up GitHub Account and Adding Collaborators on GitHub Repository

Theory:
GitHub: GitHub is a website and cloud-based service (client) that helps an individual or
developers to store and manage their code. We can also track as well as control changes to
our or public code.

Advantages of GitHub: GitHub has a user-friendly interface and is easy to use. We can
connect the git-hub and git but using some commands shown below in figure Without GitHub
we cannot use Git because it generally requires a host and if we are working for a project, we
need to share it will our team members, which can only be done by making a repository.
Additionally, anyone can sign up and host a public code repository for free, which makes
GitHub especially popular with open-source projects.

Procedure:
To make an account on GitHub, we search for GitHub on our browser or visit https://github.com/signup.
Then, we will enter our mail ID and create a username and password for a GitHub account.

Snapshots –

After visiting the link this type of interface will appear, if you already have an account, you can sign in
and if not, you can create.
 GitHub Login

GitHub Interface
Adding Collaborators on GitHub Repository:

1. Log in to GitHub: Make sure you're logged into your GitHub account.
2. Go to Your GitHub Dashboard: On the GitHub homepage, click the "+" icon in the
top-right corner and select "New repository".
3. Fill in Repository Details:
4. Repository Name: Choose a name for your repository.
5. Description (optional): Add a short description for your repository.
6. Public or Private: Select whether you want your repository to be public or private.
7. Initialize this repository with a README (optional): Check this option if you want
to automatically create a README file.
8. Create Repository: Once you've filled in the details, click the "Create repository"
button.

Creating new repository

9. Go to the repository: Open your GitHub repository.

10. Navigate to Settings: On the right side of the repository's top menu, click the
"Settings" tab.
11. Select Collaborators: In the left sidebar, scroll down and select "Collaborators"
under the "Access" section.
12. Add Collaborator: Click the "Add collaborator" button.
13. Search for Username: In the text field, enter the GitHub username of the person you
want to add.
14. Send Invitation: Click "Add". The person will receive an invitation to join the
repository.
15. Wait for Acceptance: Once they accept the invitation, they will have collaborator
access.
 Adding collaborators to the repository.

Assign Roles and Permissions:

 Assign appropriate permissions to collaborators: Admin (full control), Write (can push to
branches), and Read (view-only access).
2. Manage Tasks with GitHub Issues
 Create Issues: Use GitHub Issues to track tasks, bugs, or features.
 Assign Issues: Assign issues to specific collaborators.
 Use Labels: Categorize tasks with labels like bug, feature, etc.
 Set Milestones: Group issues under milestones to track progress.
3. Organize with GitHub Projects
 Create Project Boards: Set up Kanban-style boards to organize tasks visually.
 Add Issues to Projects: Link issues to the board and track task progress.
4. Branching and Pull Requests (PRs)
 Branching Strategy: Encourage feature branches and keep the main branch stable.
 Pull Requests: Collaborators submit PRs for review before merging into the main branch.
 Assign Reviewers: Assign reviewers to ensure code quality before merging.
5. Code Reviews and Feedback
 Review Process: Ensure all PRs are reviewed by collaborators before merging.
 Provide Feedback: Offer constructive feedback for improvements and ensure adherence to
coding standards.
 Experiment 3

Aim: Push/Pull Using Git: To demonstrate push and pull operations in Git.

Theory:
Git is a distributed version control system that helps manage and track changes to code over
time. It enables multiple developers to work on the same codebase without conflicts. The
push and pull commands are used to interact with remote repositories.
1. Push: The git push command is used to upload local changes (committed to the local
repository) to a remote repository (such as GitHub, GitLab, or Bitbucket). This ensures that
other collaborators can access your changes.
2. Pull: The git pull command is used to fetch the latest changes from a remote repository and
automatically merge them into your local branch. This ensures your local branch is up-to-date
with changes made by others.

Procedure:
To push changes:
1. Setting Up a Local Repository
If you're starting with an empty local repository, you will need to initialize it first. If you
already have a remote repository, you can clone it directly.
a. Initialize a Local Git Repository:
 git init

This creates a .git directory, making your current directory a Git repository.
b. Clone a Remote Repository (if applicable):
If you are working with an existing remote repository, you can clone it:
 git clone https://github.com/username/repository.git
3. Pushing Changes to a Remote Repository
After making commits locally, you will want to push your changes to the remote repository.
a. Push Changes:
Push your local branch to the remote repository:
  git push origin <branch-name>

Pushing content to my test repository. (used VS code terminal)

Changes visible over remote repository

To Pull changes:
1. Navigate to your repo
Open your terminal and navigate to the directory of your local Git repository using the
following command:
cd /path/to/your/repository
2. Check your current branch
To check which branch you’re currently on, use the command:
git branch
3. Commit or stash local changes (if any)
If you have any uncommitted changes, make sure to commit or stash them first. To check
for changes, run:
git status
o If you have changes, commit them by using:
git add . && git commit -m "message"
o Or, if you want to save the changes temporarily, stash them with: git stash
4. Pull from the remote repo
To pull the latest changes from the remote repository, use the command:
git pull origin <branch>
Replace <branch> with the name of the branch you want to pull from, e.g., main.
5. Resolve conflicts (if any)
If there are any conflicts between your local changes and the changes from the remote
repository, Git will notify you. To resolve conflicts:
o Open the conflicting files and manually make the necessary changes.
o Once resolved, add the files to the staging area with:
git add <resolved-file>
o Commit the resolved conflicts:
git commit -m "Resolve merge conflicts"
6. Push changes (if needed)
After pulling the changes, if you have made any local changes that you want to push to
the remote repository, use the following command:
git push origin <branch>
Replace <branch> with the name of your current branch.

Pull Request sent however nothing to be changed.

 Index Task 1.2

S. No Program Title Page No.

1.Merging 2 Branches on Git

1. 01
 Merge two branches within a repository.

2.Clone, Fork, and Create Pull Requests

2. 04
 Demonstrating forking, cloning, and pull requests.

3. Using .gitignore and README Files

3.  Managing ignored files and creating structured README files. 08

4. 4. Show the Networking Graph structure

 Experiment 1

Aim:
Merging 2 Branches on Git
 Merge two branches within a repository.

Theory:
In Git, merging is the process of integrating changes from one branch into another. This is
typically done to combine the work done in different branches, such as when a feature branch
is merged back into the main branch.
1. Merge Operation: When you run git merge <branch-name>, Git tries to automatically
combine the changes from the specified branch (<branch-name>) into your current
branch. If there are no conflicting changes, the merge is seamless.
2. Merge Conflicts: If two branches have conflicting changes in the same file or section of
code, Git cannot automatically merge them. In this case, Git will flag these conflicts, and
you'll need to manually resolve them before completing the merge.
3. Fast-forward Merge: If the current branch has not diverged from the branch you're
merging, Git will simply "fast-forward" the pointer of the current branch to the latest
commit of the branch you're merging. This happens when no commits exist in the target
branch since the last common ancestor.
4. Non-fast-forward Merge: If both branches have diverged and contain unique commits,
Git creates a new "merge commit" to combine the histories of both branches.
Merging is a fundamental part of collaborative workflows in Git, helping multiple
developers work on different features or fixes in parallel and then integrate their changes.

Procedure:
1. Creating a new branch in your repository using Git branch <branch-name>

Creating a new branch Bug-fix.

2. After successfully creating a new branch, you can switch to it by the help of Git
checkout bug-fix and then add some code or file to further then merging it with the main
branch.

Adding fixes.txt to the new branch (bug-fix)

3. Now after successfully creating a new branch and adding some code or files we need to
go to the main branch and merge our bug-fix branch with the main branch using Git
merge <branch-name> command.

The bug-fix branch merged successfully to the main branch and now the main branch
contains the fixes.txt file from bug-fix
 Experiment 2

Aim:
Clone, Fork, and Create Pull Requests
 Demonstrating forking, cloning, and pull requests.

Theory:
1. Forking a Repository
Forking a repository on GitHub creates a personal copy of someone else’s project. This
allows you to experiment with changes without affecting the original repository. Forking is
commonly used in open-source projects, as it enables you to contribute without needing
direct access to the original codebase. Once a repository is forked, it appears in your GitHub
account, and you can modify it freely. This makes it easier to propose improvements or bug
fixes without impacting the main repository.

2. Cloning a Repository
Cloning a repository refers to copying the contents of a repository (whether your own or
someone else’s) to your local machine. This allows you to work with the files directly on
your computer, without needing a continuous connection to GitHub. After forking a
repository, you clone it to your local machine by copying the repository URL and using it to
create a local copy. Once cloned, you can make edits, create branches, and track changes
locally before pushing them back to GitHub.

4. Creating a Pull Request (PR)

A Pull Request (PR) is a method for proposing changes from your local or forked
repository back to the original repository. It allows project maintainers to review your
changes before merging them into the main codebase. After making and committing
changes locally, you push them to your fork on GitHub. Then, you create a PR by
selecting the changes you want to propose and submitting them for review. PRs enable
the project maintainers to provide feedback and ensure the changes meet the standards of
the project before they are merged into the main repository.

Summary
The process of forking, cloning, and creating a pull request is essential for contributing to
open-source projects or collaborating in a team. Forking lets you make changes to a personal
copy of the project. Cloning allows you to work locally on your machine. Finally, creating a
pull request proposes your changes to the original repository for review and merging. This
workflow is crucial for managing code, collaborating with others, and maintaining project
organization.

Procedure:
1. Fork a Github repository:
 Step 1: Go to the GitHub repository you want to contribute to.
 Step 2: At the top right corner of the repository page, click the Fork button. This creates a
copy of the repository in your GitHub account.
 Using fork on Github.

 Step 3: You now have a personal copy of the repository in your account. You can make
changes to this fork without affecting the original repository.

Repository successfully forked.

2. Clone a Github repository to the local system:

 Step 1: Go to your GitHub account and open the forked repository.

 Step 2: Click the Code button on the repository page and copy the URL (HTTPS or SSH) for
cloning.

 Step 3: Open a terminal or Git Bash on your local machine.

 Step 4: Use the git clone command followed by the URL you copied to create a local copy of
the repository on your computer.

 Step 5: Navigate to the cloned repository folder on your local machine to begin making
changes.
3. Creating a Pull Request (PR):

 Step 1: After making and committing changes locally, push them to your forked repository
on GitHub.

Changes have been made and pushed to the remote repository(personal)

 Step 2: Go to the forked repository on GitHub.

 Step 3: GitHub will often prompt you to create a pull request when you push changes to a
new branch. If you don’t see the prompt, go to the Pull Requests tab and click New Pull
Request

Pull request dashboard.

 Step 4: Choose the base repository (the original repository you forked from) and the
compare branch (your branch with the changes).
 Pull request created successfully.

 Step 5: Provide a title and description for your pull request, explaining what changes
you’ve made and why.
 Step 6: Click Create Pull Request to submit it for review.

Pull request reflecting on the other user’s repository.

 Experiment 2

Aim:
Using .gitignore and README Files
 Managing ignored files and creating structured README files.
Theory:
Managing Ignored Files with .gitignore and Creating Structured README Files
1. The .gitignore File
The .gitignore file is used to specify which files or directories Git should ignore, keeping the
repository clean from unnecessary files (e.g., logs, build artifacts, or sensitive information).
Common entries include:
 *.log (ignore all log files)
 node_modules/ (ignore Node.js dependencies)
 .env (ignore environment variable files)
It helps in maintaining a tidy project by excluding files that don’t need to be version-controlled.

2. README File
A README provides essential information about the project, including its purpose, setup
instructions, and usage. Key sections typically include:
 Project Title and Description
 Installation and Usage instructions
 Contributing guidelines and License

A well-structured README ensures the project is accessible and easy to understand

for new users and contributors.

Procedure:
Procedure for Using .gitignore and Creating a README File
1. Procedure for Using .gitignore
1. Create a .gitignore File:
 In the root directory of your repository, create a file named .gitignore.

Created and added .gitignore file.

2. Define Ignored Files:
 Open the .gitignore file and list the files or directories you want Git to ignore
using patterns. Example: Sample.log

Added sample.log file in .gitignore.

3. Commit the .gitignore File:
 After adding the required entries, commit the .gitignore file to your repository so
that others working on the project follow the same ignore rules.

Changes committed on the local repository

4. Check Ignored Files:
 Ensure that the files are ignored by running git status and confirming that
unwanted files do not appear.

The sample.log file does not appear here.

2. Procedure for Creating a README File
1. Create a README.md File:
 In the root directory of your repository, create a file named README.md.

Readme.md file created.

2. Write Project Title and Description:
 Start with the project title followed by a brief description of what the project
does and its purpose.
3. Commit the README File:
 After completing the README file, commit it to your repository to make it
available to all collaborators.

Added text to the readme file and committed.

The added readme file reflecting on remote repository

 Experiment 2

Aim:
Show the Networking Graph structure.

Theory:
The Network option in GitHub Insights visualizes the forking history and contributions to a
repository.
Key Features:
1. Fork Network Visualization: Shows how your repository has been forked and its
relationships with other repositories.
2. Branching and Merging: Displays when branches are created, merged, or deleted.
3. Contributions Overview: Highlights commits and pull requests by different users.
4. Code Changes: Tracks the evolution of the project through forks and branches.

Procedure:
Procedure to Access the Network Graph in GitHub Insights:
1. Go to the Repository:
 Open the repository on GitHub that you want to analyze.

Check the insights option on the repository.

2. Navigate to the Insights Tab:

  At the top of the repository page, click on the "Insights" tab.

Look for Network option.

3. Select Network:
 From the Insights menu on the left sidebar, click on "Network".
4. View the Network Graph:
 The Network graph will load, showing the forking history, branches, and contributions over
time.

The following graph shows current branches and other info.