我什么时候需要在“git add，git commit”之前或之后做“git pull”？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/18529206/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
When do I need to do "git pull", before or after "git add, git commit"?
提问by Green
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 addto stage a trackedand modifiedfile. Not to include a brand new file to repository. Does this changes an order of commands?
我忘了提及，在这种情况下，我使用的git add，要进行一次跟踪和修改的文件。不要将全新的文件包含到存储库中。这会改变命令的顺序吗？
回答by johnjo
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).
根据我的经验，这是使用 Git 阻力最小的途径（无论如何在命令行上）。
回答by Arnaud Denoyelle
pull = fetch + merge.
拉 = 获取 + 合并。
You need to commit what you have done before merging.
您需要在合并之前提交您所做的事情。
So pull after commit.
所以提交后拉。
回答by Jasarien
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 correctway to do this merge flow, only what works best for people.
不过，我确定有人会不同意我的观点，我认为没有任何正确的方法可以执行此合并流程，只有最适合人们的方法。
回答by Mohyaddin Alaoddin
I think git pull --rebaseis the cleanest way to set your locally recent commits on top of the remote commits which you don't have at a certain point.
我认为git pull --rebase是将您本地最近的提交设置在您在某个时候没有的远程提交之上的最干净的方法。
So this way you don't have to pull every time you want to start making changes.
因此，这样您就不必每次想要开始进行更改时都拉动。
回答by AlexE
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.
只要与远程分支没有任何冲突，“脏”本地文件就不是问题。如果存在冲突，合并将失败，因此在提交本地更改之前拉取没有风险或危险。
