Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
Why use GIT?
Transcript of Why use GIT?
3 basic goals A top of the HILL Comparison
CVS & GIT Matrix Partners preso! Harvard Business Review How to lower the cost of enterprise sales? GIT Time & Network Bandwidth And why it happened?
CVS sucks at branching
Every cvs command goes to network, NOTHING is LOCAL = You'll create a new sandbox
checkout the whole repository Let's see what
this GIT can do? V C S Why use xxx THIS IS FOR YOU IF you-
wished if CVS was smart
messed up a CVS repo before and spent long hours fixing it
hate to wait for cvs update, log or even a diff No GIT for me GIT CVS We can shift to GIT completely to make our life happy :)
Meanwhile, use git locally and keep CVS as it is. Solution! Conclusion CVS/GIT whatever they
are, their JOB is to
help teams work in an efficient manner.
Make your own choices :) The Cost to Acquire a Customer (CAC) exceeds the Life Time Value (LTV) a customer brings us. This is my third go-around selling to large enterprises, SkyStream, Kontiki and now Qumu.
I like to explain to you the problem the way I see it, the changes I suggest to avoid making the same mistake again. and Travels to Clients And let's code happily :) Well, A lot of developers
have become used-to with
CVS and might not feel the
need to shift.
Trust me, you'll be happy. Jatin Ganhotra
_ _ _ _ _ _ _ SO, you want to work on a new feature A version control system is a piece of software that helps the developers on a software team work together and also archives a complete history of their work.
We want people to be able to work simultaneously, not serially.
Think of your team as a multi-threaded piece of software with each developer running in his own thread.
The key to high performance in a multi-threaded system is to maximize concurrency.
Our goal is to never have a thread which is blocked on some other thread.
When people are working at the same time, we want their changes to not conflict with each other.
Multi-threaded programming requires great care on the part of the developer and special features such as critical sections and locks.
Without these kinds of things, the threads would overwrite each other’s data.
A multi-threaded software team needs things too, so that developers can work without messing each other up.
That is what the version control system provides.
We want to archive every version of everything that has ever existed — ever. The 40 year history of version control tools shows a steady movement toward more concurrency.
In first generation tools, concurrent development was handled solely with locks. Only one person could be working on a file at a time.
The second generation tools are a fair bit more permissive about simultaneous modifications, with one notable restriction. Users must merge the current revisions into their work before they are allowed to commit.
The third generation tools allow merge and commit to be separated.
The world of version control is in a time of transition. The vast majority of professional programmers are using second generation tools but the third generation is growing very quickly in popularity. History of Version Control
Written in a collection of Perl, C, and various shell scripts, designed and created by Linus Torvalds
based on the needs of the Linux kernel project; decentralized, and aims to be fast, flexible, and robust
Linus Benedict Torvalds is a Finnish American software engineer and hacker,
the principal force behind the development of the Linux kernel
the chief architect later
and now acts as the project's coordinator.
Maintained by Junio Hamano (a Japanese American software engineer and hacker).
He lives in California and works for Google
each developer works directly with his or her own local repository, and changes are shared between repositories as a separate step. History of GIT Wiki - Comparison Tags are just human readable shortcuts for hashes
Branches can be made from any commit
git tag <tag-name> Git and Tagging A “ working tree” has a “ .git” directory at the top level
Unlike CVS, SVN: No Pollution of deeper directories
The .git dir contains:
Config – Configuration file (.ini style)
Objects – The object repository
Refs/heads/* - branches like “master”
Refs.tags/* - tags
Logs – logs
Refs/remotes/* - tracking others
Index – The index cache
HEAD – points to one of the branches (the current branch where commits go) Mapping objects to a file tree Create convention to define default server
Developers clone from central server
Lots of tools for transmitting patches between developers
GIT is used by:
Qt, KDE, Android, eclipse, and many more Git for Software Versioning git fsck
Checks object database to make sure all is sane
Can show information about dangling objects
Cleans up repository and compress files
When used with --prune, cleans out dangling blobs
Can really speed up larger repositories Cleaning Up git checkout -b branch
Lists all local branches available
We can now make changes in one branch and propagate change using
git cherry-pick Using Branches Git branching is lightweight
No massive copying a la CVS/Subversion
Tools for helping merge branches and changes easily
You are ALWAYS on a branch
Branches can be local or remote
Allows you to choose specific commits to apply
You can edit the commits while cherry picking Branching git checkout
Used to checkout a specific version/branch of the tree
Moves the tree back to a certain specified version
Use the --force to ignore working changes
Reverts a commit
Does not delete the commit object, just applies a patch
Reverts can themselves be reverted!
Git never deletes a commit object
It is very hard to shoot yourself in the foot! Undoing What is Done git diff HEAD^^
Show what has changed in last two commits
git diff HEAD~10..HEAD~2
Show what changed between 10 commits ago and two commits ago
git format-patch HEAD^^..HEAD
Will create individual patch files per commit
Can also compare
Between specific objects
To branches/tags Git and Patch files echo “I love Git” >> hello.txt
Shows changes we have made
Shows list of modified files
git add hello.txt
git diff HEAD
See the changes in working version
git commit -m ‘Second commit’ Working With Git ~/.gitconfig
In top level of repository
Contains all objects, commits, configuration, for project
.git/config has project specific configurations
Stored in directory for ignoring Key Git Files/Directories mkdir first-git-repo && cd first-git-repo
Creates the basic artifacts in the .git directory
echo “Hello World” > hello.txt
git add .
Adds content to the index
Index reflects the working version
Must be run prior to a commit
git commit -a -m ‘Check in number one’ Our First Git Repository Index
Stores information about current working directory and changes made to it
Every object has a SHA1 to uniquely identify it (SHA1 is KING)
“ objects“ consist of:
Stored in .git/objects
Indexed by unique hash
All files are stored as blobs
Directories of blobs or other trees
Plus zero or more parent commits
Plus a message about why
One object for every commit
Contains hash of parent, name of author, time of commit,
and hash of the current tree
An object (usually a commit)
Plus a subject
Plus an optional payload to sign it off
Plus an optional gpg signature Git Architecture Speed
Very fast operations compared to other VCS (e.g CVS and Subversion)
Compression can be done across repository not just per file
Minimizes local size as well as push/pull data transfers
Object model is very simple
Large userbase with robust tools Git Advantages Traditional version control system
Server with database
Clients have a working version
Client/server communication Centralized Version Control The Old School Way… Let’s DIVE into GIT For Windows
Github for Windows, GIT Extensions, git-cola
Github for MAC, GITX, SourceTree, git-cola
ALL These are FREE GIT GUI clients bash/zsh completion
Gitk and many others
GUI to review changes
Used for starting HTTP process for browing project Some Git Coolness Example: Apache configurations
Multiple environments (dev/test/production)
Minor differences between environments
Want to effectively move changes across environments Git for Configuration Management Protocols
Git protocol Use git clone to replicate repository
Get changes with
git fetch (fetches and merges)
Propagate changes with
git push Using Remote git log
Note the hash code for each commit.
git show <OBJECT>
Can use full or shortened hash Viewing What Has Changed Getting information
git show Getting a Repository
git commit Some Commands Other distributed systems include
Every working checkout is a repository
Get version control even when detached
Backups are trivial Distributed Version Control Say, you checked in around 10 files, and now you need to revert the change Time & Network Bandwidth You'll individually revert all the files, or do revert by date :( And why it happened?
CVS doesn't track/group content in a commit
CVS is file based = xxx CVS protocol does not allow to remove directories.
You go to the server console and remove them from the real physical repository. = xxx CVS has issues with Renaming files = xxx