- unless it is cloned elsewhere, removing your source tree will also blow away your repository
- Tom Lord's arch was the tool that started the distributed version control craze
- arch puts its repositories in a separate location; this can be replicated w/ git by setting up a remote repository and cloning it locally for daily work
- as an aside, many git fanboys fail to credit Lord for his seminal work. Lord did not get the renumeration or credit he deserved for the innovations he introduced with arch.
brew install git
Clone an existing repository by finding its uri (check github.com as a popular location)
git clone git://git.kernel.org/pub/scm/git/git.git mygitdir
You won't need to include the "mygitdir" argument unless you want to rename the local source tree.
git pull # or pull --rebase
The --rebase option forces git to reapply your local commits to the pulled tree, allowing you to resolve merge conflicts one by one.
git add dirname
git add filename
Git status can tell you what it thinks has changed, and the state of your local source tree relative to that of the remote repository you cloned.
git commit -a
A commit does nothing to propagate the changes to the cloned repository. It sets the point at which you want your local changes to be versioned, and lets to edit a comment for that commit point.
A push propagates the changes back to the cloned repository.
Stash lets you postpone dealing with merge conflicts; typically you might to a git status, git stash, git pull, and git stash apply, then work through any merge conflicts.
There are many other options. These seem to be the ones I've used most often.