git本地分支跟远程分支一定要同名才能push吗？ - 开源中国社区
当前访客身份：游客 [
当前位置：
小弟用git有一段时间了，但经常遇到这个问题，索性问一下，希望能有解决方案
git version 1.7.9.5
我clone了一个远程仓库
git branch -r
& origin/master
& origin/test1
git checkout -b test1test origin/test1
在本地建立一个分支test1test跟踪远程的分支test1
git branch
* test1test
git config -l
（前面略）....
branch.test1test.remote=origin
branch.test1test.merge=refs/heads/test1
这时问题来了，我做了几个修改，明明看起来是跟踪远程分支了，但是push不上去
echo& hello2 & test1
git add test1 && git commit -m "hello2" && git push
[test1test f4db248] hello2
&1 file changed, 1 insertion(+), 1 deletion(-)
Everything up-to-date
git status
# On branch test1test
# Your branch is ahead of 'origin/test1' by 1 commit.
nothing to commit (working directory clean)
echo& hello3 & test1 && git add test1 && git commit -m "hello3" && git push
[test1test 1baa86d] hello3
&1 file changed, 1 insertion(+), 1 deletion(-)
Everything up-to-date
git status
# On branch test1test
# Your branch is ahead of 'origin/test1' by 2 commits.
nothing to commit (working directory clean)
这个分支的状态始终是Your branch is ahead of 'origin/test1' by xxx commits.
这是为什么？如果我老老实实把分支名叫做test1就可以push？是我哪里理解有问题？
另外问一个相关问题：
还是上面那个测试环境，有的git在clone以后，直接git checkout test1就能建立一个跟踪远程test1的本地分支，有的需要手工指定，这是哪个git版本才有的特性吗？
共有4个答案
<span class="a_vote_num" id="a_vote_num_
git pull能正常工作的原因是 这个分支的父分支 是有对应远程分支的。
比如你爸有车，如果你想用，有两种方法
1.把自己merge到父分支中，在父分支中push,相当于搭你爸的顺风车。
2.自己在远程也有一个对应的分支，push -u ,相当于自己买个车。
--- 共有 2 条评论 ---
我一直以为pull配了对应的远程分支以后，push也理所当然就能工作了……
(1年前)&nbsp&
明白了，谢谢！！
(1年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
程序正常退出的返回值是0。
<span class="a_vote_num" id="a_vote_num_
不一定，本地分支和它所对应的远程分支的名字可以不一样的
git push -u origin local_branch_name:romote_branch_name
一般 remote_branch_name为空则远程会创建同名分支
local 和remote可以不一样，当使用了 -u 参数后，push local时候 默认的远程分支就是remote了
--- 共有 1 条评论 ---
谢谢回答，我测试了一下，用git push -u的方法可以将本地的分支push到远程的不同名分支上，这个问题算是有一个解决方法了。只是比较好奇直接git push为什么不可以，但git pull却可以工作……
(1年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
最好loacal branch 跟 remote branch 命名一样。
更多开发者职位上
有什么技术问题吗？
hawkyou...的其它问题
类似的话题31957人阅读
git 详解（32）
远程分支（remote branch）是对远程仓库中的分支的索引。它们是一些无法移动的本地分支；只有在Git 进行网络交互时才会更新。远程分支就像是书签，提醒着你上次连接远程仓库时上面各分支的位置。
我们用 (远程仓库名)/(分支名) 这样的形式表示 远程分支。比如我们想看看上次同origin 仓库通讯时master 的样子，就应该查看origin/master 分支。如果你和同伴一起修复某个问题，但他们先推送了一个iss53 分支到远程仓库，虽然你可能也有一个本地的iss53
分支，但指向服务器上最新更新的却应该是origin/iss53 分支。
可能有点乱，我们不妨举例说明。假设你们团队有个地址为
的 Git 服务器。如果你从这里克隆，Git 会自动为你将此远程仓库命名为origin，并下载其中所有的数据，建立一个指向它的master 分支 的指针，在本地命名为origin/master，但你无法在
本地更改其数据。接着，Git 建立一个属于你自己的本地master 分支，始于origin 上master 分支相同的位置，你可以就此开始工作（见图 3-22）：
图 3-22.& 一次Git 克隆 会建立你自己的 本地分支master 和 远程分支origin/master，它们都指向 origin/master 分支的 最后一次提交。
如果你在本地 master 分支做了些改动，与此同时，其他人向
推送了他们的更新，那么服务器上的 master 分支就会向前推进，而于此同时，你在本地的提交历史正朝向不同方向发展。不过只要你不和服务器通讯，你的origin/master指针仍然保持原位不会移动（见图 3-23）。
图 3-23. 在本地工作的同时有人向远程仓库推送内容会让提交历史开始分流。
可以运行 git fetch origin 来同步 远程服务器 上的数据到 本地。该命令首先找到origin 是哪个服务器（本例为），从上面获取你尚未拥有的数据，更新你本地的数据库，然后把origin/master 的指针移到它最新的位置上（见图 3-24）。
图 3-24. git fetch 命令会更新 remote 索引。
为了演示拥有多个远程分支（在不同的远程服务器上）的项目是如何工作的，我们假设你还有另一个仅供你的敏捷开发小组使用的内部服务器 git.。可以用第二章中提到的git remote add 命令把它加为当前项目的远程分支之一。我们把它命名为teamone，以便代替原始的 Git 地址（见图 3-25）。
图 3-25. 把另一个服务器加为远程仓库
现在你可以用 git fetch teamone 来获取小组服务器上你还没有的数据了。由于当前该服务器上的内容是你 origin 服务器上的子集，Git 不会下载任何数据，而只是简单地创建一个名为teamone/master 的分支，指向teamone 服务器上master 分支所在的提交对象31b8e（见图 3-26）。
图 3-26. 你在本地有了一个指向 teamone 服务器上 master 分支的索引。
push推送 本地分支
要想和其他人分享某个 本地分支，你需要把它推送到一个你拥有写权限的远程仓库。你的本地分支不会被自动同步到你引入的远程服务器上，除非你明确执行推送操作。换句话说，对于无意分享的分支，你尽管保留为私人分支好了，而只推送那些协同工作要用到的特性分支。
如果你有个叫 serverfix 的分支 需要和他人一起开发，可以运行git push (远程仓库名) (分支名)：
$ git push origin serverfix
Counting objects: 20, done.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (15/15), 1.74 KiB, done.
Total 15 (delta 5), reused 0 (delta 0)
To :schacon/simplegit.git
* [new branch]
serverfix -& serverfix
这其实有点像条捷径。Git 自动把 serverfix 分支名扩展为
refs/heads/serverfix:refs/heads/serverfix，意为“取出我在本地的 serverfix 分支，推送到远程仓库的 serverfix 分支中去”。我们将在第九章进一步介绍refs/heads/ 部分的细节，不过一般使用的时候都可以省略它。也可以运行git push origin serverfix:serferfix 来实现相同的效果，它的意思是“上传我本地的
serverfix 分支到远程仓库中去，仍旧称它为 serverfix 分支”。通过此语法，你可以把本地分支推送到某个命名不同的远程分支：若想把远程分支叫作awesomebranch，可以用git push origin serverfix:awesomebranch 来推送数据。
接下来，当你的协作者再次从服务器上获取数据时，他们将得到一个新的远程分支 origin/serverfix：
$ git fetch origin
remote: Counting objects: 20, done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 15 (delta 5), reused 0 (delta 0)
Unpacking objects: 100% (15/15), done.
From :schacon/simplegit
* [new branch]
-& origin/serverfix
&#20540;得注意的是，在 fetch 操作下载好新的远程分支之后，你仍然无法在本地编辑该远程仓库中的分支。换句话说，在本例中，你不会有一个新的serverfix 分支，有的只是一个你无法移动的origin/serverfix 指针。
如果要把该内容合并到当前分支，可以运行 git merge origin/serverfix。如果想要一份自己的serverfix 来开发，可以在远程分支的基础上分化出一个新的分支来：
$ git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
Switched to a new branch &serverfix&
这会切换到新建的 serverfix 本地分支，其内容同远程分支 origin/serverfix 一致，这样你就可以在里面继续开发了。
跟踪远程分支
从远程分支 checkout 出来的本地分支，称为_跟踪分支(tracking branch)_。跟踪分支 是一种和 远程分支有直接联系的 本地分支。在跟踪分支里 输入git push，Git 会自行推断应该向哪个服务器的哪个分支推送数据。反过来，在这些分支里运行git
pull 会获取所有远程 索引，并把它们的数据都合并到本地分支中来。
在克隆仓库时，Git 通常会自动创建一个名为 master 的分支来跟踪 origin/master。这正是git push 和git pull 一开始就能正常工作的原因。当然，你可以随心所欲地设定为其它跟踪分支，比如origin 上除了master 之外的其它分支。刚才我们已经看到了这样的一个例子：git
checkout -b [分支名] [远程名]/[分支名]。如果你有 1.6.2 以上版本的 Git，还可以用--track 选项简化：
$ git checkout --track origin/serverfix
Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
Switched to a new branch &serverfix&
要为本地分支设定不同于远程分支的名字，只需在前个版本的命令里换个名字：
$ git checkout -b sf origin/serverfix
Branch sf set up to track remote branch refs/remotes/origin/serverfix.
Switched to a new branch &sf&
现在你的本地分支 sf 会自动向 origin/serverfix 推送和抓取数据了。
删除远程分支
如果不再需要某个远程分支了，比如搞定了某个特性并把它合并进了远程的 master 分支（或任何其他存放稳定代码的地方），可以用这个非常无厘头的语法来删除它：git push [远程名] :[分支名]。如果想在服务器上删除serverfix 分支，而不是删除commit，运行下面的命令：
$ git push origin :serverfix
To :schacon/simplegit.git
- [deleted]
咚！服务器上的分支没了。你最好特别留心这一页，因为你一定会用到那个命令，而且你很可能会忘掉它的语法。有种方便记忆这条命令的方法：记住我们不久前见过的
git push [远程名] [本地分支]:[远程分支] 语法，如果省略[本地分支]，那就等于是在说“在这里提取空白然后把它变成[远程分支]”。
分支的衍合
把一个分支整合到另一个分支的办法有两种：merge 和 rebase（译注：rebase 的翻译暂定为“衍合”，大家知道就可以了。）。在本章我们会学习什么是衍合，如何使用衍合，为什么衍合操作如此富有魅力，以及我们应该在什么情况下使用衍合。
基本的衍合操作
请回顾之前有关合并的一节（见图 3-27），你会看到开发进程分叉到两个不同分支，又各自提交了更新。
图 3-27. 最初分叉的提交历史。
之前介绍过，最容易的整合分支的方法是 merge 命令，它会把两个分支最新的快照（C3 和 C4）以及二者最新的共同祖先（C2）进行三方合并，合并的结果是产生一个新的提交对象（C5）。如图 3-28 所示：
图 3-28. 通过合并一个分支来整合分叉了的历史。
其实，还有另外一个选择：你可以把在 C3 里产生的变化补丁在 C4 的基础上重新打一遍。在 Git 里，这种操作叫做_衍合（rebase）_。有了
rebase 命令，就可以把在一个分支里提交的改变移到另一个分支里重放一遍。
在上面这个例子中，运行：
$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
它的原理是回到两个分支最近的共同祖先，根据当前分支（也就是要进行衍合的分支 experiment）后续的历次提交对象（这里只有一个 C3），生成一系列文件补丁，然后以基底分支（也就是主干分支master）最后一个提交对象（C4）为新的出发点，逐个应用之前准备好的补丁文件，最后会生成一个新的合并提交对象（C3’），从而改写experiment 的提交历史，使它成为master 分支的直接下游，如图 3-29
图 3-29. 把 C3 里产生的改变到 C4 上重演一遍。
现在回到 master 分支，进行一次快进合并（见图 3-30）：
图 3-30. master 分支的快进。
现在的 C3’ 对应的快照，其实和普通的三方合并，即上个例子中的 C5 对应的快照内容一模一样了。虽然最后整合得到的结果没有任何区别，但衍合能产生一个更为整洁的提交历史。如果视察一个衍合过的分支的历史记录，看起来会更清楚：仿佛所有修改都是在一根线上先后进行的，尽管实际上它们原本是同时并行发生的。
一般我们使用衍合的目的，是想要得到一个能在远程分支上干净应用的补丁 — 比如某些项目你不是维护者，但想帮点忙的话，最好用衍合：先在自己的一个分支里进行开发，当准备向主项目提交补丁的时候，根据最新的origin/master 进行一次衍合操作然后再提交，这样维护者就不需要做任何整合工作（译注：实际上是把解决分支补丁同最新主干代码之间冲突的责任，化转为由提交补丁的人来解决。），只需根据你提供的仓库地址作一次快进合并，或者直接采纳你提交的补丁。
请注意，合并结果中最后一次提交所指向的快照，无论是通过衍合，还是三方合并，都会得到相同的快照内容，只不过提交历史不同罢了。衍合是按照每行的修改次序重演一遍修改，而合并是把最终结果合在一起。
有趣的衍合
衍合也可以放到其他分支进行，并不一定非得根据分化之前的分支。以图 3-31 的历史为例，我们为了给服务器端代码添加一些功能而创建了特性分支 server，然后提交 C3 和 C4。然后又从 C3 地方再增加一个client 分支来对客户端代码进行一些相应修改，所以提交了 C8 和 C9。最后，又回到server 分支提交了 C10。
图 3-31. 从一个特性分支里再分出一个特性分支的历史。
假设在接下来的一次软件发布中，我们决定先把客户端的修改并到主线中，而暂缓并入服务端软件的修改（因为还需要进一步测试）。这个时候，我们就可以把基于
server 分支而非 master 分支的改变（即 C8 和 C9），跳过 server 直接放到master 分支中重演一遍，但这需要用git rebase 的--onto 选项指定新的基底分支master：
$ git rebase --onto master server client
这好比在说：“取出 client 分支，找出 client 分支和 server 分支的共同祖先之后的变化，然后把它们在master 上重演一遍”。是不是有点复杂？不过它的结果如图 3-32 所示，非常酷（译注：虽然client 里的 C8, C9 在 C3 之后，但这仅表明时间上的先后，而非在 C3 修改的基础上进一步改动，因为server 和client
这两个分支对应的代码应该是两套文件，虽然这么说不是很严&#26684;，但应理解为在 C3 时间点之后，对另外的文件所做的 C8，C9 修改，放到主干重演。）：
图 3-32. 将特性分支上的另一个特性分支衍合到其他分支。
现在可以快进 master 分支了（见图 3-33）：
$ git checkout master
$ git merge client
图 3-33. 快进 master 分支，使之包含 client 分支的变化。
现在我们决定把 server 分支的变化也包含进来。我们可以直接把 server 分支衍合到
master，而不用手工切换到 server 分支后再执行衍合操作 — git rebase [主分支] [特性分支] 命令会先取出特性分支server，然后在主分支master 上重演：
$ git rebase master server
于是，server 的进度应用到 master 的基础上，如图 3-34 所示：
图 3-34. 在 master 分支上衍合 server 分支。
然后就可以快进主干分支 master 了：
$ git checkout master
$ git merge server
现在 client 和 server 分支的变化都已经集成到主干分支来了，可以删掉它们了。最终我们的提交历史会变成图 3-35 的样子：
$ git branch -d client
$ git branch -d server
图 3-35. 最终的提交历史
衍合的风险
呃，奇妙的衍合也并非完美无缺，要用它得遵守一条准则：
一旦分支中的 提交对象 发布到 公共仓库，就千万不要 对该分支进行 衍合 操作。
如果你遵循这条金科玉律，就不会出差错。否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。
在进行衍合的时候，实际上抛弃了一些现存的提交对象而创造了一些类&#20284;但不同的新的提交对象。如果你把原来分支中的提交对象发布出去，并且其他人更新下载后在其基础上开展工作，而稍后你又用git rebase 抛弃这些提交对象，把新的重演后的提交对象发布出去的话，你的合作者就不得不重新合并他们的工作，这样当你再次从他们那里获取内容时，提交历史就会变得一团糟。
下面我们用一个实际例子来说明为什么公开的衍合会带来问题。假设你从一个中央服务器克隆然后在它的基础上搞了一些开发，提交历史类&#20284;图 3-36 所示：
图 3-36. 克隆一个仓库，在其基础上工作一番。
现在，某人在 C1 的基础上做了些改变，并合并他自己的分支得到结果 C6，推送到中央服务器。当你抓取并合并这些数据到你本地的开发分支中后，会得到合并结果 C7，历史提交会变成图 3-37 这样：
图 3-37. 抓取他人提交，并入自己主干。
接下来，那个推送 C6 上来的人决定用衍合取代之前的合并操作；继而又用 git push --force 覆盖了服务器上的历史，得到 C4’。而之后当你再从服务器上下载最新提交后，会得到：
图 3-38. 有人推送了衍合后得到的 C4’，丢弃了你作为开发基础的 C4 和 C6。
下载更新后需要合并，但此时衍合产生的提交对象 C4’ 的 SHA-1 校验&#20540;和之前 C4 完全不同，所以 Git 会把它们当作新的提交对象处理，而实际上此刻你的提交历史 C7 中早已经包含了 C4 的修改内容，于是合并操作会把 C7 和 C4’ 合并为 C8（见图 3-39）:
图 3-39. 你把相同的内容又合并了一遍，生成一个新的提交 C8。
C8 这一步的合并是迟早会发生的，因为只有这样你才能和其他协作者提交的内容保持同步。而在 C8 之后，你的提交历史里就会同时包含 C4 和 C4’，两者有着不同的 SHA-1 校验&#20540;，如果用git log 查看历史，会看到两个提交拥有相同的作者日期与说明，令人费解。而更糟的是，当你把这样的历史推送到服务器后，会再次把这些衍合后的提交引入到中央服务器，进一步困扰其他人（译注：这个例子中，出问题的责任方是那个发布了 C6 后又用衍合发布 C4’ 的人，其他人会因此反馈双重历史到共享主干，从而混淆大家的视听。）。
如果把衍合当成一种在推送之前清理提交历史的手段，而且仅仅衍合那些尚未公开的提交对象，就没问题。如果衍合那些已经公开的提交对象，并且已经有人基于这些提交对象开展了后续开发工作的话，就会出现叫人沮丧的麻烦。
读到这里，你应该已经学会了如何创建分支并切换到新分支，在不同分支间转换，合并本地分支，把分支推送到共享服务器上，使用共享分支与他人协作，以及在分享之前进行衍合。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：2349866次
积分：21116
积分：21116
排名：第254名
原创：370篇
转载：102篇
评论：277条
(6)(1)(2)(1)(1)(3)(1)(1)(3)(5)(4)(4)(5)(1)(4)(10)(5)(3)(8)(2)(2)(6)(4)(9)(5)(5)(16)(6)(20)(24)(18)(6)(8)(5)(1)(15)(4)(19)(35)(35)(21)(18)(21)(7)(2)(21)(31)(38)Git怎么推送本地分支到远程新分支上面去？ - 开源中国社区
当前访客身份：游客 [
当前位置：
你好，想跟你请教个问题：
&git怎么推送本地分支到远程新分支上面去？就是现在我想把目前的代码作为新分支推送到GIT上面去?谢了&
&因为今天的代码被我玩坏了，所以想新建一个分支专门玩代码的 ,但是又不想影响以前的代码。
共有5个答案
<span class="a_vote_num" id="a_vote_num_
git push origin local_branch:remote_branch
这个操作，local_branch必须为你本地存在的分支，remote_branch为远程分支，如果remote_branch不存在则会自动创建分支。
类似，git push origin :remote_branch，local_branch留空的话则是删除远程remote_branch分支。
<span class="a_vote_num" id="a_vote_num_
git push origin 本地分支名:远程分支名
--- 共有 3 条评论 ---
: 提交了没有
(6个月前)&nbsp&
: 肯定是你操作错了
(1年前)&nbsp&
这样不行，这样连MASTER分支的都会更改，我最后还是用版本回退实现功能了。
(1年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
引用来自“leo108”的评论
git push origin 本地分支名:远程分支名
好的，我试试
<span class="a_vote_num" id="a_vote_num_
git checkout local_branch
git push origin local_branch:remote_branch
<span class="a_vote_num" id="a_vote_num_
引用来自“leo108”的评论
git push origin 本地分支名:远程分支名
引用来自“KMSFan”的评论好的，我试试就是这样的，远程分支若不存在会自动创建
更多开发者职位上
有什么技术问题吗？
KMSFan...的其它问题
类似的话题博客访问： 2030702
博文数量： 261
博客积分： 15936
博客等级： 上将
技术积分： 24462
注册时间：
认证徽章：
Fedora-ARM
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： LINUX
当git仓库中存在远程分支，并同时用了一个本地分支去跟踪它的时候，我们通常会使用fetch或者pull从remote中抓取数据。首先我们先看看git fetch 和 git pull的区别：以下两篇为转载内容，人家已经讲的很好了，我没必要再废话：git fetch 与 git pull 都是从 remote 端取信息
在不接参数时，git fetch 与 git pull 有如下不同
1. git fetch 可以在一个 bare类型的repository内执行，而git pull 不可以
2. git fetch 只从远程端取repository信息，如新的branch，tag，及新的代码变化，也就是更新.git或bare型repository中的内容
From git://git.kernel.org/pub/scm/boot/u-boot/galak/u-boot
* [new branch]
-> origin/base
* [new branch]
-> origin/bootm
* [new branch]
-> origin/fsl_ddr
* [new branch]
-> origin/master
* [new branch]
-> origin/mpc85xx
* [new branch]
-> origin/origin
* [new tag]
DENX--2350 -> DENX--2350
* [new tag]
LABEL__0120 -> LABEL__0120
* [new tag]
LABEL__1735 -> LABEL__1735
但 git fetch 不会 checkout出任何代码
git pull 不仅会执行git fetch的操作，git pull 还做了merge的操作。Git中从远程的分支获取最新的版本到本地有这样2个命令：
1. git fetch：相当于是从远程获取最新版本到本地，不会自动merge
git fetch origin master
git log -p master..origin/master
git merge origin/master
以上命令的含义：
首先从远程的origin的master主分支下载最新的版本到origin/master分支上
然后比较本地的master分支和origin/master分支的差别
最后进行合并
上述过程其实可以用以下更清晰的方式来进行：
git fetch origin master:tmp
git diff tmp
git merge tmp
从远程获取最新的版本到本地的test分支上
之后再进行比较合并
2. git pull：相当于是从远程获取最新版本并merge到本地
git pull origin master
上述命令其实相当于git fetch 和 git merge
在实际使用中，git fetch更安全一些
因为在merge前，我们可以查看更新情况，然后再决定是否合并～～～～～～～～～～～～～～～～～～转载结束～～～～～～～～～～～～～～～～～～～～& &&& & 在含有工作副本的git仓库中可以使用git pull，在获取远程数据后，本地跟踪分支就可以快进，并和远程分支指向的commit点保持一致在bare仓库中只能使用fetch从remote中抓取数据，但是本地已跟踪的分支可能并没有快进到和remote同步的commit点，出现例如：tekkaman_b2 pushes to tekkaman_b2 (local out of date)如果需要本地分支快进，与remote同步，可使用以下命令：git fetch origin tekkaman_b2:tekkaman_b2
:&以上的命令可以解决本地跟踪分支与远程不同步的问题。这个方法在非bare仓库中同样适用，但是在实际的使用中存在特殊情况：在非bare仓库中fetch的特殊情况tekkaman@tekkaman-desktop:~/development/research/git/test1_g.git$ git branch
* tekkaman_b2
tekkaman@tekkaman-desktop:~/development/research/git/test1_g.git$ git fetch origin
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /home/tekkaman/development/research/git/test1
e3030a6..ba86b38 tekkaman_b2 -> origin/tekkaman_b2
tekkaman@tekkaman-desktop:~/development/research/git/test1_g.git$ git remote show origin
* remote origin
Fetch URL: /home/tekkaman/development/research/git/test1
Push URL: /home/tekkaman/development/research/git/test1
HEAD branch: tekkaman_b2
Remote branches:
master tracked
no_remote tracked
tekkaman_b1 tracked
tekkaman_b2 tracked
Local branch configured for 'git pull':
tekkaman_b2 merges with remote tekkaman_b2
Local refs configured for 'git push':
master pushes to master (up to date)
no_remote pushes to no_remote (up to date)
tekkaman_b2 pushes to tekkaman_b2 (local out of date)
tekkaman@tekkaman-desktop:~/development/research/git/test1_g.git$ git fetch origin tekkaman_b2:tekkaman_b2
fatal: Refusing to fetch into current branch refs/heads/tekkaman_b2 of non-bare repository
fatal: The remote end hung up unexpectedly
tekkaman@tekkaman-desktop:~/development/research/git/test1_g.git$ git checkout master
Switched to branch 'master'
tekkaman@tekkaman-desktop:~/development/research/git/test1_g.git$ git fetch origin tekkaman_b2:tekkaman_b2
From /home/tekkaman/development/research/git/test1
e3030a6..ba86b38 tekkaman_b2 -> tekkaman_b2
tekkaman@tekkaman-desktop:~/development/research/git/test1_g.git$ git remote show origin
* remote origin
Fetch URL: /home/tekkaman/development/research/git/test1
Push URL: /home/tekkaman/development/research/git/test1
HEAD branch: tekkaman_b2
Remote branches:
master tracked
no_remote tracked
tekkaman_b1 tracked
tekkaman_b2 tracked
Local branch configured for 'git pull':
tekkaman_b2 merges with remote tekkaman_b2
Local refs configured for 'git push':
master pushes to master (up to date)
no_remote pushes to no_remote (up to date)
tekkaman_b2 pushes to tekkaman_b2 (up to date)& & 从上面的实验中可以看出：在非bare的git仓库中，如果你要同步的本地跟踪分支是当前分支，就会出现拒绝fetch的情况。也就是说不可以在非bare的git仓库中通过fetch快进你的当前分支与远程同步。个人和我同事的理解是：如果本地数据被修改过了，这种同步的fetch会更改本地的文件（相当于fetch后再checkout到某个commit点），可能影响当前未提交的的工作。& & 但是暂时没有更多证据来证实我们的猜想。在网上找的的唯一参考：
阅读(14046) | 评论(0) | 转发(9) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。}