FACULTY OF INFORMATION TECHNOLOGY:
Field of study: Information Technology
Specialty: Programming
Abdulla Yerezhep
Student Identification Number (SID) 59098
Analysis of affection of VCS to student’s educational and
professional life
Supervisor: dr. inż. Barbara Fryc
DIPLOMA THESIS AT FIRST-CYCLE STUDIES
Rzeszów 2021
I, the undersigned, hereby state that the thesis entitled “Utilization of video games in programming
learning for primary school children” submitted by me has been prepared without any help. I also state
that the thesis has not been subject to procedures connected with acquiring an academic (Bachelor’s)
degree at a higher education institution at any earlier time. I moreover declare that this version of the
thesis is identical with the submitted electronic version. ................................................................ date
author’s legible signature
2
Table of content:
INTRODUCTION
1. INTRODUCTION TO VERSION CONTROL SYSTEMS
1.1 VERSION CONTROL SYSTEM
1.2 CENTRALIZED VERSION CONTROL SYSTEMS
1.3 DISTRIBUTED VERSION CONTROL SYSTEMS
2. CENTRALIZED VS. DISTRIBUTED
2.1.1 THREE GENERATIONOF OF VCS
2.1.2 WHY ARE SOFTWARE PROJECTS MOVING FROM CVCS TO
DVCS?
3. SOURCE CODE MANAGEMENT SOFTWARES
3.1 SUBVERSION(SVN)
3.2 GIT
3.3 COMPARISON OF GIT AND SVN
3.4 GITHUB
3.4.1 GITHUB IN CLASSROOM ENVIRONMENT
3.4.2 IMPORTANCE OF GITHUB IN RECRUITING PROCESSES
4. PRACTICAL PART
4.1 METHODOLY
4.2 SURVEY
4.2.1 FINDINGS
4.2.2 INTERPRETATION
4.3 WEB – SITE DEVELOPMENT USING GIT AND GITHUB
4.3.1 STACK OF SOFTWARE USED
4.3.2 FUNCIONALITIES OF THE WEB-SITE
4.3.3 GITHUB INSIGHTS
5. CONCLUSION
6. REFERENCES
3
INTRODUCTION
I have decided to write the thesis work that I have titled "Version Control System Software" because, in
the past several decades, version control systems have played an important role in software developers'
work process during project creation and also in students an educational environment. In this research
paper, I will provide information on the fundamentals of version control systems, as well as the history
and features that have evolved over time. Currently, the process of developing large software products
is quite complex and time-consuming. The developers often face the problem of controlling the changes
made in the program code, since the development process is iterative. According to that, it becomes
necessary to store previous and stable versions of the project, available to programmers, and to perform
current work on the working version by using version control systems. As a consequence, the issue I
want to reflect on in my paper is extremely subjective and motivated by my own experience, although
have relevance to other students who are also studying in the specialty of IT technologies at the Faculty
of Programming, which translates the idea of significant need for additional background and context on
the source control software subject. My survey investigates this problem and collects valuable information from first, second, and third-cycle students studying in an information technology discipline, and
the majority of them report that they lack the proper knowledge regarding VCS and particularly Git and
GitHub, which itself is essential for learners in computer science to have and to be experienced in this
for the productive future development and further employment. Indeed by creating projects to your
GitHub and committing actively raises your chances to get a software developer job.
This tends to be a common problem for someone who is just starting to explore the amazing world of
computer sciences by learning and improving his/her software engineering skills; however, a number of
studies have shown that this problem can be solved by introducing and implementing VCSs into the
classroom from the very beginning of students' journey to become competent and effective software
developers.
Therefore, my thesis work will provide information on three generations of VCSs and important aspects
to pay attention when categorizing VCSs to centralized and distributed by describing both of them
closely. Next, I mention Subversion in my thesis being the most popular centralized VCS among open
source project community, although yet will cover only some basics of it. Although more detailed description will be on distributed version control systems and on its fundamentals following by Git that
occur favorite among other source code management tools, which I analyze by objective comparison of
four version control systems that are: Git; Subversion; Mercurial; CVS and evaluate main parameters of
version control software to have. Lastly, I would like to propose an important idea of implementing a
VCS to the classroom environment by the teacher and making it main tool for checking student’s homework and project assignments and code creation progress during lessons. By analyzing work of few other
researchers on that subject and outlining best practices.
To conclude VCS is an integral part of the daily professional practice of today's software development
team and even for individuals. Individual software developers who are regularly working in teams with
an effective version control system usually recognize the incredible benefits of version control, even
when working on small solo projects. Accustomed to the powerful advantages of version control systems, many developers have no idea how to work without them. It has become an essential, a whole
social media for programmers where one can collaborate with people through code and share as well as
publish services.
So, the main questions that’d been considered in this thesis work is what is version control system in
general? Why do you need such technology applied to your coding process? How to choose right software source control for your projects? How to raise student’s motivation to learn, experience in writing
code, and sense of belonging?
4
The main aim of the thesis
My bachelor's thesis' main goal is to provide insight and cover the fundamentals of version control systems (VCS). In my objective of the study I want to research chosen topic by examining and reviewing
scientific literature which are available on the internet for public use and are written by researchers on
related topics, in addition I have provided public survey among bachelor degree students from majoring
in information technology of University of Information Technology and Management(UITM) and furthermore I will attempt to evaluate and describe my own experience by creating a web-application using
approaches based on best practices of using VCS’s to introduce reader to one of the essential aspects of
software engineering that is version control system. As a case study I want to target Git the preferred
version control system of most developers all around the world and GitHub platform where developers
can store their projects and network with those who share their interests in more detail among other
version control systems like Subversion, Mercurial which also are described in following paper, but only
briefly. From my own experience of using Git and GitHub I realize how much easier it becomes to track
on code changes and prevent complications in the future which is why one of the main goals is to give
reader an understanding of how important is to have such tools in student classroom environment moreover in the future career life as a programmer.
First chapter is divided into three subchapters and were chosen to write to introduce VCS, it’s history,
why we need such systems, and show two main types of the system, that are Centralized and Distributed
version control system.
In second chapter I go in detail about differences of the system how it evolved throughout time, at the
end I have compared them with cons and pros of both systems. I also tried to answer for a question why
small and big projects most likely to choose DVCS rather than CVCS as time moves forward.
In third chapter we go further with comparison and choose two most popular software from both types
and describe them closely and compare these two software that we use to manage our source code, I
used different research papers to analyze credible data and build up my own opinion about which is at
the end of the day is more in demand. Additionally, I have done research about importance of GitHub
which is basically social media for programmers and also acts as a virtual vault where we can store our
source code and all kind of different projects, moreover I covered such an important topics as GitHub in
classroom environment and in recruiting processes.
And lastly my practical part consists of survey that was conducted by me and my findings, as well as
my own project that I have developed in order to track all the progress to observe my data that was
created by GitHub automatically, by analysis this information it efficiently helped me to see my issues
which will help me in my future projects.
5
CHAPTER 1. INTRODUCTION TO VERSION CONTROL SYSTEMS
1.1 VERSION CONTROL SYSTEM
“The Version Control System (VCS) is a tool for tracking the progress of a changing object. In other
words, a Version Control System (VCS) is a software system that tracks the evolution of an entity. To
put it another way, it's a system that keeps track of any improvements created by software developers”
[Zolkipli, Ngah and Deraman, 2018].1
Version control systems help development teams handle improvements to source code over time. It records any improvements made to the code in a special database. Developers will go back if a bug is
discovered and compare it with previous versions of the code to correct bugs and understand how to
effectively minimize the damage for everyone on the team.
By Eric Raymond’s opinion stated in his book “Understanding Version-Control Systems” says that:
“The most basic capability you get from a VCS is reversibility, the ability to back up to a saved, knowngood state when you discover that some modification you did was a mistake or a bad idea.”. Other two
important capabilities by his opinion are concurrency, and annotation.[Raymond, 2007]2
Source code is a treasure in nearly all software projects: it is a valuable resource that must be protected.
Source code is a repository of invaluable knowledge and understanding of the problem field for most
software development teams, which they have scrupulously collected and refined.
“If you don’t have source control, you’re going to stress out trying to get programmers to work together.
Programmers have no way to know what other people did. Mistakes can’t be rolled back easily. The
other neat thing about source control systems is that the source code itself is checked out on every programmer’s hard drive — I’ve never heard of a project using source control that lost a lot of code.”
[Spolsky, 2016]3
Version control protects against small and massive failures, made under accidental human element, and
unintended consequences. In the case of simultaneous work of several people on the same project, source
control systems keep track of conflicts that occur between users related to changing the same file. Most
systems can automatically merge changes made by different developers. However, such merging is possible only for text files and provided that different (non-overlapping) parts of this file have changed.
The above limitation is due to the fact that most version control systems are focused on supporting the
software development process, and the source codes of programs are stored in text files. If the automatic
merge fails, the system may prompt you to fix the problem manually.
Due to an unknown or too complex file format, there are times when merging is not possible in either
mode. Some version control systems provide the ability to lock a file in the vault. Locking it prevents
other users from obtaining a working copy or prevents modification of the working copy of the file.
To sum up let’s overview features that VCS provides according to Mike G. Miller.[Miller, 2015]4
Version control systems provide the following capabilities:
 The ability to take "snapshots" of your job on a daily basis at different points in time. It's best
