当前回答
我也为此挣扎过。事实上,我来到这里时,用谷歌搜索了完全相同的问题。阅读了所有这些答案,终于在我脑海中画出了一张图片,我决定试着从下面看2个储存库和1个沙箱的状况,以及一段时间以来在看它们的版本时所采取的行动。这就是我所想出来的。如果我在任何地方搞砸了,请纠正我。
三个邮箱有一个接听器:
--------------------- ----------------------- -----------------------
- Remote Repo - - Remote Repo - - Remote Repo -
- - - gets pushed - - -
- @ R01 - - @ R02 - - @ R02 -
--------------------- ----------------------- -----------------------
--------------------- ----------------------- -----------------------
- Local Repo - - Local Repo - - Local Repo -
- pull - - - - fetch -
- @ R01 - - @ R01 - - @ R02 -
--------------------- ----------------------- -----------------------
--------------------- ----------------------- -----------------------
- Local Sandbox - - Local Sandbox - - Local Sandbox -
- Checkout - - new work done - - -
- @ R01 - - @ R01+ - - @R01+ -
--------------------- ----------------------- -----------------------
三号邮局拉一拉一拉
--------------------- ----------------------- -----------------------
- Remote Repo - - Remote Repo - - Remote Repo -
- - - gets pushed - - -
- @ R01 - - @ R02 - - @ R02 -
--------------------- ----------------------- -----------------------
--------------------- ----------------------- -----------------------
- Local Repo - - Local Repo - - Local Repo -
- pull - - - - pull -
- @ R01 - - @ R01 - - @ R02 -
--------------------- ----------------------- -----------------------
--------------------- ----------------------- -----------------------
- Local Sandbox - - Local Sandbox - - Local Sandbox -
- Checkout - - new work done - - merged with R02 -
- @ R01 - - @ R01+ - - @R02+ -
--------------------- ----------------------- -----------------------
这帮助我理解了为什么买东西很重要。
其他回答
简简单简的答案是:git pull
简单git fetch
和继 继 继 继 继 继git merge
.
必须指出,git pull
会不管你喜不喜欢自动合并。这当然可能导致合并冲突。让我们假设你的远程是origin
并且你的分支是master
。如果您git diff origin/master
在拉车之前,你应该对潜在的合并冲突有某种了解,并且可以据此为你的当地部门做好准备。
除了拉和推,一些工作流程涉及git rebase
,例如这一条,我从相关条款中转述如下:
git pull origin master
git checkout foo-branch
git rebase master
git push origin foo-branch
如果你发现自己处于这种情况, 你可能会被诱惑git pull --rebase
除非您真的知道自己在做什么 否则我建议不要这么做man
页面git-pull
版本, 版本2.3.5
:
这是一个潜在危险的操作模式。 它重写历史, 当您已经发布历史时, 历史并不是好兆头。 除非您仔细阅读了 git- rebase(1) , 否则不要使用此选项 。
git fetch
从远程服务器将代码从远程服务器撤回到本地仓库的跟踪分支。如果您的远程服务器被命名origin
然后,这些分支将居其中;origin/
,例如,origin/master
, origin/mybranch-123
等等。这些不是你们的现树枝,而是你们的现树枝。当地当地服务器上那些分支的复制件
git pull
是否为 a 的git fetch
但当时并且,还有将跟踪分支的代码合并到您当前本地版本的该分支中。如果您尚未准备好进行该修改,只需git fetch
头一次。
git 拉
它使用单一命令执行两个函数。
它会获取对远程分支的所有修改, 然后将这些修改合并到您的本地分支中。 您也可以通过 -- rebase 来修改拉动行为。 合并和重基准的区别可以读取在这里
git 获取 git 获取
Git 抓取仅能完成 Git pull 的一半工作。 它只是将远程更改带入您的本地回购, 但没有将其应用到分支中 。 您必须明确应用这些更改 。 这可以做如下操作 :
git fetch
git rebase origin/master
git pull = = (获取 Git + git 合并)
git refick 不改变本地分支 。
如果您已经拥有一个本地仓库, 并且为所要的工程设置了远程设置, 您可以使用 git 抓取, 来抓取所有现有的远程的分支和标记 。... Fetch 不改变本地分支 。 因此您需要将远程分支与本地分支合并, 以纳入新抓取的更改 。发自 Github
最简单的说,git pull
是否为 a 的git fetch
续 续 agit merge
.
git fetch
更新您的远程跟踪分支refs/remotes/<remote>/
。此操作可以随时安全运行,因为它不会改变您在refs/heads
.
git pull
本地分支提供其远程版本的最新信息,同时更新其他远程跟踪分支。
调自 Git 文档git pull
:
git pull
运行中git fetch
使用给定参数,然后取决于配置选项或命令行的旗帜,将调用其中之一git rebase
或git merge
以便各处之间互相调和。
有必要记住,在任何特定机器的Git存储库工作时,存储库载有来自所有远程的所有分支的复制件,以及每个地方分支的复制件,你已经做了一些工作。
你可以看到这个使用git branch -a
显示您所在的分支机构,包括master
和所有遥控器的分支。
master
feature/my-feature-branch
remotes/origin/master
remotes/origin/my-feature-branch
remotes/another-remote-machine/master
remotes/another-remote-machine/my-feature-branch
上面我已指出 遥控遥控器的存在origin
以另一个名称返回和另一个远程another-remote-machine
.
注意 您不必在所有仓库中拥有每个分支的复制件 。 (remotes 和 local.) 它取决于您通过运行同步 。git pull
, git push
, git fetch
,来自不同的机器 / 仓库 所涉及的。
推荐文章
- Windows git“警告:LF将被CRLF取代”,这是警告尾巴向后吗?
- git中的哈希冲突
- git可以自动在空格和制表符之间切换吗?
- Git暂存文件列表
- 如何将git配置存储为存储库的一部分?
- 如何修改GitHub拉请求?
- 如何在Github和本地删除最后n次提交?
- 我如何调试git/git-shell相关的问题?
- 错误:无法使用rebase进行拉取:您有未分阶段的更改
- Git隐藏未缓存:如何把所有未分期的变化?
- 真实的恶魔
- 如何从另一个分支获得更改
- Git:权限被拒绝(publickey)致命-无法从远程存储库读取。克隆Git存储库时
- git reflog和log有什么区别?
- git推挂在Total line之后