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?

Solution 1:

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).

Solution 2:

pull = fetch + merge.

You need to commit what you have done before merging.

So pull after commit.

Solution 3:

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.

Solution 4:

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.