if it's done right after changes have been made and experiments have been completed.
 To go back to a previous version, restore missing data, or figure out when a bug first appeared.
 To share your progress with others and keep you up to date with your work.
 To deal with conflicts involving other people's jobs.
1
Zolkipli N. N, Ngah A. and Deraman A.: Version Control System: A Review, Procedia Computer Science 135:408-415
2
Raymond E.: Understanding Version-Control Systems ( DRAFT ) Why use version control ? Categorizing Version-Control
Systems
3
Sapolsky J. :The Joel Test: 12 Steps to Better Code
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ of 09.08.2000
4
Miller M.: Professional Software Development
https://mixmastamyk.bitbucket.io/pro_soft_dev/index.html#professional-software-development of 31.03.2021
6

To work from different locations, such as work, home, or a mobile device, while keeping
copies in sync.
 Asset protection—remote backup of sensitive data.
Increased protection, which allows for more experimentation.
Traditional version control systems use a centralized model. The point is the presence of a unified
storage of documents controlled by a special server. Thus, it handles most of the version control functions. Distributed version control is more advanced, runs better, is less prone to bugs, has more functionality, and is a little more difficult to comprehend. Let’s have a closer look on both of these systems.
According to “Version Control Systems” by Stefan Otte journal article VCSs allow for the acceleration
and simplification of the software development process, as well as the creation of new workflows. They
have a model for concurrent access and keep track of files and their past. VCSs can be approached from
two perspectives:
1) the centralized model with the centralized Version Control Systems (CVCSs).
2) the distributed model with the distributed Version Control Systems (DVCSs).
[Otte, 2005]5.
1.2 CENTRALIZED VERSION CONTROL SYSTEM
In this section, I'll explain what a centralized control system is along with listing some of its operations
and distinguishing characteristics.
Fig. 1 Centralized Version Control System Diagram
Source: Somasundaram R. (2013). Centralized version control 10.04.2018
Centralized version control systems are built on the idea that there is a single "central" version of your
project somewhere on a server, and developers "commit" their changes to this main copy. [Lionetti,
2012]6. The server keeps an updated record of things, whereas users only keep a local version of such
shared files. The repository can be reached from anywhere via LAN or WAN. In centralized version
control a team of software developers work on just one repository through checkout, all developers make
some changes to the repository, and only the most recent version of the data is extracted from the server
and that’s why everyone are aware when someone else from the team made a change as well as when
someone made some wrong commit to the branch. There is certain level of restrictions in committing to
5
Otte S.: Version Control Systems Computer Systems and Telematics Institute of Computer Science
Freie Universit¨at Berlin, Germany 2005 pp 108-109.
6
Lionetti. G: What is version control: centralized vs. DVCS https://www.atlassian.com/blog/software-teams/version-controlcentralized-dvcs of 14.02.2012.
7
the project’s repository, changes to the data can only be made by trusted contributors, since centralized
version control refers to a single repository containing the accurate project version. A centralized version
control system is commonly used in both large commercial and small open source projects. Although
developing a project using CVCSs might be sometimes challenging, for example users would not be
able to merge their progress or just save the published updates if the central repository is unavailable,
and it will be lost if the central repository is damaged.
A centralized version control system can perform 18 basic operations. Let’s get familiar with some of
the most usefull operations and understand what kind of function they perform.
1. Create - A new repository is created using the create function. This is one of the first operations
that can be used, and it will be used far less often after that.
2. Checkout - When you need to create a new working copy for an existing repository, you use the
checkout operation.
3. Commit - Adds the updates from the working copy to the repository as a new changeset.
4. Update - Updates the working copy in relation to the archive. Update is similar to a mirror image
of commit. Both operations transfer changes from the operating copy to the repository. Commit
is used to move data from the working copy to the repository. The update is in the opposite
direction.
5. Status - Lists the modifications that have been made to the working copy.
6. Diff - Show the details of the modifications that have been made to the working copy.
7. Branch - Create another line of development.
8. Merge - Apply changes from one branch to another.
9. Resolve -Handle conflicts resulting from a merge.
10. Lock - Prevent other people from modifying a file.
CVS, Subversion, ClearCase, and Perforce are four of the most popular centralized version control systems you might have heard of.
1.3 DISTRIBUTED VERSION CONTROL SYSTEM
Distributed version control systems still have the functionality to store everything just in one central
repository, but has got involved and gives the opportunity to its each contributor to have their own copy
of the repository and the history of changes as shown in Figure 2. In fact, the term "distributed" comes
from the idea that there is no single point of contact with the work's past, allowing everyone to interact
with each other team member. No one else would be able to see a developer's project branch if he makes
one. Other developers need to know where they can get a copy of the project that the developer is actually
working on in order to see what's going on, they'll be able to combine his branch with their own, so they'll
be able to see the results. Another huge advantage for using DVCSs is that developers are able to contribute to the project repository in an offline mode. You can presume how relevant this function is in a
progressively mobile world with a rising number of remote contributors. Some of the most common
DVCSs might be: Git; Mercurial; Bazaar.
8
Fig. 2 Distributed Version Control System Diagram
Source: Chacon S & Strauv B (2013). Distributed version control system of 10.04.2018.
9
CHAPTER 2. CENTRALIZED VS. DECENTRALIZED
2.1 THREE GENERATION OF VCS
Here is the representation of the evolution of version control tools that can be split into three generations
by Eric Sink, 2011 in his book “Version Control by Example”. [Sink, 2011]7
Table 1. Three Generations of Version Control
Generation
Networking
Operations
Concurrency
Examples
First
None
One file at a time
Locks
RCS, SCCS
Centralized
Multi-file
Merge
before commit
Distributed
Changesets
Commit before
merge
CVS, SourceSafe,
Subversion, Team
Foundation Server
Bazaar,
Git,
Mercurial
Second
Third
Source: Version Control by EXAMPLE written by Sink in 2012
As you can notice on the Table 1 above the evolution of version control tools over the last five decades
has shown a steady trend toward more concurrency.
 Concurrent development was done exclusively with locks in first-generation tools. At any given
