Question

我知道之前已经问过这个问题，但在我看来答案已经随着时间的推移而改变，所以我很困惑。所以在2012年12月22日圆满之后，（我们这些幸存下来的人）一劳永逸，当你想从远程分支中获取最新变化时，建议使用git的方式是“开发”。

我使用pull并且说实话从未使用过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的内容。

Git Workflow Pull vs Fetch

3 个答案: