Git

Source Control.
Git Introduction
IT Academy
01/22/2015

Agenda
▪Source Control Tools
– File Server, CVS, VSS, TFS, Perforce, Git, etc.
▪Source Management Models
▪Git. Introduction
▪Case studies

History. File Server
▪ File server is a computer attached to a network that has the
primary purpose of providing a location for shared disk access,
i.e. shared storage of computer files (such as documents,
sound files, photographs, movies, images, etc.)

CVS
▪ The Concurrent Versions System (CVS), also known as the
Concurrent Versioning System, is a free software revision
(GNU GPL) control system in the field of software
development.
▪ Version control system software keeps track of all work and all
changes in a set of files, and allows several developers
(potentially widely separated in space and/or time) to
collaborate.
▪ Dick Grune developed CVS as a series of shell scripts in July
1986.
▪ CVS uses a client–server architecture: a server stores the
current version(s) of a project and its history.
▪ Now active system engineering is stopped (in May, 2008).

VSS
▪ Microsoft Visual SourceSafe (Visual SourceSafe, VSS) – is a
source control software package oriented towards small
software development projects.
▪ Like most source control systems, SourceSafe creates a virtual
library of computer files.
▪ While most commonly used for source code, SourceSafe can
actually handle any type of file in its database, but prior
versions have been shown to be unstable when confronted
with large amounts of non-textual data (images, binary
executables, etc).
▪ Now is stopped. Extended support ending on 12 April 2016.

TFS
▪ Microsoft introduced a source control and project lifecycle
management product called Team Foundation Server, which
is part of Visual Studio Team System. This product addresses
many of Visual SourceSafe's shortcomings, making it suitable
for larger teams requiring high levels of stability and control
over activities.
▪ Microsoft SharePoint Foundation (WSS) is a free add-on to
Microsoft Windows Server 2003 and 2008 providing a web
portal with commonly needed features. Microsoft SharePoint
Foundation gives a base infrastructure for teamwork: editing,
storage of documents, control of versions and etc.; includes
routes of movement of documents, lists of tasks, reminders.

SVN
▪ Apache Subversion (name SVN) is a revision control system
founded and sponsored in 2000 by CollabNet Inc.
▪ Developers use Subversion to maintain current and historical
versions of files such as source code, web pages, and
documentation.
▪ Its goal is to replace widespread system Concurrent Versions
System (CVS), considered become outdated and to be a
mostly-compatible successor.
– TortoiseSVN – client Subversion, implemented as an
extension of the Windows explorer.
– RabbitVCS – client Subversion, implemented as an
extension for the file manager for Linux.
– Subclipse – plugin for Eclipse.

History. Git
▪ Git is a distributed revision control and source code
management (SCM) system

Repository
▪ Repository is a kind of file server, but it's not your usual
breed.
▪ What makes the repository special is that it remembers every
change ever written to it: every change to every file, and even
changes to the directory tree itself, such as the addition,
deletion, and rearrangement of files and directories.
▪ When a client reads data from the repository, it normally sees
only the latest version of the filesystem tree.
▪ But the client also has the ability to view previous states of the
filesystem.

Problem of File-Sharing
▪ All version control systems have to solve the same
fundamental problem: how will the system allow users to
share information, but prevent them from accidentally
stepping on each other's feet?
▪ It's all too easy for users to accidentally overwrite each other's
changes in the repository.

Problem of File-Sharing
▪ Suppose we have two co-workers, Harry and Sally. They each
decide to edit the same repository file at the same time.
▪ If Harry saves his changes to the repository first, then it's
possible that (a few moments later) Sally could accidentally
overwrite them with her own new version of the file. While
Harry's version of the file won't be lost forever (because the
system remembers every change), any changes Harry made
won't be present in Sally's newer version of the file, because
she never saw Harry's changes to begin with.
▪ Harry's work is still effectively lost – or at least missing from
the latest version of the file – and probably by accident. This is
definitely a situation we want to avoid!

Lock-Modify-Unlock Solution
▪ Many version control systems use a lock-modify-unlock model
to address the problem of many authors clobbering each
other's work. In this model, the repository allows only one
person to change a file at a time.
▪ This exclusivity policy is managed using locks. Harry must
“lock” a file before he can begin making changes to it. If Harry
has locked a file, then Sally cannot also lock it, and therefore
cannot make any changes to that file. All she can do is read
the file, and wait for Harry to finish his changes and release his
lock.
▪ After Harry unlocks the file, Sally can take her turn by locking
and editing the file.