time, only one person can be working on a file.
 With one notable exception, the second-generation software is a lot stricter when it comes to
simultaneous modifications. Before they can commit, users must merge the new modifications
into their work.
 Merge and commit can be separated with third-generation tools.
First generation of VCSs were designed to monitor single file changes, and only tested files could be
modified locally by one person at a time. They were designed with the expectation that all users would
use their own accounts to log into the same shared Unix host.
In the second-generation networking was implemented to VCS, which resulted in centralized repositories containing the 'official' versions of their projects. This was a significant step forward because it
allowed several users to check out and work on the code at the same time while still contributing to the
same central repository. To make commits, you also needed to have network access.
The distributed VCS is the third generation. There is no centralized copy of the repository in a distributed
VCS, so all versions are created equal. This clears the way for commits, branches, and merges to be
generated locally and pushed to other repositories as required without requiring network access.
As mentioned above the latest VCSs are decentralized. That means that the project may have many
repositories, and these projects retain a sort of super-merge of repositories that attempt to reconcile their
history of change. Every developer has its own repository at its own limit, and the fusion of repositories
replaces check and commit operations for code transfer between developers. One feature benefit is that
systems such as this support the disconnected operation; since you have an own repository you don't
have to commit to the internet archive. Changes are slower and less popular in a different repository to
push.
Due to the increased interest in DVCSs over its predecessor CVCS, as well as the advantages that decentralized VCSs offered, a large number of software projects with closed and open source codes chose
to move from CVCS to DVCS at the time.
7
Sink. E.: Version Control by Example, Pyrenean Gold Press, Illinois 2011.
10
2.2 TENDENCY OF SOFTWARE PROJECTS TO MOVE FROM CVCS TO
DVCS
In research work “Version Control System: A Review,” conducted by Nazatul Nurlisa Zolkifli, Amir
Ngah*, you can observe in Table 2 to see differences between CVCS and DVCS.
Table 2. Comparison between CVCS and DVCS.and Aziz Deraman made a comparison, and the outline of their comparison
is shown in Table 2.
Version Control System
CVCS
DVCS
Repository
There is only one central repository which is the server.
Every user has a complete repository which is
called local repository on their local computer.
Repository Access
Every user who needs to access
the repository must be connected via network.
DVCS allows every user to work completely
offline. But user need a network to share their
repositories with other users.
Example of VCS Tools
Subversion, Perforce Revision
Control System
Git, Mercurial, Bazaar, BitKeeper
Projects that allow only several
users to contribute to the software development.
Team located in a single site.
DVCS is suitable for a single or more developers because the project repository is distributed to all the developers and this ability offer
a great improvement for the projects.
It also can be applied for a small or big software projects because it makes less difficult
for normal users to contribute to the development.
Team located in multiple site or different
countries and different timezones.
Software Characteristics
that suitable
Source: Nazatul Nurlisa Zolkifli et al. / Procedia Computer Science 135 (2018) 408–415
[Zolkipli, Ngah, Deraman, 2016]
Returning to the earlier statement, Brian de Alwis and Jonathan Sillito investigated the trend of software
projects to use DVCSs rather than CVCSs in “Why Are Software Projects Moving From Centralized to
Decentralized Version Control Systems?” in 2009. They have described the differences between a
CVCS and a DVCS in this paper, as well as described some of the rationales and perceived benefits
provided by projects to justify the transition.
They reviewed publicly accessible documentation and mailing list discussions for four open-source projects Perl, OpenOffice, NetBSD, and Python that have moved or are considering moving to a DVCS in
order to identify the rationales and perceived benefits provided by projects to justify such a transition.
They have initiated a qualitative study to address two research questions as part of a broader research
project to investigate version management methods and tool support. First, what advantages do these
projects see in a DVCS? Since migrating a source code repository to a new VCS takes considerable
effort, they assumed there must be compelling reasons to migrate. Second, in making the move, what
changes have these projects made to their development processes?
As a result, they identified four major anticipated benefits from transition:
 To support atomic changes. The most pressing requirement of a new VCS for the projects was repository-wide atomic commits. The NetBSD and OpenOffice groups have experienced repository
corruption as a result of using CVS branches, which may have gone undetected.
11

Simple automatic merging. DVCSs keep enough information to allow automatic and repeated
merges, which are common with long-lived branches.
 Improved support for experimental changes:
The Perl and OpenOffice projects aimed to improve non-committers' ability to work on experimental
improvements before applying them for inclusion.
 Support disconnected operation:
The Python project, in particular, sought to enable disconnected operation, a function useful for developers traveling.
Along with, survey of 820 developers provided by Caius Brindescu, Mihai Codoban, Sergii Shmarkatiuk, Danny Dig shows that 65% use DVCS and 35% use CVCS. They also examined 409M lines of
code changes from 358300 commits made by 5890 developers in 132 repositories containing a total of
73M LOC to gain more insight into how DVCS affects code changes.
The most remarkable results of their research study are:
 DVCS commits were smaller in size than CVCS
 Developers divide commitments in DVCS more often (group changes by purpose)
 Issue tracking labels are more likely to be mentioned in DVCS commits.
