2 Expanded on a point in my answer
source | link

I'm a relative newbie to version control; I've used mostly SVN, a little Mercurial, and even less Git, for only a few years now. That said, I think the following is probably good advice:

  • Make small commits often.
  • When you commit changes, commit only related items together to keep things coherent. This helps later on when you're looking back through commit messages -- if you're looking for a particular change and it's one of many, unrelated things done in a commit, you might miss it. It's also helpful if you need to roll something back since you won't be rolling back unrelated changes that were committed at the same time.
  • If you're going to do something that you think will mess things up, do it in a branch and merge it in later after you get it working.
  • Write a nice overview of what was done in each change for your commit messages. If you need more information than that, you'll probably end up looking at the code anyway.
  • Link related changes together by mentioning some overarching task you're working on. This will help paint a story across commits when you look back at things later on. An example would be: "Refactoring Feature Alpha: Changed X, Y, and Z"

You might find the Hg Init Tutorial of interest; it has information on setting things up for multiple people and general usage advice.

Recently I've been reading through the (Ruby on) Rails Tutorial, and they take you through everything you'll do while working on a RoR project, including using Git; you might like to read/follow along for a few chapters of this to see how use of version control integrates with the rest of the development process, in more of a live setting.

I'm a relative newbie to version control; I've used mostly SVN, a little Mercurial, and even less Git, for only a few years now. That said, I think the following is probably good advice:

  • Make small commits often.
  • When you commit changes, commit only related items together to keep things coherent. This helps later on when you're looking back through commit messages -- if you're looking for a particular change and it's one of many, unrelated things done in a commit, you might miss it.
  • If you're going to do something that you think will mess things up, do it in a branch and merge it in later after you get it working.
  • Write a nice overview of what was done in each change for your commit messages. If you need more information than that, you'll probably end up looking at the code anyway.
  • Link related changes together by mentioning some overarching task you're working on. This will help paint a story across commits when you look back at things later on. An example would be: "Refactoring Feature Alpha: Changed X, Y, and Z"

You might find the Hg Init Tutorial of interest; it has information on setting things up for multiple people and general usage advice.

Recently I've been reading through the (Ruby on) Rails Tutorial, and they take you through everything you'll do while working on a RoR project, including using Git; you might like to read/follow along for a few chapters of this to see how use of version control integrates with the rest of the development process, in more of a live setting.

I'm a relative newbie to version control; I've used mostly SVN, a little Mercurial, and even less Git, for only a few years now. That said, I think the following is probably good advice:

  • Make small commits often.
  • When you commit changes, commit only related items together to keep things coherent. This helps later on when you're looking back through commit messages -- if you're looking for a particular change and it's one of many, unrelated things done in a commit, you might miss it. It's also helpful if you need to roll something back since you won't be rolling back unrelated changes that were committed at the same time.
  • If you're going to do something that you think will mess things up, do it in a branch and merge it in later after you get it working.
  • Write a nice overview of what was done in each change for your commit messages. If you need more information than that, you'll probably end up looking at the code anyway.
  • Link related changes together by mentioning some overarching task you're working on. This will help paint a story across commits when you look back at things later on. An example would be: "Refactoring Feature Alpha: Changed X, Y, and Z"

You might find the Hg Init Tutorial of interest; it has information on setting things up for multiple people and general usage advice.

Recently I've been reading through the (Ruby on) Rails Tutorial, and they take you through everything you'll do while working on a RoR project, including using Git; you might like to read/follow along for a few chapters of this to see how use of version control integrates with the rest of the development process, in more of a live setting.

1
source | link

I'm a relative newbie to version control; I've used mostly SVN, a little Mercurial, and even less Git, for only a few years now. That said, I think the following is probably good advice:

  • Make small commits often.
  • When you commit changes, commit only related items together to keep things coherent. This helps later on when you're looking back through commit messages -- if you're looking for a particular change and it's one of many, unrelated things done in a commit, you might miss it.
  • If you're going to do something that you think will mess things up, do it in a branch and merge it in later after you get it working.
  • Write a nice overview of what was done in each change for your commit messages. If you need more information than that, you'll probably end up looking at the code anyway.
  • Link related changes together by mentioning some overarching task you're working on. This will help paint a story across commits when you look back at things later on. An example would be: "Refactoring Feature Alpha: Changed X, Y, and Z"

You might find the Hg Init Tutorial of interest; it has information on setting things up for multiple people and general usage advice.

Recently I've been reading through the (Ruby on) Rails Tutorial, and they take you through everything you'll do while working on a RoR project, including using Git; you might like to read/follow along for a few chapters of this to see how use of version control integrates with the rest of the development process, in more of a live setting.