SPMQA

20BCM018 DHRUVIL RAVAL

PERFORM SOFTWARE PROJECT MANAGEMENT &

DEVELOPMENT USING ZEPEL/GITHUB/KANBANIZE/MS PROJECT OR ANY
SIMILAR TOOL. (ANY TWO)
 CONFIGURATION MANAGEMENT IN GITHUB
The need?

First lets understand the definition given by Wikipedia-In software engineering, software configuration
management is the task of tracking and controlling changes in the software.

Now lets break out the definition into pieces and let me explain in my words -Software Developers do not
work on computers that are crash proof(Because such computers are too expensive to provide).Imagine
software developers writing pages of codes or making some documentation about a deliverable and the
computer crashes. Or lets imagine making multiple ctrl+z key presses just to back to a state you
previously liked or was correct. Imagine saving multiple copies of same document with different changes
in text files. Tedious Right??
Enter Github Configuration Management. Now its clear why we need configuration management as we
are ultimately humans and humans make mistakes and we would like to roll back to at some point in our
code.
Software Developers never make big changes in their software and go without making a
copy of previous versions as this might prove to be dangerous if new version has errors.
Github makes it easy to record and compare different file versions. This means that the
details about what changed, who changed what, or who initiated an issue are
reviewable anytime. A Version Control System (VCS) refers to the method used to save a
file's versions for future reference.

Intuitively, many people already version control their projects by renaming different
versions of the same file in various ways
like blogScript.js, blogScript_v2.js, blogScript_v3.js, blogScript_final.js, blogScript_defini
te_final.js, and so on. But this approach is error-prone and ineffective for team projects.
Also, tracking what changed, who changed it, and why it was changed is a tedious
endeavor with this traditional approach.
This illuminates the importance of a reliable and collaborative version control system like Git.

The GitHub workflow can be summarised by the “commit-pull-push” mantra.

1.Commit
1. Once you’ve saved your files, you need to commit them - this means the changes you have
made to files in your repo will be saved as a version of the repo, and your changes are now
ready to go up on GitHub (the online copy of the repository).
2.Pull
1. Now, before you send your changes to Github, you need to pull, i.e. make sure you are
completely up to date with the latest version of the online version of the files - other
people could have been working on them even if you haven’t. You should always pull
before you start editing and before you push.
3.Push
1. Once you are up to date, you can push your changes - at this point in time your local copy
and the online copy of the files will be the same.
Initial Setup
COMMIT TO MAIN
CREATE TXT FILE
Commit to main
CREATING BRANCH AND MERGING TO MAIN
PUBLISHING AND PUSHING CHANGES TO GITHUB ONLINE
UNDO COMMIT
PULLING REQUEST