Simple Sequence of GIT Commands

Your steps are fine. To nit-pick slightly, though, about the comments:

The comments about step (2) and (3) are not the best way to think about what's happening, I don't believe.

2.git add foo.java     //will add it to my local repo3.git commit -m "my changes"      //commit to the local repo

The step which "adds" your file to the local repository is git-commit. That's why it's called commit; you commit changes to the repository. git-add foo adds foo to the staging area, not to the repo itself.

Your git repository has three "areas", working, staging and repository, depicted here (image taken from the Pro Git book):

You make changes and work in the creatively named "working directory".

When you've made some changes, you want to prepare to make a commit. This is where the "staging area" comes into play. You "stage" the changes that you want to commit, and when you're happy with what the commit will look like, you commit the "staging area" to the "repository". [Note: in the man pages, this staging area is mostly referred to the index].

This allows you a lot of flexibility. You can stage all the changes since your last commit, or you can stage files individually, or you can stage parts of files. You can add and delete files from the staging area without losing changes or messing up the repositories history. That's what the git add and git rm commands do; they add from the working directory to the staging area, but they don't add directly into the repository. (Hopefully the image helps make the distinctions clear).

Your steps are fine. If you want to understand more about branching, commiting, manipulating commits and branches and whatnot, I'd recommend reading the Pro Git book - it's got a whole bunch of pretty pictures and language simple enough that I can understand it ;)

I think that that's enough for very basic usage. I'd just like to add two comments:

• It's always a good thing to check what you're adding to the staging area (which is what you're doing with git add): either use git diff, or do a git add --patch, which will start an interactive procedure to let you decide whether to accept or reject each hunkof code you modified. If you messed anything up during this phase,you can always git reset HEAD to get the changes back to theworking copy (i.e., you would simply undo the add)
• You might want to do steps 2 and 3 together by issuing a git commit -a -m 'yourmessage'.

After (3), you should be able to call git push origin master which will push your current master branch to github