"simple set of rules and requirements that dictate how version numbers are assigned and incremented"

""For this system to work, you first need to declare a public API. This may consist of documentation or be enforced by the code itself. Regardless, it is important that this API be clear and precise. Once you identify your public API, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.

git config branch.autosetuprebase always

"in the normal case of having your local branch simply reflecting the upstream branch and doing continuous development on it, the right thing to do is always "--rebase" because that is what you are semantically actually doing. You and others are hacking away at the intended linear history of a branch. The fact that someone else happened to push slightly prior to your attempted push is irrelevant, and it seems counter-productive for each such accident of timing to result in merges in the history.

[...]

Please consider other people that need to observe and understand the history of your project. Do you want the history littered with hundreds of merges all over the place, or do you want only the select few merges that represent real merges of intentional divergent development efforts?"

Another Git introduction - arguing to use rebase over merge with git-flow

git flow feature rebase
git flow feature finish 77-speedup-yak-shaving

Screencast that discusses gitflow in the context of development and release management in general.

Screencast that covers all: feature, release and hotfix branches.

"Git extensions to provide high-level repository operations for Vincent Driessen's branching model."<br />
<br />
Background: http://nvie.com/posts/a-successful-git-branching-model/

"As a consequence of its simplicity and repetitive nature, branching and merging are no longer something to be afraid of. Version control tools are supposed to assist in branching/merging more than anything else."

"we use two eternal branches, dev and master which contain current development code and live code respectively. Features and bugfixes are developed in their own dedicated branches and merged into dev upon completion for staging and into master when tested thoroughly and marked for release."

"This is the website for the Pro Git book, written by Scott Chacon and published by Apress. Here you can find the full content of the book, a blog with tips and updates about Git and the book and open source projects related to Git or referenced in the book."

What you need to know to get started

A port of TortoiseSVN to GIT

Compilation of online Git learning resources

A well-written introduction to Git for people without versioning experience.

Tutorial on various concepts around version control and Subversion specifically

Git repository hosting.
Created by 2 guys who left CNet, coverage on Ruby on Rails podcast, simplify adopting Git by enabling a web presence for your git repo. Attempts to create a social git of sorts, tracking what you fork and what you patch.

Collaborative writing: edit texts in a wiki-like way with some taskmanagement and chat, and publish the resulting document to a blog via xmlrpc. Participants do not need to register, emails are sent out with an identifying link

" A Subversion client, implemented as a windows shell extension.

TortoiseSVN is a really easy to use Revision control / version control / source control software for Windows. "