▪ The problem with the lock-modify-unlock model is that it's a
bit restrictive, and often becomes a roadblock for users.
▪ Locking may cause administrative problems. Sometimes Harry
will lock a file and then forget about it. Meanwhile, because
Sally is still waiting to edit the file, her hands are tied.
▪ And then Harry goes on vacation. Now Sally has to get an
administrator to release Harry's lock.
▪ The situation ends up causing a lot of unnecessary delay and
wasted time.

▪ Locking may cause unnecessary serialization. What if Harry is
editing the beginning of a text file, and Sally simply wants to
edit the end of the same file? These changes don't overlap at
all.
▪ Locking may create a false sense of security. Suppose Harry
locks and edits file A, while Sally simultaneously locks and
edits file B.
▪ But what if A and B depend on one another, and the changes
made to each are semantically incompatible? Suddenly A and
B don't work together anymore.

Copy-Modify-Merge Solution
▪ Subversion, CVS, and many other version control systems use
a copy-modify-merge model as an alternative to locking.
▪ In this model, each user's client contacts the project repository
and creates a personal working copy – a local reflection of the
repository's files and directories.
▪ Users then work simultaneously and independently, modifying
their private copies.
▪ Finally, the private copies are merged together into a new,
final version.
▪ The version control system often assists with the merging, but
ultimately a human being is responsible for making it happen
correctly.

▪ Say that Harry and Sally each create working copies of the
same project, copied from the repository. They work
concurrently, and make changes to the same file A within
their copies.
▪ Sally saves her changes to the repository first. When Harry
attempts to save his changes later, the repository informs him
that his file A is out-of-date.
▪ In other words, that file A in the repository has somehow
changed since he last copied it. So Harry asks his client to
merge any new changes from the repository into his working
copy of file A.
▪ Chances are that Sally's changes don't overlap with his own; so
once he has both sets of changes integrated, he saves his
working copy back to the repository.

▪ But what if Sally's changes do overlap with Harry's changes?
This situation is called a conflict, and it's usually not much of a
problem.
▪ When Harry asks his client to merge the latest repository
changes into his working copy, his copy of file A is somehow
flagged as being in a state of conflict: he'll be able to see both
sets of conflicting changes, and manually choose between
them.
▪ Note that software can't automatically resolve conflicts; only
humans are capable of understanding and making the
necessary intelligent choices.
▪ Once Harry has manually resolved the overlapping changes –
perhaps after a discussion with Sally – he can safely save the
merged file back to the repository

▪ The copy-modify-merge model may sound a bit chaotic, but in
practice, it runs extremely smoothly. Users can work in
parallel, never waiting for one another.
▪ When they work on the same files, it turns out that most of
their concurrent changes don't overlap at all; conflicts are
infrequent. And the amount of time it takes to resolve conflicts
is usually far less than the time lost by a locking system.
▪ When users communicate poorly, both syntactic and
semantic conflicts increase. No system can force users to
communicate perfectly, and no system can detect semantic
conflicts.

Locking
▪ While the lock-modify-unlock model is considered generally
harmful to collaboration, there are still times when locking is
appropriate.
▪ The copy-modify-merge model is based on the assumption
that files are contextually mergeable: that is, that the majority
of the files in the repository are line-based text files (such as
program source code).
▪ But for files with binary formats, such as artwork or sound,
it's often impossible to merge conflicting changes. In these
situations, it really is necessary to users to take strict turns
when changing the file.

Git. Client
▪ http://git-scm.com/downloads

Git. Client
▪ http://msysgit.github.io/

Git. Create Repository
▪ Signing up for a new GitHub account
https://github.com/signup/free
▪ Create Repository, and Run Git Bash (or cmd)

Git. Create Repository
▪ Add .gitignore: Java

Register
▪ Register your name and e-mail in git
$ git config --global user.name
"<desired name to be seen as author of code>"
$ git config --global user.email "<desired
e-mail to be seen as authors of code>"
▪ List all variables set in config file
$ git config -l [--global]
$ git help config
▪ Clone repository via supplied path
$ git clone "<path>"

Git. Clone
▪ Run cmd
C:...User>cd workspace
▪ Clone repository
$ git clone
https://github.com/lv136/atqc.git

Git. Clone
▪ Create (copy) maven project
▪ Import to Eclipse

Git. Remote Repository
▪ Displaying remote repositories (with URL)
$ cd atqc136
$ git remote
$ git remote -v
▪ Adding a remote repository
$ git remote add [nickname] [url]
$ git remote add ivan
git://github.com/../other.git
▪ Use nickname instead of the full URL
$ git fetch ivan

