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

Question

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.