我创建了一个shell别名，我打算与其他命令一起使用：
this = "!f() { git rev-parse --abbrev-ref HEAD; }; f"
这个想法是它会输出我正在使用的当前git分支，并像这样使用它：
git push -u origin this
当我只运行别名时，它会正确输出当前分支，但是当我尝试使用它时，就像上面的例子一样，它给了我一个错误：
error: src refspec this does not match any.
error: failed to push some refs to 'myrepo.git'
如果我尝试使用相同的命令，但实际上写了分支名称（git push -u origin <branch>），那就可以了。
我做错了什么？当我将this别名与其他命令结合使用时，是否无法展开我的{{1}}别名？
答案 0 :(得分：2)
git不会在命令行中的随机点扩展别名（这需要大量扫描并始终工作，并且可能会破坏分支引用/等中的别名单词的使用。）
你能得到的最接近的是git push -u origin "$(git this)"。
git push的手册页说：
当命令行没有指定参数的推送位置时，将查询当前分支的branch。*。远程配置以确定推送的位置。如果缺少配置，则默认为origin。
当命令行未指定要使用...参数或--all， - mirror， - batgs选项时，该命令通过查询remote。*。push configuration来查找默认值，如果是没有找到，尊重push.default配置来决定推送什么。
git config的手册页说：
remote..push
git-push [1]的默认“refspec”集。见git-push [1]。
和
push.default
如果没有明确给出refspec，则定义git push应采取的操作。不同的值非常适合特定的工作流程;例如，在纯粹的中央工作流程中（即获取源等于推送目的地），上游可能就是你想要的。可能的值有：
没有 - 除非明确给出refspec，否则不要推送任何内容（错误输出）。这主要是针对那些希望通过始终明确避免错误的人。
current - 推送当前分支以更新接收端具有相同名称的分支。适用于中央和非中央工作流程。
上游 - 将当前分支推回到其更改通常集成到当前分支（称为@ {upstream}）的分支。如果您要推送到通常从中拉出的相同存储库（即中央工作流程），此模式才有意义。
简单 - 在集中式工作流程中，像上游一样工作，如果上游分支的名称与本地分支的名称不同，则可以更加安全地拒绝推送。
当推送到与您通常拉出的遥控器不同的遥控器时，请作为当前工作。这是最安全的选择，适合初学者。
此模式已成为Git 2.0中的默认模式。
- 匹配 - 推送两端具有相同名称的所有分支。这使得您正在推动的存储库记住将被推出的分支集合（例如，如果您总是在那里推送maint和master而没有其他分支，您推送的存储库将具有这两个分支，以及您的本地maint和master将被推到那里。
要有效地使用此模式，您必须确保在运行git push之前准备推出所有要推出的分支，因为此模式的重点是允许您推送所有分支一个人去。如果您通常只在一个分支上完成工作并推出结果，而其他分支未完成，则此模式不适合您。此模式也不适合推入共享中央存储库，因为其他人可能会在那里添加新分支，或者更新控制范围之外的现有分支的提示。
这曾经是默认设置，但不是因为Git 2.0（简单是新的默认设置）。
因此，设置push.default值与git push的所需行为相匹配（simple是最佳选择，但如果您的git太旧，那么upstream就像是current）然后您可以使用git push（首先尝试git push -n确认如果您想要安全会发生什么）。