Git. Remote Repository
▪ Get data (branch) from remote projects
$ git fetch [servername]
▪ Branches can be viewed or merged (manual).
▪ Gets (fetch) data and automatically to merge with the code
(master)
$ git pull
▪ Send (push) to the main repository
$ git push [servername] [branches]
▪ Send master branch on the origin server (auto if clone)
$ git push origin master

Git. Ignoring. File .gitignore
▪ Empty lines and beginning with # are ignored
▪ Standard glob patterns
▪ End patterns with a forward slash "/" for directory
▪ Invert the template using !
*.[oa]
▪ Ignore all files in the directory target/
target/
▪ Ignore the .classpath file in the root directory
/.classpath
▪ ignore doc/notes.txt, but not doc/info/arch.txt
doc/*.txt
▪ ignore all .txt files in the directory doc/
doc/**/*.txt

Git. Ignoring. File .gitignore
C:UsersUserworkspaceatqc136>git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
modified: .gitignore
Untracked files:
pom.xml
src/

Git. Status of Files
▪ Create new file README
$ git status
▪ Tracking the file README
$ git add README
$ git status
▪ Edit file README and run $ git status
▪ README listed as both staged and unstaged
▪ Use $ git add README and run $ git status

Git. Compare Content
▪ What changed: compares the contents of the directory with
the contents of the index
$ git diff
▪ That will go down in the next commit (Git Bash only)
$ git diff ––cached
$ git diff ––staged
▪ Committing changes
$ git commit
▪ Command will open a text editor $EDITOR

Git. Formatting Commits
▪ Set variable
$ set GIT_EDITOR=notepad
$ git config --global core.editor "notepad"
▪ Add all
$ git add .
$ git add myfile.txt myotherfile.txt
$ git add "**.txt"
$ git status
$ git commit -m "My first commit!"
$ git commit
$ git commit -am "Add all files and commit.
I live on the edge"

Git. Delete
▪ Deleting files and add to index
$ rm README
$ git status
$ git rm
$ git status
▪ Delete file from index (leaving in the directory)
$ git rm ––cached README
▪ Moving Files
$ git mv file_from file_to

Git. History Commit
▪ View commit history
$ git log
▪ Parameter -p shows the difference and output last 2 records
$ git log -p -2
▪ List of commits in the last two weeks
$ git log --since=2.weeks
▪ Cancel changes
$ git commit -m "initial commit"
$ git add forgotten_file
$ git commit ––amend [-m "message"]
▪ Second commit replaces the results of the first

Git. Changes
▪ Cancel indexing file
$ git status
$ git reset HEAD README
▪ Undo Changes file (merge, conflict)
$ git checkout -- README
▪ Get more information about one of the remote repository
$ git remote show origin

Git. Branches
▪ Create a new branch
$ git branch testing
▪ Switched to branch (-b create)
$ git checkout testing
$ git checkout –b testing

Git. Merge
▪ We’ve been working hard on that testing branch.
▪ After another commit, it’s looking so sweet we’ve decided it’s
good enough to join the master branch.
$ git checkout master
$ git merge testing
▪ If you haven’t merged a branch, Git won’t let you delete it with
this command
$ git branch -d testing
▪ Files have not been merging $ git status

Git. Conflict
<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
please contact us at support@github.com
</div>
>>>>>>> iss53:index.html
▪ Delete Rows <<<<<<< ======= >>>>>>>
▪ Run $ git add for each conflicted file.

Git. Back Changes
▪ Cancel last commit
$ git reset --soft HEAD
▪ Delete last commit (change workspace)
$ git reset --hard HEAD
▪ Delete from server
$ git revert <commit-sha1>
▪ Back Changes
$ git log
commit 82f5ea346a2e651544956a8653c0f58dc151275c
$ git checkout 82f5

Git
Command syntax Description
repo init initializes a new client
repo sync syncs client to repositories
repo start starts a new branch
git add stages files ( adds to index )
repo status shows status of current branch
git commit commits staged files
git branch shows current branches
git branch [branch] creates new topic branch
git checkout [branch] switches HEAD to specified branch
git merge [branch] merges [branch] with current branch
git diff shows diff of unstaged changes
git log shows history on current branch
repo upload Uploads changes to review server

References
▪ Visual Git Reference
http://marklodato.github.io/visual-git-guide/index-en.html
▪ Everyday GIT Commands
https://www.kernel.org/pub/software/scm/git/docs/everyday.htm
▪ Easy Version Control with Git
http://code.tutsplus.com/tutorials/easy-version-control-with-git--

Git

More Related Content

Viewers also liked (17)

Similar to Git (20)

Recently uploaded (20)

Git