* democratized Version Control Systems (dVCS) Sharing complete repositories is a simple concept which poses subtle constraints in whose solution yields a form of democratized version control. * A look back at SVN ** Linear history is normal, all graphs are trees In other words, any given commit can have many children, but only one parent. ** Merging is painful and error prone Most solutions to this problem involve writing appropriate commit logs or writing out to files so merges can be traced. Screwing this up can be bad, and as a result it is avoided as much as possible. ** Sharing changes consists of mailing patches Obviously this was all workable, but it didn't exactly engender itself to lazy people like myself. The existance and popularity of CVSup in spite of being written in Modula 3 shows the value of repository sharing. * Constraints ** Repositories are collections of interwoven histories So: *** Linear history is a thing of the past *** Merging must be easy *** Sharing changes must be easy * How git satisfies dVCS constraints ** History is no longer linear Time is no longer a useful identifier when comparing the history of disparate repositories, and thus can't be used for commit identifiers. ** git uses SHA hashes to identify repository objects SHA is a critical factor in determining correct sharing of file data. The hash is computed from file contents and mapped to file names. ** Merging is elevated to a first class operation Git makes merging easy(ier). It will probably never be trivial, but git at least automates the grunt work of tracking down common ancestors to reduce conflicts and ease merging. ** Branching is trivial and encouraged Creating a branch is just creating another ref pointing to an existing commit. It's very fast and efficient. It's very easy to move things between branches, and they are encouraged for any non-trivial work. It doesn't even mess up your history graph a lot of the time, and when it does you can often alter it so it does not. *** What is the object store? **** blobs Blobs are blobs of binary data. **** trees Trees point to blobs or other trees. **** commits Git commits contain a tree, its parent commits, and a tree object, along with meta-data: message, author, commiter, and so forth. **** tags Tag objects contain a commit id and an optional message and cryptographic signature. If neither are present, a tag is merely a symbolic ref. *** All objects are identified by SHA hashes. The unit of history is the commit which can be soley identified by its contents. The hash is easy to compute and provides good entropy properties when building a hash table. *** History is immediately verifiable (barring hash collisions) *** Some measure of security comes for free All commits are effectively signed by all their previous commits, so verifying a repository becomes trivial given only a valid commit id. ** merge commits In git, a commit can have many parents, as opposed to SVN where a commit can have only one parent. Merge commits can also contain blobs themselves to mark conflict resolutions. ** SHA hashes are a pain to type Git has a concept of `refs' which are typically symbolic references to commits. At the end of the day, every ref ends up as a SHA hash. *** SHA hashes can typically be shortened to a few characters *** tags are fixed refs Tags have optional descriptions and GPG signatures. *** branches and HEAD Branches are moving refs and always reference their tips. HEAD is a pointer to the tip of the current branch. *** $ref^ and $ref~$n You can follow parents by using caret or tilde notation. Merge commits are followed in their order in the commit blob. # ^ is the parent, ^^ is the paren't parent, and so on e.g: HEAD^ (The next most-recent commit on the current branch) # ~2 is shorthand for ^^ e.g: HEAD~2 (The third most-recent commit on the current branch) ** Sharing commits *** Remotes *** Implicit read-only "vendor" branches. *** Push and Pull *** Example * Merge strategies *** Fast forward When the merge target is an ancestor of the other branch, this just points the target's HEAD at the other branch. *** Recursive Used when more than one common ancestor exists. Builds the merge base revision by recursively merging common ancestors. *** And others See git-merge(1) * A brief note on the index The index stores the tree object of the commit-to-be. # adding to the index cache: git add # removing: git rm --cached ** git reset Can be used to reset the index, or certain files in the index, to a given commit, which is HEAD by default. * How dVCS democratizes version control * My seekrit agenda I am a lazy programmer, and the more people who use git the easier my life is. I use git because... * Additional Resources # Git - SVN Crash Course # Git User's Manual # Extensive Man Pages