Git Workflow Pull vs Fetch

Question

我知道之前已經問過這個問題，但在我看來答案已經隨着時間的推移而改變，所以我很困惑。 所以在2012年12月22日圓滿之后，（我們這些幸存下來的人）一勞永逸，當你想從遠程分支中獲取最新變化時，建議使用git的方式是“開發”。

我使用拉，說實話從來沒用過fetch。 我只是感到震驚，我可能會讓自己陷入一些奇怪的境地。

以下是我的工作流程示例：

git pull origin develop
git checkout -b story-001
...do some work
git commit -am "fixed utests"
.. do some more work
git commit -am "fixed impl for service x"
git rebase develop
git checkout develop
git merge --squash story-001
git commit -m "Story 001 completed <testinfo>"
git push origin develop
..error.. master is head..
git pull origin develop
..maybe merge issue
git mergetool
..resolved problem
git commit -am "resolved merge for story 001"
git push origin develop
git branch -D story-001
....
... and so on
... after a while some changes on remote <develop>
... 
git pull origin develop

正如你在我的世界中看不到的那樣，為什么會這樣？

Answer 1

好吧， git pull執行git fetch然后是git merge 。 因此，如果您希望自動合並pull ed存儲庫，那么您不需要git fetch 。

Answer 2

如果您希望當前（本地）的工作保持領先，那么您就可以了

git fetch
git rebase origin/develop

要么

git pull --rebase

代碼中的合並，即遠程和本地更改時的拉動，可能會導致本地工作的順序錯誤，並被遠程更改覆蓋。

因此，如果你想抓住遙控器，你應該做拉動和獲取，如果你已經在你的本地做了一些工作。 只是為了保持簡單。 但是大多數時候，如果你運氣好的話，拉動會起作用。

這是我通過做更多研究所理解的。 但是，在我嘗試進行一些實驗驗證之前，我不確定。

我認為最好的解決方案是大多數時候使用git pull --rebase，不知何故更有意義。 您可以根據我的理解更改git pull的默認行為，但這可能很危險，因為您可能會忘記它並使自己更加困惑。

Answer 3

我通常這樣工作：

git pull origin develop
git checkout -b story-001
git commit -am "..."
# more commits, squash the commits, reorganize

在這個階段，我經常進行git fetch來獲取最新的更改。 如果有任何新的更改，我將執行git rebase origin/develop以在新更改之上移動我在功能分支上的工作。

# work some more
git checkout develop
git merge # defaults to origin
git merge story-001
git push

有了這個工作流程，我沒有合並提交，歷史很干凈。 此外，我通常不會編寫這些命令，嘗試像git-smart這樣的東西。