通常,我会创建一个这样的分支:
git checkout branch
git checkout -b new_branch
它运行良好,因为它不会自动设置上游分支,因此它向我显示了推送设置上游的警告。我通常会复制它,然后它正确地跟踪一个远程分支......
那说它很麻烦......
所以我开始使用新方法来减少步骤量:
git checkout -b new_branch from_branch
不幸的是它给了我这个输出:
git checkout -b xxx origin/staging
Branch xxx set up to track remote branch staging from origin.
...
因此,当我尝试推送时,它给了我这个错误:
fatal: The upstream branch of your current branch does not match
显然上游不是我想要的那个......我宁愿让它自动添加origin / xxx或根本没有上游。
我看到有一个“--no-track
”选项;有没有办法让它成为默认值?我没有使用track选项获得成功。
答案 0 :(得分:4)
如您所述,git checkout
命令支持与--track
相同的--no-track
/ git branch
选项,因此要使新分支zorblatt
指向同一个提交为origin/master
,但没有origin/master
作为其(错误的)上游:
git checkout -b zorblatt --no-track origin/master
不幸的是,没有办法默认这一点。 (奇怪的是, 是git-gui,gui.matchTrackingBranch
的配置旋钮。)
(旁白:旧的动词,曲目,有点糟糕:"分支X跟踪远程跟踪分支Y / Z"很快就会出现#34; branch"和#34; ;跟踪"似乎不再意味着任何。"上游"是笨拙的,但至少不是来自冗余部门。)
答案 1 :(得分:1)
tl; dr:你可能想要git config --global push.default=upstream
,但是对于git push
执行的确切操作还有其他设置可能会更符合您的工作流程。
Git的默认值是一项持续的工作。执行裸git push
的操作曾经......好吧,它的C ++术语是“专家友好的”,它对于理解的人来说非常有意义,但对于仍然找到自己的腿的人来说却是一个惊喜。那么git添加了push.default
设置,以及各种“模式”,即决定裸git push
将做什么的方法,以及寻找并最终转换为不会引导新手的合理内容的想法抱怨他们在不知不觉中造成的伤害。
简短的形式是,新的出厂默认行为实际上是一个防儿童的上限,你只需要学会过去,它就会阻止那些不小心的人伤害自己。
如果您阅读the git push
docs,则会提到所有这些并指向git config
的{{1}}文档:
如果命令行未指定使用
push.default
参数或<refspec> ...
,--all
,--mirror
选项推送的内容,则命令会查找默认--tags
通过咨询<refspec>
配置,如果找不到,请尊重remote.*.push
配置以决定要推送的内容(有关push.default
的含义,请参阅git-config。)如果命令行和配置都没有指定要推送的内容,则使用默认行为,该行为对应
push.default
的{{1}}值:当前分支被推送到相应的上游分支,但作为安全措施,如果上游分支与本地分支的名称不同,则推送被中止。。
push.default
如果没有明确给出refspec,则定义git push应采取的操作。不同的值非常适合特定的工作流程;例如,在纯粹的中央工作流程中(即获取源等于推送目的地),上游可能就是你想要的。可能的值有:
没有 - 除非明确给出refspec,否则不要推送任何内容(错误输出)。这主要是针对那些希望通过始终明确避免错误的人。
current - 推送当前分支以更新接收端具有相同名称的分支。适用于中央和非中央工作流程。
上游 - 将当前分支推回到其更改通常集成到当前分支(称为@ {upstream})的分支。如果您要推送到通常从中拉出的相同存储库(即中央工作流程),此模式才有意义。
简单 - 在集中式工作流程中,如果上游分支的名称与本地分支的名称不同,就像上游一样工作,增加安全性以拒绝推送。
当推送到与您通常拉出的遥控器不同的遥控器时,请作为当前工作。这是最安全的选择,适合初学者。
此模式已成为Git 2.0中的默认模式。
匹配 - 推送两端具有相同名称的所有分支。这使得您正在推动的存储库记住将被推出的分支集合(例如,如果您总是在那里推送maint和master而没有其他分支,您推送的存储库将具有这两个分支,以及您的本地maint和master将被推到那里。
要有效地使用此模式,您必须确保在运行git push之前准备推出所有要推出的分支,因为此模式的重点是允许您推送所有分支一个人去。如果您通常只在一个分支上完成工作并推出结果,而其他分支未完成,则此模式不适合您。此模式也不适合推入共享中央存储库,因为其他人可能会在那里添加新分支,或者更新控制范围之外的现有分支的提示。
这曾经是默认设置,但不是因为Git 2.0(简单是新的默认设置)。
答案 2 :(得分:0)
--no-track
旗帜将成为你的朋友。当您使用checkout命令而不是branch命令创建新分支时,它将实现不跟踪远程分支的最终目标。
这只会为您节省三次击键,因此输入的内容仍然很多。您可以将它包装在一个git别名中以简化操作,这是我用于此任务的那个:
git config --global alias.nb '!bash -c "git checkout -b $1 --no-track ${2-origin/master}" -'
这接受2个参数并调出bash来完成操作。我们使用每个功能分支,并且(几乎)总是从master开始新的分支,所以我使第二个参数可选,并使用origin / master作为默认值。
要将HEAD用作默认设置,只需将${2-origin/master}
更改为$2
,或替换您自己的分支名称以适合您团队的工作流程。
用法:
git nb <branch-name> [<source-commit>]
答案 3 :(得分:-1)
效果很好,因为它没有自动设置上游分支
同时你是对是错。怎么可能?
那取决于你的git版本。
Git版本1.X将以与git v2.X不同的方式工作。
你上游取决于你用来创建分支的git版本。如果您使用1.X并创建了一个分支,而不是更新您的git版本并创建了一个新分支,它们将会表现不同。
您始终可以手动编辑.git/config
文件以查看跟踪分支。 git remote -v
会将它们打印到您的屏幕上。
git release notes 2.0
https://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes/2.0.0.txt
当
git push [$there]
没有说要推送什么时,我们已经使用了 传统的matching
语义到目前为止(所有分支都已发送 只要已经存在同名分支,就可以到远程控制台 那边)。在Git 2.0中,默认为
simple
语义,
正如您所发现的,--no-track
选项将创建一个没有上游的分支。
您可以创建一个孤儿分支(没有历史记录的分支),而不是使用cherry-pick为其添加所有需要的历史记录。
git checkout --orphan <new_branch> [<sha-1>]
现在您将清空历史记录,并且可以添加所需的任何提交。