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 comm
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.
Best way for me is:
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)
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.
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.
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.