In continuing exploration into Git, Dave has explained a bit more about the architecture of it. It seems quite different from the SVN I’m used to, but luckily he pointed out a great e-resource. Beyond simple commiting, Git (like any good source control tool) has the ability to branch. All changes are logged incrementally, with a branch representing a pointer to the change log. There is always a branch in Git, even master is a branch. Each branch may have many commits to it, with the latest commit for the current working branch being designated as HEAD. Multiple commits to a branch form a chain of changes dating back not to the beginning of the branch but the beginning of the repo. This is because the beginning of the branch can be thought of as the accumulation of all changes on the trunk up until that point.
Each commit points to one before (backward looking list, results in “tree” when viewed graphically. Commit typically have one parent but in the case of a merge they will have n parents (with n being the number of branches merged in that change set). As a result, a graph of commits in a repo form a web of pointers across many change sets. Here’s a relatively mild visualization (courtesy of progit):
It’s easy to get the hang of so long as one remembers the commands. Here are a few commonly used ones:
// Create branch, stay on working copy (be sure to be on copy you wish to branch from)
git branch branchName
// Merge from branchName into current branch
git merge branchName
// View all branches
git branch
// Switch to other branch (failure to commit changes from last branch will cause error.
// Failure to stage changes from last branch before switching may accidentally affect moved-to branch)
git checkout branchName
// Create and checkout new branch
git checkout -b branchName
// Shows current branch as well as status of modified/staged/committed
git status
This is great, almost there (the last piece of the puzzle being remoting). That’s coming up soon!
Leave a Reply