As a DVCS, Git doesn't enforce a linear line of development, but rather a directed graph. Here's what I would do, given that you want to save the other commits:
$ git branch feature-I-was-working-on commit4
This creates a branch titled feature-I-was-working-on
, and points it at commit4
. This way, you can put this branch aside and come back to it later.
$ git checkout commit1
This makes your working files the same as they were after commit1
was committed.
$ git checkout -b feature-Im-now-working-on
This creates a new branch titled feature-Im-now-working-on
, and points it at the current commit you're on (if you've been following along, that's commit1
).
So now if you git checkout feature-Im-now-working-on
, you don't get any of commit2
, commit3
, or commit4
. If you check out feature-I-was-working-on
, you get those.
Now, you're on the branch feature-Im-now-working-on
, and you make more commits. Those commits don't get into feature-I-was-working-on
, but you can go back to it at any time.
But let's say that now you want to get commit2
, commit3
, and commit4
into feature-Im-now-working-on
. That's simple! First check out feature-Im-now-working-on
, then run this command:
$ git merge feature-I-was-working-on
DVCSs are more complicated than Subversion, but they're also more powerful. If you work with them and not against them, they let you easily do things you would never think of in Subversion.