When do I need to do "git pull", before or after "git add, git commit"?

What is the right way?

git add foo.js
git commit foo.js -m "commit"
git pull
git push

Or

git pull
git add foo.js
git commit foo.js -m "commit"
git push

Or

git add foo.js
git pull
git commit foo.js -m "commit"
git push

UPD:

I forgot to mention that in this case I use git add to stage a tracked and modified file. Not to include a brand new file to repository. Does this changes an order of commands?

I think that the best way to do this is:

Stash your local changes:

git stash

Update the branch to the latest code

git pull

Merge your local changes into the latest code:

git stash apply

Add, commit and push your changes

git add
git commit
git push

In my experience this is the path to least resistance with Git (on the command line anyway).

pull = fetch + merge.

You need to commit what you have done before merging.

So pull after commit.

I'd suggest pulling from the remote branch as often as possible in order to minimise large merges and possible conflicts.

Having said that, I would go with the first option:

git add foo.js
git commit foo.js -m "commit"
git pull
git push

Commit your changes before pulling so that your commits are merged with the remote changes during the pull. This may result in conflicts which you can begin to deal with knowing that your code is already committed should anything go wrong and you have to abort the merge for whatever reason.

I'm sure someone will disagree with me though, I don't think there's any correct way to do this merge flow, only what works best for people.

I think git pull --rebase is the cleanest way to set your locally recent commits on top of the remote commits which you don't have at a certain point.

So this way you don't have to pull every time you want to start making changes.

You want your change to sit on top of the current state of the remote branch. So probably you want to pull right before you commit yourself. After that, push your changes again.

"Dirty" local files are not an issue as long as there aren't any conflicts with the remote branch. If there are conflicts though, the merge will fail, so there is no risk or danger in pulling before committing local changes.

Best way for me is:

1. create new branch, checkout to it
2. create or modify files, git add, git commit
3. back to master branch and do pull from remote (to get latest master changes)
4. merge newly created branch with master
5. remove newly created branch
6. push master to remote

Or you can push newly created branch on remote and merge there (if you do it this way, at the end you need to pull from remote master)