3

我知道以前有人问过这个问题，但在我看来答案已经随着时间而改变，所以我很困惑。因此，一劳永逸地在 2012 年 12 月 22 日末日之后，（我们这些幸存下来的人）当您想从远程分支中提取最新更改时，推荐使用 git 的方式说“开发”。

我使用拉，老实说从未使用过获取。我只是感到震惊，我可能会让自己陷入某种奇怪的境地。

这是我的工作流程示例：

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

正如你所见，我的世界里没有 fetch，为什么会有？

4

3 回答 3

9

好吧，git pull确实git fetch其次git merge。因此，如果您希望自动合并pulled 存储库，那么您不需要git fetch.

于 2012-12-22T16:37:55.043 回答
6

如果您希望您当前的（本地）工作保持领先，您可以

git fetch
git rebase origin/develop

或者

git pull --rebase

在远程和本地更改时合并代码，即拉取，可能会导致您的本地工作以错误的顺序放置并被远程更改覆盖。

因此，如果您只想抓住遥控器，如果您在本地完成了一些工作，则应该进行拉取操作。只是为了保持简单。但大多数时候，如果你幸运的话，拉动会起作用。

这是我通过更多研究了解到的。但是我不确定，直到我尝试一个小实验来验证。

我认为最好的解决方案是大多数时候使用 git pull --rebase ，以某种方式更有意义。据我了解，您可以更改 git pull 的默认行为，但这可能很危险，因为您可能会忘记它并使自己更加困惑。

于 2013-01-04T23:08:40.710 回答
2

我通常是这样工作的：

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 之类的。

于 2012-12-22T16:47:02.620 回答