git FETCH_HEAD 是什么?
自己测试
打开本地文件:
切换本地分支之后, 然后执行 git pull,本地的FETCH_HEAD 发送改变:
注意需要执行 git pull, FETCH_HEAD 才会发送变化。 否则不变。 第一行是 当前分支的真正的 FETCHHEAD, 其中of 后面的是 远程的仓库地址。
not-for-merge 是什么? not-for-merge 表明了 默认情况下 git merge不会 对其分支自动进行 merge, 如果有需要, 必须手动知道分支。
参考 https://stackoverflow.com/questions/18262670/egit-not-for-merge
git FETCH_HEAD 是什么? 可见, 他就是一个 默认的 fetch 或说 merge 的指针, 同时包括了其他的 非默认的分支。
转载
下面是转载 https://www.cnblogs.com/Venom/p/5477367.html +++++++++
git push.
这个很简单, 其实和后面的差不多, 这里就不讲了.
唯一需要注意的地方是:
git push origin :branch2, 表示将一个内容为空的同名分支
推送到远程的分支.(说白了, 即删除远程主机的branch2分支), 但是这并不会消除之前的comment内容, 而且你一旦提交了一些大的文件(例如: 图片之类的), 通过这个操作, 是不会将这些文件占用的空间消除的. 如果要真正的删除一个文件, 除了删除整个项目, Github网站也有提供办法, 不过还没看懂.
git fetch, 理解fetch的含义, 是远程协作的关键.
而理解 fetch
的关键, 是理解 FETCH_HEAD
.
这里需要解释下什么是FETCH_HEAD??
FETCH_HEAD指的是: 某个branch在服务器上的最新状态'.
执行过fetch操作的项目'都会存在一个FETCH_HEAD列表,
每一个
这个列表保存在 .git/FETCH_HEAD
文件中, 其中每一行对应于远程服务器的一个分支
.
当前分支指向的FETCH_HEAD, 就是这个文件第一行对应的那个分支
.
一般来说, 存在两种情况:
-
如果没有显式的指定
远程分支
, 则远程分支的master
将作为默认的FETCH_HEAD. -
如果指定了
远程分支
, 就将这个远程分支作为FETCH_HEAD.
常见的git fetch 使用方式包含以下四种:
git fetch
这一步其实是执行了两个关键操作:
- 创建并更新
所有远程分支的本地远程分支
.
- 设定当前分支的FETCH_HEAD
为远程服务器的master分支
(上面说的第一种情况)
需要注意的是: 和push不同, fetch会自动获取远程`新加入'的分支.
git fetch origin
同上, 只不过手动指定了remote.
git fetch origin branch1
设定当前分支的 FETCH_HEAD' 为
远程服务器的branch1分支`.
注意: 在这种情况下, 不会在本地创建本地远程分支
, 这是因为:
这个操作是git pull origin branch1
的第一步, 而对应的pull操作,并不会在本地创建新的branch.
一个附加效果是:
这个命令可以用来测试远程主机的远程分支branch1是否存在, 如果存在, 返回0, 如果不存在, 返回128, 抛出一个异常.
git fetch origin branch1:branch2
只要明白了上面的含义, 这个就很简单了,
- 首先执行上面的fetch操作
-
使用远程branch1分支在本地创建branch2(但不会切换到该分支),
如果本地不存在branch2分支, 则会自动创建一个新的branch2分支,
如果本地存在branch2分支, 并且是`fast forward', 则自动合并两个分支, 否则, 会阻止以上操作. -
git fetch origin :branch2
等价于: git fetch origin master:branch2
git pull
只要理解了git fetch, git pull就太简单了.
git pull 等价于以下两步:
- 经命令中的pull换成fetch, 执行之...
- git merge FETCH_HEAD
唯一需要提及的一点是:
我认为pull操作, 不应该涉及三方合并
或 衍合
操作 换个说法: pull 应该总是 fast forward 的. 为了达到这样一个效果, 在真正push操作之前, 我倾向于使用衍合
, 在本地对代码执行合并操作.
https://www.cnblogs.com/Venom/p/5477367.html