Here I will discuss on distributed version control system and how it is better then centralize version control system. I will demonstrate some basic terminology of GIT as well.
3. Verson Control System
l
Version control is like Wikipedia. You check it for
l
What changes people has made.
l
Inspect these changes
l
Contribute your own.
5. Brief History : VCS
Revision Control System : This was the first version control
system , Introduced in early 1980's. A directory of source code
could contains many RCS repositories. Each repository
concerning itself with a single file.
Concurrent Versioned System. : It allowed multiple users to
contribute on a project. It is collection of multiple RCV repository
with network awareness. Dealing with directories was still very
difficult and different then Unix file system.
SubVersion (SVN) : It improved CVS by providing better solution
for directory , history , deletion management.
6. Centralized VCS
“Centralized version control systems are based on the
idea that there is a single “central” copy of your project
somewhere (probably on a server), and programmers will
“commit” their changes to this central copy.”
9. Distributed VCS
“distributed revision control system (DVCS) keeps track
of software revisions and allows many developers to
work on a given project without requiring that they
maintain a connection to a common network. It believes
in Peer to Peer approach”
10. Brief Introduction : GIT
Git is one of the most popular DVCS.
Git was initially designed and developed by Linus Torvalds for
Linux Kernel development in 2005.
Every Git working directory is a full-fledged repository with
complete history and full version tracking capabilities, not
dependent on network access or a central server.
Git is a free software distributed under the term of GNU
General Public License version 2.
16. Terminology............
Reset : If you have committed junk but not pushed.
$ get reset –hard
reset --hard wipe out all the work and move the head to last
commit. Thus any changes to tracked files in the working tree
since the commit before head are lost.
reset --soft moves the head to specific commit but do not
discard the changes. It will leave all your changed files
"Changes to be committed", as git status would put it.
17. Terminology............
Reset : If you have committed junk but not pushed.
$ get reset –hard
reset --hard wipe out all the work and move the head to last
commit. Thus any changes to tracked files in the working tree
since the commit before head are lost.
reset --soft moves the head to specific commit but do not
discard the changes. It will leave all your changed files
"Changes to be committed", as git status would put it.
18. Terminology............
checkout : If you want to switch to old state briefly.
$ git checkout 7554b6
This takes you back in time, while preserving newer commits.
However, like time travel in a science-fiction movie, if you now edit
and commit, you will be in an alternate reality, because your actions
are different to what they were the first time around.
19. Terminology............
l
$git revert HEAD
revert : If you have committed the just and pushed it as well. This will
create a new commit that reverses everything introduced by the
accidental commit.
20. Terminology............
$ git rebase -i HEAD~10
Remove commits by deleting lines. Like the revert command, but off
the record: it will be as if the commit never existed.
Reorder commits by reordering lines.
Replace pick with:
edit to mark a commit for amending.
reword to change the log message.
squash to merge a commit with the previous one.
fixup to merge a commit with the previous one and discard the log
message
28. Branching
Creating a branch
$ git branch <branch-name>
Creating a new branch from parent ( commit , branch or tag) and switch
to newly created branch
$ git checkout -b <branch-name> <parent>