Do I need to commit in Git, when should I do this, and how can I revert to old versions?

I've been following a tutorial on Git and I'm a bit confused about a few specific issues. The main reason I need to use version control right now is simply to access previous versions of my project if I make a mistake and don't know how to get rid of an error.

1. Is it true that a version is only saved in Git if you executed a commit statement? For some reason, I was thinking that every time you make any change in your project it would automatically be added as a version in your repository for you to go back to.

2. So when should you execute commit? Is it only when you think you've made a good bit of progress?

3. How do you actually reve开发者_如何学编程rt to a previous version in Git? i.e. what's the command?

---

1. With Git (same with SVN, or Bazzar, or others), you need to commit so a version is saved -- this way, git only keeps track of the versions you considered as good enough.

2. I tend to commit when I've got something that works OK -- at least when working on the main branch.
If I'm working on a temporary branch, created specifically to develop a new feature / fix a bug, then I commit pretty much whenever I want, to save the current state of my work.

3. You should take a look at the following page : Undoing in Git - Reset, Checkout and Revert

---

1. Yes, you have to commit to persist a change. This is true in all VCSes though, not just Git.
2. You should commit when you have a version of your code that builds and runs. It should be something you would want to be able to undo to. It's unlikely that this is true on every save. I find I usually commit between 4 and 12 times a day, but it can be more frequent if I'm making a lot of small improvements.

---

1. Yes, only when you run a commit.
2. You should commit as often as you need to\want to. Whenever you finish something useful, before you change something your worried might not work out, or a point were you want to make sure you can come back to. Pushing those changes to others is a different matter. Only ever push things that are at least mostly working and stable.
3. If you have a choice, and need file based version tracking you might want to use Subversion (SVN). Otherwise use git checkout [commit-ref] [filename]. The [commit-ref] is the hash value of the version you want.

---

1. Yes. But read on...

2. With git specifically, it's a good idea to commit every time you think you have made one self-contained logical change. So this should happen quite a lot -- typically commit between once in 5-30 minutes. For examples, just clone the git repo for git, and look at the work of some of the more experienced people.

In many other vcs:es, where your commits are immediately visible to other people, it's often considered good practise to only commit when it builds, or when you have a complete feature. In git, this level of granularity is handled by branches, and someone viewing your commit log should be able to see not just what you did, but how you did it, eg:

• "new branch for feature frobnication"
• "commit: foos now can be frobnicated"
• "commit: baz now checks if foos it works on are being frobnicated"
• "commit: bar now can frobnicate foos"
• "commit: tests for frobnication"

This makes tools that look back on the source much more useful for debugging. You should certainly try to avoid single commits that change 100+ lines -- they turn work you have done on the source into opaque blocks that are hard to understand.