We may conclude that DVCS contain higher quality components than CVCS due to their smaller size,
consistent adjustments, and inclusion of issue tracking labels.[Brindescu, 2014]8
CHAPTER 3. SOURCE CODE MANAGEMENT SOFTWARES
3.1 SUBVERSION(SVN)
CVS was the preferred version control system until the 1990s. However, due to CVS's unwillingness to
include certain features in order to keep up with evolving trends, new CVS clones began to emerge:
CVSNT, EVS, Open CVS, and Subversion. Subversion grew in popularity and became the most widely
used version control system in the 2000s. Most CVS users started to migrate to Subversion in the early
to mid-2000s. [Ruparelia, 2010]9
I decided to include a Subversion overview in my thesis paper to demonstrate that, despite the popularity
supremacy of DVCSs, there is still a need for CVCSs, which are to these days widely used.
“Subversion is a free/open source version control system (VCS). That is, Subversion manages files and
directories, and the changes made to them, over time. This allows you to recover older versions of your
data, or examine the history of how your data changed. In this regard, many people think of a version
control system as a sort of “time machine.” [Collins-Sussman et al., 2004]10
As a centralized operated open source version control system, Subversion is well known and embraced
and features its stability as a safe place for useful data, simplicity of model and use and its capacity of
meeting the needs of a broad variety of users and projects from individuals to large companies.
Subversion was developed as a "better CVS" by CollabNet. Its features are best discussed with regard
to CVS enhancements, because they have decided to build an unlimited version control system that was
more suitable for the evolving trend in software projects. There are few things that SVN has improved
the most significant ones are directory versioning, true version history and atomic commits.
Directory versioning - Subversion uses a “virtual” versioned filesystem that records modifications to
entire directory trees over time, from the other side CVS just keeps track of the history of individual
files.
Brindescu C., Codoban M., Shmarkatiuk S., and Dig D.: “How Do Centralized and Distributed Version Control Systems
Impact Software Changes?,” Proceedings - International Conference on Software Engineering, no. CONFCODENUMBER
(2014): 322–33, https://doi.org/10.1145/2568225.2568322.
9
Ruparelia, Nayan B.. “The history of version control.” ACM SIGSOFT Software Engineering Notes 35 (2010): 5 - 9.
10
Collins-Sussman B., Fitzpatrick B., and Pilato C.: Version Control with Subversion, California 94305, USA 2004.
8
12
True version history - Subversion allows you to add, remove, copy, and rename files as well as directories. And each additional new file starts with a new, clean history of its own. Since CVS is restricted to
file versioning, operations such as copies and renames—which can occur with files but are actually
modifications to the contents of a containing directory—are not allowed.
And lastly atomic commits where a list of modifications is either entirely or partially inserted into the
repository. This enables developers to build and commit changes in logical chunks, avoiding issues that
can arise when only a portion of a collection of changes is successfully submitted to the repository.
To summarize, while SVN has exceeded CVS in terms of new useful capabilities, there are still many
reasons to avoid it. It's not a suitable tool for automation or Software development. And that it no longer
has a supporting community behind it. Because of this, migrating to the distributed version control system Git would be a safer option. In response to the question, "Does anyone still use Subversion?" the
answer we can see on Chart 1 and it’s yes, and about 23% of open source projects use Subversion while
72 percent are on Git.
Chart 1. Compare Repositories
Chart 1. Openhub.net. (n.d.). Open Hub, the open source network. http://www.openhub.net/.
3.2 GIT
To introduce you with Git I will be relying on the content described in a book “Pro Git” which provides
a reader full capability of it and describes key points that makes it different from other VCSs. Git is a
distributed version control system, free and open source, built to manage anything with speed and
productivity from small to large projects. It was created in 2005 by the author of Linux OS -Linus Torvalds.
One of the most significant of concepts in Git is snapshots, the idea behind it would be better described
as a reference of a taking a picture or screenshot of the files at the exact moment of the progress of your
work, so a repository's snapshot is equivalent to a video's screenshot. Which is basically an opposite to
the other VCSs way of functioning such as Subversion, CVS, Bazaar etc. that consider the data they
retain as a set of files, with recent changes to every file throughout time. Git considers the data to be a
series of snapshots. If a file hasn't modified, Git does not really save it once more; instead, it stores a
relation to the previous version of the file it has already saved. Almost every element of version control
that most other systems borrowed from the previous generation had been reconsidered by Git. [Chacon
& Straub, 2014]11.
11
Chacon S, Straub B. Pro git: Everything you need to know about Git. Second. Apress; 2014. https://git-scm.com/book/en/v2
13
Fig 3. Differences in storing data between Git and other VCSs. Source: Pro Git.
As shown in Figure 3 in comparing to previous VCSs Git tries to be as light and fast as possible, so it
doesn't just blindly copy the entire directory every time, but shrinks (whenever possible) a commit into
a changeset or "delta" between the current version and the previous one.
Other advantages of Git are local history backup, that is characteristic of almost any distributed version
control systems. This feature significantly speeds up project’s creation process, because developers do
not need to request a server for any data, simply because they are able to access it from a local disk. Git
uses cryptographic function checksumming SHA-1(Secure Hash Algorithm 1) to store everything in
database by the value of hash, not by regular file names, which allows Git know about every file being
changed or got corrupted.
Here are some basics of using Git. Only required and useful (in my opinion) parameters are listed here,
because listing all of them would be inappropriate. To do this, use git command -help or --help, where
command is the name of the command you want to get help about.
 Creating a repository
git init - Creates git repositories and a .git directory in the current directory.
git clone - Clones repositories named origin (or whatever you specify -o “name”) from the branch that
HEAD points to (or the one you specify -b “branch”). You can also clone only the HEAD branch you
need (or the one you specify in -b “branch”) by specifying --single-branch. By default, all tags are cloned,
but by specifying --no-tags you do not need to clone them. After executing the command, a. git directory
is created in the current directory
 File status
git status - This command can show you which branch you are currently on and the state of all files.
There are no required options, the only useful ones are -s, which will show a brief idea of the state of
the files.
14
Fig. 4 Life cycle of the files. Source: Pro Git.
As shown in Figure 5 files can be Untracked and Tracked. Tracked files can be in 3 states: Unmodified,
Modified, Staged.
When you add (via git add) a "untracked" file, it enters the "Staged" state.
If you make changes to a file when it is in the "Unmodified" state, it will be moved to the "Modified"
state. When you save a modified file (one that is in the "Modified" state), it enters the "Staged" state.
When you commit a file (which is in the "Staged" state), it is moved to the "Unmodified" state.
If the versions of the file in HEAD and the working directory differ, the file will be in the "Modified"
state; otherwise, the file will be in the "Unmodified" state.
If the version of the file in HEAD differs from the version in the working directory but not from the
version in the index, the file is in the "Prepared" state.
This cycle is interpreted as follows: Unmodified > Modified > Staged > Unmodified
First you update the file, save it in the index, commit it, and then do it all over again.
One more part of Git that I want to cover is branching.
 Commits
git commit – This command commits changes. git commit --amend - can quickly overwrite the last
commit
 Viewing history
git log – helps you to view the commit history of your repository.
 Working with a remote repository
git remote [options] - For working with external repositories
git remote add [options] “repository name” “URL address”- If you have cloned the repositories via the
http URL, then you already have a link to the external one. Otherwise, you can add it with this command.
git push - Sends all staged commits to the server.
 Branching
git branch “name” – creates new branch.
git merge – to unify(merge) two branches of git repository.
Finally, I would like to mark one of the important facts that a lot of students and people that are new to
programming might often misunderstand is the idea that Git and GitHub is totally different pieces of
software. Git - is as we mentioned at the beginning is the application that we download and connect to
our project that will control development by versioning each change made to the repository. GitHub, on
the other hand, is a website that acts as a vault for all open source projects to store in and records the
history of versions of your projects. In fact, the most popular version control system is Git, and the most
popular online code repository is GitHub. Git and GitHub are typically designed to communicate with
one another and are thus often used as a single framework for collaborating on a project.
15
3.3 COMPARISON OF GIT VS SUBVERSION
In this section we will compare two open source control software Git and Subversion (SVN), comparison
will be interpreted as a set of tables with technical capabilities of each VCSs as a result we will define
which of them is better according to its productivity and speed. Git was developed slightly later than
SVN and was based on a very specific project - Linux kernel development, which is carried out by a
very broad circle of developers spread across the globe. Git's architecture and implementation proved
promising to other software projects, and today, SVN and Git are likely the most common version control systems. The basic concepts of SVN and Git are quite different, and the decision about using SVN
or Git should be based on considering these differences. I will compare these two VCSs by conducting
a literature review from open source resources and creating a table of comparison.
Rating scale: Very bad; Bad; Good; Very Good; Excellent
Characteristics:
Git
Subversion
Speed
Excellent
Bad
Remote contributions(Mobility)
Excellent
Very Bad
Bad
Very Good
User Interface
Type of System
Functional capabilities (copy and transfer of the file/folders, tracking changes line by line)
Documentations
Very Good
Bad
Good
Bad
Good
Very Good
Excellent
Excellent
Good
Very Good
Command set
Excellent
Good
Popularity
Excellent
Good
Cross-platform (Windows, Linux, MacOS)
Ease of use
 Speed
