Menu
If you have uncommitted changes, the merge part of the git pull command will fail and your local branch will be untouched. Thus, you should always commit your changes in a branch before pulling new commits from a remote repository.
Always Pull Before a Push Doing so will ensure that your local copy is in sync with the remote repository. Remember, other people have been pushing to the remote copy, and if you push before syncing up, you could end up with multiple heads or merge conflicts when you push.
We use Git pull when one is working alone on the branch. Since there is no point in reviewing your changes again, you can directly pull them to your repository. Using Git pull command is no different than using Git merge command. Just keep in mind that git pull is a short cut to git fetch and git merge.
I'd say correct way is always to pull and fix conflicts (if any) before pushing any code upstream. Therefore [PULL - FIX CONFLICTS(if any) - PUSH] * is the right way. Pulling after push will make no sense since there will be a pull again before you push changes upstream making the the previous pull unnecessary.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With