什麼是正確的方法？什麼時候需要做「git pull」，在「git add，git commit」之前還是之後？
git add foo.js
git commit foo.js -m "commit"
git pull
git push
或者
git pull
git add foo.js
git commit foo.js -m "commit"
git push
或者
git add foo.js
git pull
git commit foo.js -m "commit"
git push
UPD：
我忘了提及的是，在這種情況下，我使用git add上演了一出跟蹤和修改了文件。不要將全新的文件包含到存儲庫中。這是否改變命令的順序？
pull = fetch + merge。
您需要提交您在合併之前完成的操作。
所以拉後提交。
這是否意味着你最終會做出一個爲每次提交進行額外的提交併使回購馬虎？此外，您的初始提交消息每次都會以合併註釋結束。如果是這樣，我傾向於使用@johnjo提到的隱藏方法。 –
@DanielM是的，有一個額外的提交合並（具有明確的默認提交信息）。這是一件好事，因爲它允許你簽出你最後一次提交或你的同事的最後一次提交或合併提交。如果你想避免它，並且如果你想在你的同事提交之後提交你的提交，你可以'rebase'而不是'merge'。你可以用'git commit && git rebase'或'git pull --rebase'來完成。 –
感謝您的提示，@Arnaud。在閱讀了許多不同的SO問題之後，這個評論成了它。當我的同事們處理不同的文件時，我最喜歡的選擇是在升級我的更改後「git pull」，因爲我發現它是最自然的。雖然我意識到許多不同的工作流程都起作用（隱藏也很好），所以這可能是品味的問題。 – nephewtom
我建議儘可能頻繁地從遠程分支拉，以儘量減少大的合併和可能的衝突。
話雖如此，我會第一個選項去：
git add foo.js
git commit foo.js -m "commit"
git pull
git push
拉動，使您的提交與拉過程中遠程修改合併之前提交更改。這可能會導致衝突，你可以開始處理知道你的代碼已經被提交，如果出現任何錯誤，你不得不中止合併，無論出於何種原因。
我敢肯定有人會不同意我，雖然我不認爲有任何正確的方式來做這種合併流程，只有最適合人們的方式。
您希望您的更改位於遠程分支當前狀態的頂部。所以可能你想在你自己做出決定之前就拉正確。之後，再次推送您的更改。
只要與遠程分支沒有任何衝突，「髒」本地文件不是問題。如果存在衝突，合併將失敗，因此在進行本地更改之前沒有風險或危險。
我認爲要做到這一點，最好的辦法是：
藏匿本地更改：
git stash
更新分支到最新的代碼
git pull
合併本地更改成最新編號：
git stash apply
添加，提交和推送更改
git add
git commit
git push
在我的經驗，這是通向阻力最小使用Git（在命令行上是這樣）。
我認爲git pull --rebase是最簡單的方法來設置您在本地最近提交遠程提交的頂部，你沒有在某一點上。
所以這種方式你不必每次都想要開始進行修改。
相關問題：http://stackoverflow.com/questions/813822/how-to-make-git-merge-handle-uncommitted-change-to-my-working-tree – leo9r