According to tests performance of version control systems, Git is the fastest of them. Then comes Mercurial, followed by SVN and CVS. As well as in terms of work performance distributed version control
systems like Git simply doesn’t require to go over the network for everything.
 Mobility (remote contributions)
Git is certain winner in this because it allows user to copy a repository with all history changes to local
device and make commits from any place over the globe.
 User Interface
Subversion and Git both have command-line interfaces. In addition, web and standard graphical user
interfaces are both in high quality, either as part of the basic installation or as a separate package.
 Type of System
A distributed system, in my view, has many benefits over a centralized one. First, it does not necessitate
a continuous network connection. Second, in terms of data storage, it is more consistent and reliable. If
the data integrity on the server is violated in a centralized system, data will be lost, while in a distributed
system, users will save a local copy of the repository. Third, the ease of collaborating with several repositories in a distributed project. As a result, I give systems with this kind a higher rating.
 Functional capabilities
In functionality capabilities, I value support opportunities copying files and folders; transfer of files and
folders; tracking changes in the file line by line. SVN line by line monitors changes, and also allows you
to transfer files and folders. But, Git allows to do all three of the functions.
 Cross-platform
Cross-platform is a characteristic feature of all systems, so both gets the maximum score.
16
 Ease of use
In GIT, it's easier to switch from branch to branch, merge between them. But, one central repository in
SVN allows managers to take a more better approach to management, protection, approvals, mirrors,
and backups. Furthermore, many people believe that SVN is easier than using Git. It is, for example,
quicker to add a new functionality. It takes an extra step to add a new function to Git. Others claim that
the way SVN is configured results in greater trunk reliability, and that getting it on a centralized server
feels more managed and stable to others. In my opinion it’s more of matter of habit and depends on
which system have been used for your projects. For someone who is very new to VCSs I would recommend to use Git.
 Command set
Despite the fact that they all have decent command sets, Git goes above and beyond by providing a
rather feature rich command set.
 Documentations
I assessed the documentation from the perspective of a beginner, from perspective of someone who has
never used this system before. The simpler the approach of accessing the documentation is, and the more
understandable the language used, the better ratings the system receives. Git proved to be the friendliest
to the user. Links to documents can be found on their official websites' main pages. The report is written
in a simple and concise manner. SVN documentation is oriented toward specialists. It is difficult for
someone who lacks knowledge to comprehend them.
To conclude provided information we can observe from comparison that as a consequence, Git receives
the highest number of high points. This version control system comes highly recommended by me. However, if you have a compelling reason to use a centralized approach best decision would be to use SVN
among other CVCSs. When selecting and testing version control systems for your project, keep in mind
that the advantages of a specific solution are often subjective. Personal interests of the programmer, for
example, or factors such as performance, IDE plugin capabilities, and so on.
3.4 GITHUB
For a preset to a practical part of my thesis work, I want to provide my findings and analysis on couple
of researches that were examining GitHub as a learning management system (LMS) a collaborative and
peer to peer development tool, including instructor as a initiator and host of such classes. First, I will
give brief introduction on basic concepts of GitHub. Second, I explain why it’s the most popular open
source project hosting web-service? Along with, why do employers often ask to provide a GitHub account during the enrolling process for software engineer positions?
GitHub is open source a social media platform and management tool for your projects as well as source
code repositories that is created and designed for software developers. It helps you to communicate with
people all over the world, organize projects, and keep track of your progress.
It's completely free, and it's one of the most advanced hosting services available. Apart from personal
preference and technical specifications, there is one major reason why everyone uses GitHub, it's because of its huge number of contributors making it an excellent networking site.
You are able to host an open source projects, although many developers use GitHub to host private
repositories due to the platform's ease of use.
Now let’s get familiar with key concepts of GitHub:
 GitHub Issues
GitHub Issues is one of the most popular bug trackers in the world it provides repository owners with
the ability to organize, tag, and link issues to specific stages of development.
 Rating mechanisms (“Star” system)
To express your interest in a repository, it must be marked with a star. This can be done using the "Star"
button. This will allow you to keep track of interesting projects and find similar ones. It is also one of
the most important rating mechanisms, as the more stars a repository has, the more popular it is.
 Fork
17
Fork is a copy of the repository. This is the same as branch in Git that.
 Pull requests
A Pull Request is a request from your branch to the master branch of the original repository. As a result,
people who fund the project look at your Pull Request and makes code review. During the review process, certain items may need to be corrected, changed, or completed.
3.4.1 USING GITHUB IN CLASSROOM ENVIRONMENT.
I truly believe that the main aim of studying courses related to rapidly evolving information technologies
is to teach students not only the applicable knowledge, but also the skills of working with such technical
resources that are actively used in professional activities.
Students should feel that software development has gone beyond just a collection of source code for a
program. While working on specific assignments (for example, laboratory work or team projects). Especially, various additional tools like bug trackers, project management systems, version control systems
(VCS), and so on are used almost in every open or commercial projects in every software development
team. GitHub is a great example of one of these essential tools for programmers to be good at.
This subsection will consist of review of related literature and encapsulation of journal article, that investigates on using GitHub as an educational tool in the classroom from perspective of the students and
benefits they achieve:
“Using GitHub in the Classroom Predicts Student Learning Outcomes and Classroom Experiences:
Findings from a Survey of Students and Teachers”[Hsing, 2019]12.
First research paper is based on the idea that although GitHub is containing valuable information on how
using GitHub in the classroom affects students learning experience. Researchers studied at how students
in GitHub classrooms compared from students in non-GitHub classrooms along key factors. To make
progress in this matter, 7530 students, 300 instructors GitHub and non-GitHub classrooms were surveyed. Research questions were: “Does using (versus not using) GitHub in the classroom predict students’ learning outcomes?”; “Does using (versus not using) GitHub in the classroom predict students’
feelings of preparation for the future? Research”; “How is the implementation of GitHub in the classroom associated with students’ classroom experiences? “How does the design of implementation predict
outcomes related to classroom learning?”. As an outcome they found that only 37.2% of the students
had experience using GitHub in the classroom, and 62.8% hadn’t. Here are some main findings that were
in line with researches expectations:
 Students who used GitHub in the classroom reported they learnt more about effective teamwork
and collaboration than students who did not.
 Students who used GitHub in the classroom reported they learnt more about popular industry
tool(s) than students who did not.
 Students who used GitHub in the classroom reported they learnt more about project management
