@tswicegood's talk is for people who aren't familiar with git or version control. They won't be delving into the the internals.

Installation of git for ubuntu can be done with apt. If I heard correctly (busy setting up to blog), Windows installation will require cygwin. OSX can be done with homebrew. Be sure to verify the install no matter which installation method you. One thing to keep in mind about git is that it started out on the command line and will always be heavily entrenched there. So hopefully your team is comfortable with that.

When you start using git, you should set up your user and email. Config also allows you to enable colors.

To create a repository, you call "git init" from the command prompt. The repository is created in a hidden directory and you create a directory for your working tree(if I understood correctly). Git allows you to clone a repository with the clone command.

There is an area called "Index" that @tswicegood calls the "Staging Area". This area allows you to commit specific changes separately. Seems like the flow is like what I'm use to with Bazaar (bzr) where you check status, add files if needed, then commit. Instead of version numbers, git uses sha1 hashes based on the config and time.

Once difference to bzr is that you need to add the file again in order to commit changes you want. You can provide the file as a parameter to commit command or you can use the -a flag to commit all the known working tree changes. Using the -p flag with the add command (git add -p foo.txt), you can get the diff.

Removing a new file can be done with "git rm --cached foo.txt". Moving files can be done by moving them yourself or you can also do "git mv" to rename. Deleting a file is "git rm" without the --cached flag.

sending changes is done with push command. Something to do with 'origin' and 'master' which should be covered later?

So far the only real advantage I'm seeing over Bazaar is the staging area which I do with my branching strategy already. Apparently in git, a branch is just a pointer to a particular commit somewhere in the repository.

Git can do a merge by recursion. He's blasting through some of the branch info to get to team work. Talking about rebasing which seems crazy and dangerous. Remotes seem interesting and easy to set up. Fetching changes are how you can populate the remote branch. Once you fetch changes, you still have to merge.This brings us back to the pull command which allows you to fetch and merge.

Refspec at its simplest is a single branch. You can rebase as part of a pull by giving the --rebase flag. Refspec when pushing is flipped (local then remote).

A lot of information to take in, going to look into it more later. Looks pretty flexible.

Related articles by Zemanta

• Improve Your Development Process with Git (slideshare.net)
• My Common Git Workflow (yehudakatz.com)
• Still hatin' on git: now with added Actual Reasons (reprog.wordpress.com)
• Loving Git[2] (slideshare.net)

Joining the wordle meme late in the game because I just got ff java plugin to work.