Git is a distributed revision control system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005, and has since become the most widely adopted version control system for software development.
As with most other distributed revision control systems, and unlike most client–server systems, every Git working directory is a full-fledged repository with complete history and full version-tracking capabilities, independent of network access or a central server. Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2. [Wikipedia]
Centralized vs. Distributed (in images)
Understand local vs. remote
Git has local and remote commands; seeing both confused me (“When do you checkout vs. pull?”). Work locally, syncing remotely as needed.
Local data
git init
create local repo
use git add/commit/branch to work locally
· Getting the change into a repo (pushing or pulling)
· Applying the change to the files (update or merge)
o Updates happen when there’s no ambiguity. For example, I pull changes to a file that only you’ve been editing. The file just jumps to the latest revision, since there’s no overlapping changes.
o Merges are needed when we have conflicting changes. If we both edit a file, we end up with two “branches” (i.e. alternate universes). One world has my changes, the other world has yours. In this case we (probably) want to merge the changes together into a single universe.
· Saving the new version (commit)
Remote data
git remote add name path-to-repo
track a remote repo (usually “origin”) from an existing repo
remote branches are “origin/master”, “origin/dev” etc.
git branch -a
list all branches (remote and local)
git clone path-to-repo
create a new local git repo copied from a remote one
local master tracks remote master
git pull
merge changes from tracked remote branch (if in dev, pull from origin/dev)
git push
send changes to tracked remote branch (if in dev, push to origin/dev)
* Tag releases with meaningful names.
Why local and remote? Subversion has central checkins, so you avoid committing unfinished work. With git, local commits are frequent and you only push when ready.
Full list of commands
http://jonas.nitro.dk/git/quick-reference.html
Semantic Versioning 2.0.0