than those who did not.
And two findings that I want to emphasize are:
Students who used GitHub in the classroom felt better prepared for a future internship or job and felt
a greater sense of belonging in the classroom than those who did not.
3.4.2 IMPORTANCE OF GITHUB IN RECRUITING PROCESSES
I couldn't overlook and not note the observation from my personal experience that often recruiters who
have considered me as a prospective employer in software developer positions asked for GitHub account
URL. I find out that is a very common tendency for almost everyone I know who tried to employ in such
job positions.
A software developer's GitHub account is the clearest reflection of his or her abilities. You can demonstrate your technology stack, how well-organized your code is, and your ability to collaborate with other
programmers. Recruiters will also look at how regularly you contribute to your projects. Outstanding
Hsing C., and Gennarelli V., “Using GitHub in the Classroom Predicts Student Learning Outcomes and Classroom
Experiences,” Proceedings of the 50th ACM Technical Symposium on Computer Science Education - SIGCSE ’19, 2019,
672–78, http://dl.acm.org/citation.cfm?doid=3287324.3287460.
12
18
professionally made GitHub account can make recruiters to approach you and propose a job position.
[Hall, 2020]13.
CHAPTER 4. PRACTICAL PART
4.1 METHODOLGY
In order to determine how experienced are students in such an important collaboration software tool
such as GitHub depending on their year of studies and how beneficial it can be to excel in understanding
of version control in career life of the future developers, I have created an online research survey. The
purpose of this research is to find answers to the following research questions, by using descriptive
research methods: How students familiar with GitHub, Does they have sufficient experience using it as
LMS in the classroom?, Do they use GitHub for solo and team projects?, Were they asked to provide
recruiter with GitHub account when applying to software development job position?, and lastly, Do they
have challenges if any using Git and GitHub. I provided students of 1st, 2nd, and 3rd cycle students from
University of Information Technology and Management. The candidates are currently studying Information Technology specialty with the survey during 2nd academic term in 2021. In addition to survey, I
have created a web-application using Git to track over changes throughout development and GitHub as
a source code vault, to make my own research on case study using best practices of using version control
systems to have an experience and opinion about such SCM systems in practice.
4.2 SURVEY
I have conducted survey where 36 students answered 11 questions about GitHub web-hosting platform
experience which is always used with Git. Questionnaire was sent to undergraduate students in 1st, 2nd
and 3rd cycle of studies in IT field. While structuring my survey I wanted to focus on two important
concerns first is how experience are students in using GitHub by attending in programming classes and
second How efficiently they use GitHub for software development outside of the classes.
FINDINGS
I have pasted the results of the survey by presenting them in charts. By separating them in three different parts:
 Demographics of the survey.
 Experience in using GitHub.
 Usage of the GitHub in future career.
