0% found this document useful (0 votes)
37 views15 pages

SCM Final

scm file for chitkara university

Uploaded by

Kartikeya Jain
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
37 views15 pages

SCM Final

scm file for chitkara university

Uploaded by

Kartikeya Jain
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

A Project report

on
“Task 2”
with
Source Code Management

Submitted by :- Submitted To:


To:-
Kartikeya Jain Dr.Renu Popli
2310991865 Assistant Professor
G-21-A

Team Member 1 Name: Hardik Jain Roll No. 2310991837


Team Member 2 Name: Kartikeya Jain Roll No. 2310991865
Team Member 3 Name: Palak Pahuja Roll No. 2310991920
310991920
INDEX

S. NO Experiment Name remarks


1. Introduction

2. Problem statement

3. Solution

4. Objective

5. Create a distributed Repository


and add members in project
team
6. Open and close a pull request

7. Create a pull request on a


team members repo and close
pull requests generated by
team members on own Repo
as a maintainer
8. Publish and print network
graphs
Introduction:--
What is GIT and why is it used?
Git is a version control system that is widely used in the programming world. It is used for
tracking changes in the source code during software development. It was developed in 2005
by Linus Torvalds, the creator of the Linux operating system kernel.
Git is a speedy and efficient distributed VCS tool that can handle projects of anysize, from
small to very large ones. Git provides cheap local branching, convenient staging areas, and
multiple workflows.
orkflows. It is free, open
open-source
source software that lowers the cost because developers
can use Git without paying money. It provides support for non-linear
non linear development. Git
enables multiple developers or teams to work separately without having an impact on the
work of others.
Git is an example of a distributed version control system (DVCS) (hence Distributed Version
Control System).

What is GITHUB?
It is the world’s largest open-source
source software developer community platform where the users
upload their projects using the software Git.
What is the difference between GIT and GITHUB?

What is Repository?
A repository is a directory or storage space where your projects can live. Sometimes GitHub
users shorten this to “repo.” It can be local to a folder on your computer, or it can be a storage
space on GitHub or another online host. You can keep code files, text files, image files, you
name it, inside a repository.
What is Version Control System (VCS)?
A version control system is a tool that helps you manage “versions” of your code or changes
to your code while working with a team over remote distances. Version
sion control keeps track of
every modification in a special kind of database that is accessible to the version control
software. Version control software (VCS) helps you revert back to an older version just in
case a bug or issue is introduced to the system
system or fixing a mistake without disrupting the
work of other team members.
Types of VCS
1. Local Version Control System
2. Centralized Version Control System
3. Distributed Version Control System
I. Local Version Control System: Local Version Control SystemSystem is located in your local
machine. If the local machine crashes, it would not be possible to retrieve the files, and all the
information will be lost. If anything happens to a single version, all the versions made after
that will be lost.
II. Centralized Version Control System: In the Centralized Version Control Systems, there
will be a single central server that contains all the files related to the project, and many
collaborators checkout files from this single server (you will only have a wo
working
rking copy). The
problem with the Centralized Version Control Systems is if the central server crashes, almost
everything related to the project will be lost.
III. Distributed Version Control System: In a distributed version control system, there will be
one or more servers and many collaborators similar to the centralized system. But the
difference is, not only do they check out the latest version, but each collaborator will have an
exact copy of the main repository on their local machines. Each user has their own repository
and a working copy. This is very useful because even if the server crashes we would not lose
everything as several copies are residing in several other computers.
Experiment :- 1
Aim: Create a distributed Repository and add members in project team
1) Login to your GitHub account and you will land on the homepage as shown below. Click
on New in Repositories option in the menu bar.

2) Enter the Repository name and add the description of the repository.
3) Select if you want the repository to be public or private.

4) Now, you have created your repository successfully.


5) To add members to your repository open your repository and select settings option in the
navigation bar.
6) By clicking on Add people we can add more collaborators to the repository.
Experiment :- 2
Aim: Open and Close a Pull Request
1) To open a pull request we first have to make a new branch, by using git branch branchname
option.

2) After making new branch we add a file to the branch or make changes in the existing file.
3) Add and commit the changes to the local repository.
4) Use git push origin branchname option to push the new branch to the main repository.
5) After pushing new branch GitHub will either automatically ask you to create a pull request
or you can create your own pull request.
request

6)) GitHub will detect any conflicts and ask you to enter a description of your pull request.
7) After opening a pull request all the team members will be sent the request if they want to
merge or close the request.

8)) If the team member chooses not to merge your pull request they will close your pull
request.
9)) To close the pull request simply click on close pull request and add comment/ reason why
you closed the pull request.
10)) You can see all the pull request generated and how they were dealt with by clicking on
pull request option.
Experiment :- 3
Aim: Create a pull request on a team member’s repo and close pull requests generated by
team members on own Repo as a maintainer
To create a pull request on a team member’s repository and close requests by any other team
members as a maintainer follow the procedure given below:

1. Do the required changes in the repository, add and commit these ch


changes
anges in the local repository in
a new branch.
2. Push the modified branch using git push origin branchname.
3. Open a pull request by following the procedure from the above experiment.

4. The pull request will be created and will be visible to all the team members.
5. Ask your team member to login to his/her Github account.
6. They will notice a new notification in the pull request menu.
7. Click on it. The pull request generated by yo
you will be visible to them.
8. Click on the pull request. Two options will be available, either to close the pull request or
Merge the request with the main branch.
9. By selecting the merge branch option the main branch will get updated for all the team
members.
embers. 10.By selecting close the pull request the pull request is not accepted and not
merged with main branch.
11.The process is similar to closing and merging the pull request by you. It simply includes
an external party to execute.
12.Thus, we conclude de opening and closing of pull request. We also conclude merging of the
pull request to the main branch.
Experiment :- 4
Aim: Publish and print network graphs
The network graph is one of the useful features for developers on GitHub. It is used to
display the branch history of the entire repository network, including branches of the root
repository and branches of forks that contain commits unique to the network.
A repository's graphs give you information on traffic, projects that depend onthe repository,
contributors and commits to the repository, and a repository's forks and network. If you
maintain a repository, you can use this data to get abetter understanding
understanding of who's using your
repository and why they're using it.
Some repository graphs are available only in public repositories withGitHub Free:
• Pulse
• Contributors
• Traffic
• Commits
• Code frequency
• Network
Steps to access network graphs of respective
re repository
1. On GitHub.com, navigate to the main page of the repository.
2. Under your repository name, click Insights.

3. At the left sidebar, click on Network


4. You will get the network graph of your repository which displays the branch history of the
entire repository network, including branches of the root repository and branches of forks that
contain commits unique to the network.

Listing the forks of a repository Forks are listed alphabetically by the username of the person
who forked the repository
Clicking the number of forks shows you the full network. From there you can click
"members" to see who forked the repo.
1. On GitHub.com,
.com, navigate to the main page of the repository.
2. Under your repository name, click Insights.
3. In the left sidebar, click Forks.
4. Here you can see all the forks
Viewing the dependencies of a repository You can use the dependency graph to explore the
code your repository depends on. Almost all software relies on code developed and
maintained by other developers, often known as a supply chain. For example, utilities,
libraries, and frameworks. These dependencies are an integral part of your code and any bugs
or vulnerabilities in them may affect your code. It's important to review and maintain these
dependencies.

You might also like