gpt4 book ai didi

Git pull 表现得像 git fetch?

转载 作者:行者123 更新时间:2023-12-05 04:31:46 26 4
gpt4 key购买 nike

对于我公司的一个存储库,命令 git pull 开始像 git fetch 一样工作。它会 pull 下所有更新,但实际上不会将更改 merge 到分支中。然后我必须运行 git merge origin/master 来 merge 它们。

什么会导致这种情况?我以前从未见过这种行为。它似乎没有影响存储库的其他用户,它只是我。它也没有影响我使用的其他存储库。我的 git 版本是 git version 2.24.3 (Apple Git-128) 并且存储库托管在 GitHub 上,尽管我怀疑这是否重要。

使用额外请求的详细信息进行编辑:

在任何其他操作之前 git status 的输出:

$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

接着是git pull:

remote: Enumerating objects: 3333, done.
remote: Counting objects: 100% (1623/1623), done.
remote: Compressing objects: 100% (128/128), done.
remote: Total 3333 (delta 1517), reused 1554 (delta 1488), pack-reused 1710
Receiving objects: 100% (3333/3333), 2.07 MiB | 15.83 MiB/s, done.
Resolving deltas: 100% (2113/2113), completed with 355 local objects.
From github.com:repo/url
6c1fab37s6b7..7acd6e422762 master -> origin/master

git status git pull 之后:

$ git status
On branch master
Your branch is behind 'origin/master' by 94 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)

nothing to commit, working tree clean

为了更好的衡量,git branch -vv 的输出:

$ git branch -vv
* master 6c32ab37afb7 [origin/master: behind 94] commit message

当使用 GIT_TRACE=1 时,会收集到以下附加信息:

pull 输出前:

09:46:36.847574 exec-cmd.c:238          trace: resolved executable dir: /Library/Developer/CommandLineTools/usr/bin
09:46:36.848324 git.c:439 trace: built-in: git pull
09:46:36.865183 run-command.c:663 trace: run_command: git fetch --update-head-ok
09:46:36.870423 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Library/Developer/CommandLineTools/usr/libexec/git-core/git
09:46:36.871061 exec-cmd.c:238 trace: resolved executable dir: /Library/Developer/CommandLineTools/usr/libexec/git-core
09:46:36.871707 git.c:439 trace: built-in: git fetch --update-head-ok
09:46:36.890545 run-command.c:663 trace: run_command: unset GIT_PREFIX; ssh git@github.com 'git-upload-pack '\''org/repo-name.git'\'''
remote: Enumerating objects: 3232, done.
remote: Counting objects: 100% (1480/1480), done.
remote: Compressing objects: 100% (229/229), done.
09:46:41.239506 run-command.c:663 trace: run_command: git index-pack --stdin -v --fix-thin '--keep=fetch-pack 94201 on USERNAME' --pack_header=2,3232
09:46:41.252417 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Library/Developer/CommandLineTools/usr/libexec/git-core/git
09:46:41.254014 exec-cmd.c:238 trace: resolved executable dir: /Library/Developer/CommandLineTools/usr/libexec/git-core
09:46:41.256304 git.c:439 trace: built-in: git index-pack --stdin -v --fix-thin '--keep=fetch-pack 94201 on USERNAME' --pack_header=2,3232
remote: Total 3232 (delta 1333), reused 1323 (delta 1243), pack-reused 1752
Receiving objects: 100% (3232/3232), 4.03 MiB | 19.39 MiB/s, done.
Resolving deltas: 100% (1972/1972), completed with 268 local objects.
09:46:42.117286 run-command.c:663 trace: run_command: git rev-list --objects --stdin --not --all --quiet --alternate-refs
09:46:42.126065 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Library/Developer/CommandLineTools/usr/libexec/git-core/git
09:46:42.126771 exec-cmd.c:238 trace: resolved executable dir: /Library/Developer/CommandLineTools/usr/libexec/git-core
09:46:42.127570 git.c:439 trace: built-in: git rev-list --objects --stdin --not --all --quiet --alternate-refs

pull 输出后:

09:46:43.640301 run-command.c:663       trace: run_command: git gc --auto
09:46:43.647411 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Library/Developer/CommandLineTools/usr/libexec/git-core/git
09:46:43.648461 exec-cmd.c:238 trace: resolved executable dir: /Library/Developer/CommandLineTools/usr/libexec/git-core
09:46:43.649426 git.c:439 trace: built-in: git gc --auto

最佳答案

不带额外参数运行 git pull 基本上等同于运行:

git fetch
git merge

也就是说,这里没有额外的origin/master传递 git merge。因此,如果您在上游为 origin/br1 的分支 br1 上运行 git merge,则实际上是在运行 git merge origin/br1,不是 git merge origin/master

我的猜测,那么——因为你没有在问题中提供足够的信息——无论你现在在哪个分支上,它都有一个上游,但那个上游不是 origin/主人。最好在 git pull 命令及其实际输出之前显示一个 git status 命令及其输出;这些将有助于确认您在运行 git pull 时所在的分支,以及其上游设置的内容。

请注意,您可以配置 git pull 以运行 git rebase 作为它的第二步,并且在现代 Git 中(但不是出于date Apple 版本),您还需要配置其中一个 pull.* 设置。不过,我建议根本不要使用 git pull:运行 git fetch,然后运行您自己的第二个命令。除了需要新的 pull.* 设置的最新 Git 之外,让 git pull 做你不想做的事情太容易了。

关于Git pull 表现得像 git fetch?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/71785898/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com