1. Demographics of the survey.
First part of the survey is covering demographics of the participant in order to understand, if person
is a good fit for the survey and to differentiate data for better analysis.
13
Jonathan H.: "Using Github To Land A Job - Orange Quarter", Orange Quarter, 2021 <https://orange-quarter.com/usinggithub-to-land-a-job/>
19
Fig. 5 Survey statistics. Participation of particular gender groups of respondents in the survey. Source: Own study.
More than a half of participant(61.1%) are male.16.7% are female and 22.2% prefer did not to tell.
Fig. 6 Survey statistics. Participation of particular year of study groups of respondents in the survey. Source: Own study.
Surveyed participants are almost equally divided into three part 3rd year cycle(38.9%), 1st year cycle(36.1%), and 2nd cycle(25%).
Fig. 7 Survey statistics. Participation of particular faculty groups of respondents in the survey. Source: Own study.
20
Majority of them are studying in Programming faculty(80.6%). And very low percentage of people study
Graphical Design(11.1%). The rest is Networking(8.3%).
Fig. 8 Survey statistics. Participation of particular student groups that are experienced in different programming language
of respondents in the survey. Source: Own study
Very surprisingly all participants are similar with programming languages 30.6% claim that they are
competent in 3 programming languages, other 30.6% know at least 1, and 25% have knowledge in minimum 2. And very low percentage have experienced in 4 or 5 programming languages.
2. Experience in using GitHub.
Second part of the my survey is dedicated to detect how much of the participant actually know and
used GitHub in class environment and to understand whether person have GitHub accounts, last
questions answer how experienced is participants.
Fig. 9 Survey statistics. Participation of particular student groups that had or hadn’t experience using GitHub of respondents in the survey. Source: Own study.
Interestingly almost half of the surveyed ones did had experience in using GitHub as a Collaboration
and learning tool in the class environment, and almost another hadn’t.
21
Fig. 10 Survey statistics. Participation of particular groups of students that had or hadn’t a GitHub account respondents in
the survey. Source: Own study
As expected majority(72.2%) of participant already posses GitHub account signed up and the rest still
don’t have it yet.
Fig. 11 Survey statistics. Familiarity level of particular groups of students with GitHub respondents in the survey. Source:
Own study
16.7% claim that they are very familiar and experienced, 36.1% familiar, but not experienced, 25% are
somewhat familiar, butn never used before, and 22.2% are not familiar with GitHub at all.
3. Usage of the GitHub in IT career
22
Fig. 12 Survey statistics. The experience of particular groups of students applying to IT job position respondents in the survey. Source: Own study
38.9% have been asked for a GitHub link to an account when applying to IT related job, 30.6% haven’t
got asked or haven’t yet applied for a job, and 30.6% have never applied for an IT job position.
Fig. 13 Survey statistics. The approach of particular groups of students when using GitHub respondents in the survey.
Source: Own study
We can make a conclusion by viewing charts and outline several very important statements.
1. Majority of participants 81% were students studying in Programming course in 2 and 3 year
cycles and are experienced in several programming languages.
2. 72% of surveyed students report that they have GitHub accounts, although only 17% can be
confident in using it. 25% report of somewhat experience in using it and 22% have no experience
at all.
3. 50% percent of the students have been using GitHub as a collaboration and learning tool within
a classes. Despite of the effectiveness of such method 50% have never experienced such way of
being taught or replied with open answer: “yes and only by one teacher from the whole course”,
“Yes, but not deeply”.
4. Majority of applicants 39% have been asked to share their GitHub account and only 31% have
never applied to any IT related job.
5. Very low percentage of applicants have used GitHub in developing project within a team only
2%.
23
INTERPRETATION
The outcomes show us clearly that not only students are not experienced in using one of the most important and widely used tools for collaborative development of software, but also not enough attention
was put to teach students of such methods. Of course, survey was held anonymously and not all of the
students studying in IT department in 1st 2nd 3rd year cycle took part on taking it, but even with data that
we have, in my own opinion adding Git and GitHub in the class environments of the students, using it
as a collaborative tool for closing projects and finishing assignments in teams might be a big plus for
them in the future IT career escalation. In my own experience every job position that I was applying
having GitHub account was required and not only essence of it but also important was to have few or at
least couple of self-done pet-projects. And to store and develop such projects you would need to have
certain skills in using Git and GitHub.
4.3 WEB – SITE DEVELOPMENT USING GIT AND GITHUB
My next step in practical part of my diploma thesis is to demonstrate my own analysis of source code
development process and show that development with such tools is very easy and can give a lot of useful
data to analyze the process of software development in order to increase efficiency in future projects. I
have developed a web application using Git to track the changes over the time of the development and
GitHub to store all my files and access them from every device or place wherever I want, which made
the process extremely convenient.
You can observe source code in my GitHub repository that are publicly available: GitHub Repository
https://github.com/AbdullaYerezhep/Sociate
First let me give about the project:
The goal of the projects is to create a dating web application “Sociate”, that helps people to find prospective date partners with the ability to like and chat with people.
Functional objectives
1. Users are able to create an account by registering and login into the website.
2. Users are able to edit profiles by adding information about descriptions, interests, preferences,
country, and city of residence.
3. Users are able to upload and delete account photos and see photos of users on their profile accounts, and also assign particular photo as main to be shown as an avatar of a user.
4. Users can search using a sorting filter by age.
5. Users can like profiles that seemed interested to them and in the case of mutual sympathy system
shows matched profiles
6. The system tracks the information of users' online presence and shows it on the profile page.
7. The system has a simple navigation bar to guide users around.
8. Users can chat with each other privately by creating and deleting messages.
9. The system informs a user about the possible loss of data when refreshing or leaving web pages.
10. The system has admin, moderator, and member roles.
Non-Functional Objectives
1. Performance and scalability. The system should be able to support 100+ simultaneous users. The
mean time to view a web page over a 56Kbps modem connection shall not exceed 2 seconds. Downtime after a failure shall not exceed 1 hour.
2. Reliability, availability, maintainability. The system shall be completely operational at least 80% of
the time.
24
3. Security. The system shall provide password-protected access to web pages that are to be viewed
only by employees.
4. Usability The number of web pages navigated to access data information from the top page should
not exceed 2.
Stack of technologies
For building an API I chose an Asp.Net Core Framework and for the client side I used an Angular 10
and for the database, I have used an Entity Framework Core SQLite database provider to handle all
database operation because of its ease of use and ability to make migration and create tables with data
without manually typing it, although it is for a local database and also I have a cloud database storage to
store all photos of users there, for more efficient performance. As for programming languages, they are
C#, JavaScript, Typescript, and classic markup languages HTML5 and CSS3.
This is a login page of my application where you need to provide the system with the username and
password credential and it requests API and uses JSON Web Token (JWT).
Fig. 14 Web-site screenshots. The login page. Source: Own study
Register form has blanks to full like Username, KnownAs, DateOfBirth(18+), Country and
City, Password, and Password confirmation.
25
Fig. 15 Web-site screenshots. The registration page. Source: Own study
This is a List of matches where you can see is a person online at this moment.
Fig. 16 Web-site screenshots. The matches page. Source: Own study
The list of liked persons is separated on another page.
26
Fig. 17 Web-site screenshots. The liked members page. Source: Own study
On the profile page, you can edit and change user information, the system will notify the user if added
info is saved.
Fig. 18 Web-site screenshots. The account edit page. Source: Own study
User can upload photos to his profile.
27
Fig. 19 Web-site screenshots. The photo upload page. Source: Own study
Fig. 20 Web-site screenshots. The uploaded photo page. Source: Own study
There is also the possibility to message users.
28
Fig. 21 Web-site screenshots. The matches page. Source: Own study
which is held online,
Fig. 22 Web-site screenshots. The messaging page. Source: Own study
and the user you are messaging gets a notification about it.
29
Fig. 23 Web-site screenshots. The notification about receiving message. Source: Own study
Database structure
Here is a database relation diagram of the web application. It's is shown that all the relations are built
around Users entity in the diagram.
\
Fig. 24 Web-site screenshots. The database structure logic. Source: Own study
30
To build such system I have used GIT and GitHub as source code management tools, that made my
software development much organized less unsafe to loose the progress and make mistakes throughout
the development and of course much more mobile as I could access my source code from anywhere in
the world just by having an internet connection.
GitHub Insights is a native app that generates analytic reports based on data from your GitHub Enterprise
Server instance to assist you in better understanding and improving your software delivery process. It is
a machine-based tool that connects to GitHub Enterprise. GitHub Insights provides a great track of the
development process and creates useful graphs in order to show developer the amount of progress and
the time was spent in order to create a project, how many branches and pull requests were used that can
help analyze previous work and improve future planning of the project development. In my projects I
haven’t used pull request but they are very useful in team development pull requests enables contributors
to easily notify you of modifications they've made to a repository, with access restricted to the contributors you specify. Acceptable adjustments can be easily merged.
In bigger project that need continuous delivery and continuous integration there is also solution - GitHub
Actions. With world-class CI/CD, GitHub Actions makes it simple to automate all your development
activities. Right from GitHub, you can write, test, and release your code. Make code reviews, branch
management, and issue triaging go as smoothly as possible.
In these graphs we can see my total commits number and amount of commits each day. The progress
itself is stretched out in timeline, from the start to finish of creating process of the application in a graph.
We can see that majority of the progress was done in first part of the timeline, meaning in the beginning
of the work that can be explained by the enthusiasm at the very start and straight after that drop down in
progress as I have started to face a lot of hard tines building my project, because of my lack of experience
creating relatively medium projects. But by observing these statistics I have gained valuable knowledge
and in my future projects I will plan out and distribute the work across time more or less equally to
maintain balanced development process that will cause more stable development behavior. I am thinking
of trying new features of GitHub like GitHub Issues and Product Roadmap
GitHub
31
Fig. 25 Insight statistics. The total commits number and amount of commits each day statistics. Source: Own study
Fig. 26 Insight statistics. The total commits number and amount of commits each day statistics. Source: Own study
In Network graph we can see that I have used two main branches one for the development and another
one that us above is the main branch. I have followed best practices advices and split out my development
path into two branches one for consistent development and another to save already safe and checked
commits. But projects is always improving entity and it always has space to grow to, it could be some
small bug fixes or new big features update, however in the future it’s better be done by creating additional branches for each such additional work needed to be done, as it an opportunity for you and your
team members to work specifically on some certain development path and not interfere with other ones.
32
Fig. 27 Insight statistics. The total amount of branches used while development. Source: Own study
References
1.
Zolkifli, N. N., Ngah, A. & Deraman, A. Version Control System: A Review. Procedia Comput.
Sci. 135, 408–415 (2018).
2.
Zagalsky, A., Feliciano, J., Storey, M. A., Zhao, Y. & Wang, W. The emergence of GitHub as a
collaborative platform for education. CSCW 2015 - Proc. 2015 ACM Int. Conf. Comput. Coop.
Work Soc. Comput. 1906–1917 (2015) doi:10.1145/2675133.2675284.
3.
Vuorre, M. & Curley, J. P. Curating Research Assets : A Tutorial on the Git Version Control
System. Adv. Methods Pract. Psychol. Sci. 1, (2018).
4.
Spinellis, D. Version control systems. IEEE Softw. 22, 108–109 (2005).
5.
Spandel, D., Kjellgren, J. & Johansson, C. Choosing between Git and Subversion. (2014).
6.
Sink, E. Version Control by Example. (2012).
7.
Raymond, E. Understanding Version-Control Systems ( DRAFT ) Why use version control ?
Categorizing Version-Control Systems. 1–54 (2007).
8.
Nguyen, H. Le & Ignat, C. L. An Analysis of Merge Conflicts and Resolutions in Git-Based
Open Source Projects. Comput. Support. Coop. Work CSCW An Int. J. 27, (2018).
9.
Nathan, S. Tools of the trade. Engineer 1-NOVEMBER, 108–109 (2010).
10.
Mulu, K., Bird, C., Nagappan, N. & Czerwonka, J. Transition from centralized to decentralized
version control systems: A case study on reasons, barriers, and outcomes. Proc. - Int. Conf.
Softw. Eng. 334–344 (2014) doi:10.1145/2568225.2568284.
11.
Malmsten, C. F. Evolution of Version Control Systems. Comparing CENTRALIZED against
DISTRIBUTED Version Control models (2010).
12.
Koc, A. A Survey of Version Control Systems.
33
13.
Hsing, C. & Gennarelli, V. Using GitHub in the Classroom Predicts Student Learning Outcomes
and Classroom Experiences. Proc. 50th ACM Tech. Symp. Comput. Sci. Educ. - SIGCSE ’19
672–678 (2019).
14.
Gunnarsson, S. ;, Larsson, P. ;, Månsson, S. ;, Mårtensson, E. ; & Sönnerup, J. Enhancing Student Engagement Using GitHub as an Educational Tool. Genombrottet, Lunds tekniska högskola. (2017).
15.
Guerrero-Higueras, ángel M. et al. Academic success assessment through version control systems. Appl. Sci. 10, (2020).
16.
Gousios, G., Vasilescu, B., Serebrenik, A. & Zaidman, A. Lean ghtorrent: GitHub data on demand. 11th Work. Conf. Min. Softw. Repos. MSR 2014 - Proc. 384–387 (2014)
doi:10.1145/2597073.2597126.
17.
Glazunova, O. G., Parhomenko, O. V, Korolchuk, V. I. & Voloshyna, T. V. The effectiveness of
GitHub cloud services for implementing a programming training project: students’ point of
view. J. Phys. Conf. Ser. 1840, 012030 (2021).
18.
Feliciano, J., Storey, M. A. & Zagalsky, A. Student experiences using GitHub in software engineering courses: A case study. Proc. - Int. Conf. Softw. Eng. 422–431 (2016)
doi:10.1145/2889160.2889195.
19.
Deepa, N., Prabadevi, B., Krithika, L. B. & Deepa, B. An analysis on Version Control Systems.
Int. Conf. Emerg. Trends Inf. Technol. Eng. ic-ETITE 2020 (2020) doi:10.1109/icETITE47903.2020.39.
20.
De Alwis, B. & Sillito, J. Why are software projects moving from centralized to decentralized
version control systems? Proc. 2009 ICSE Work. Coop. Hum. Asp. Softw. Eng. CHASE 2009
36–39 (2009) doi:10.1109/CHASE.2009.5071408.
21.
Cochez, M., Isomöttönen, V., Tirronen, V. & Itkonen, J. The use of distributed version control
systems in advanced programming courses. CEUR Workshop Proc. 1000, 221–235 (2013).
22.
Chacon, S. & Straub, B. Pro Git. Pro Git (2014). doi:10.1007/978-1-4842-0076-6.
23.
Brindescu, C., Codoban, M., Shmarkatiuk, S. & Dig, D. How do centralized and distributed version control systems impact software changes? Proc. - Int. Conf. Softw. Eng. 322–333 (2014)
doi:10.1145/2568225.2568322.
24.
Ball, T., Kim, J.-M. & Siy, H. P. If your version control system could talk. ICSE Work. Process
Model. Empir. Stud. Softw. Eng. (1997).
25.
Alnor, N. & Khleel, A. Comparison of version control system tools. (University of Miskolc,
2020). doi:10.35925/j.multi.2020.3.7.
26.
Sapolsky J. :The Joel Test: 12 Steps to Better Code
ware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ of 09.08.2000
https://www.joelonsoft-
27.
Miller
M.:
Professional
Software
Development
https://mixmastamyk.bitbucket.io/pro_soft_dev/index.html#professional-software-development of 31.03.2021
34
28.
Collins-Sussman B., Fitzpatrick B., and Pilato C.: Version Control with Subversion, California
94305, USA 2004.
29.
Lionetti. G: What is version control: centralized vs. DVCS https://www.atlassian.com/blog/software-teams/version-control-centralized-dvcs of 14.02.2012
30.
Chacon S, Straub B. Pro git: Everything you need to know about Git. Second. Apress; 2014.
https://git-scm.com/book/en/v2.
CHAPTER 5. CONCLUSION
The University of Information Technology and Management in Rzeszów
Faculty of Applied Information Technology
Diploma Thesis Summary
Thesis title in English
Author: Abdulla Yerezhep
Supervisor: dr. inż. Barbara Fryc
Keywords: Version Control Version(VCS), Distributed Version Control System(DVCS), Centralized Version Control
System(CVCS), Git, GitHub.
I have made huge work of researching the world of version control system (VCS) the main idea of this thesis paper was to
demonstrate one of the best creations in the development management, the system that can ease the hard work of developers
and team of developers from having issues with progress version track, source code hosting, team administration, and project
management.
To fully understand the topic, I am trying to study I have started out from the very beginning and research the roots of VCS
by diving into history of creation, and found out two main types of it that are CVCS and DVCS, then continued my journey
by outlining the different generations of VCS and how they evolved through time. After all, I noted that nowadays DVCS
are much more in demand by also proving my point referencing to couple of research papers that I found in open access in
the internet. Then continued my journey by outlining the different generations of VCS and how they evolved through time.
My third chapter was dedicated to show software that is used throughout the world, by choosing two most used VCS according to Openhub.net. (n.d.). Open Hub, the open source network. http://www.openhub.net/. That are Subversion and Git we
stopped and described both of them in details and showed all differentiating aspects for both as they have completely opposite
approaches to source code management which makes them uniquely good and bad for each individual situation. By the result
of my comparison of these two systems I found out that for most development teams and enterprises better is still Git with
it’s distributed system that has huge advantage over Subversion, as well as few other solutions like snapshots and pull request
which puts Git above it’s opponent and I haven’t found any examples from functional aspects that Subversion makes better
than Git, although many individuals will choose dispersed repositories because of the apparent advantages of performance
and multiple versions, there are times when a central repository is preferable. For example, if you have any sensitive code
that you don't really want others to see, you shouldn't place it all under Git.
35
Now the practical part which I have divided in to two pieces, first one is my own attempt to host a descriptive research by
providing student in the university that I am studying myself with the survey that I have constructed in order to identify the
level of the awareness in VCS’s like Git, although the results that I have received objectively are not very accurate because
of the audience that participated in survey were chosen from broad spectrum of participants and it wasn’t truly narrowed as
it could’ve been if I would choose specific faculty and year of the students, although survey was my very first try in this kind
of research method I made several few statements that I found are the most important and interesting ones that we can take
out from this survey: Majority of surveyed were not fully experienced or engaged in using Git; Although students having
major in programming faculty and are in 3rd year cycle have had classes related to using Git as source code management and
are the most experience group amongst others, not a lot of them really invest in building a GitHub portfolio that is very crucial
in job application processes. Hence in my opinion it’s to convey such idea that developing skills in source code management
and knowing the tools for its very profitable for future developers. In my next researches on this topic I would find very
interesting to provide a particular group of people like a class that take one course within educational system and take a
survey before a course and after to track the progress of the students in particular service tool. Also interview the instructor/lecturer with questions related to his methods and opinion as well as in before and after form.
My second part of the practical part is my own analysis of the project development which helped me to detect the mistakes I
have made in my planning of the development process and opened me new opportunities to extend my GitHub account value,
that can in perspective land me in job that would be interested in technologies and experience I gained from this project. I
will monitor changes in GitHub new solution in the future.
36
37