我做了一个 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别名与另一个命令结合使用时，它不能展开吗？
git 不会在命令行中的随机点扩展别名(这需要大量扫描并始终工作，并可能破坏分支 ref/etc 中别名词的任何用法(
你能得到的最接近你想要的东西是 git push -u origin "$(git this)" .
综上所述，除非您知道有理由手动指定远程和分支名称，否则您可能不需要这样做。
git push 的手册页说：
当命令行未指定使用参数推送的位置时，将参考当前分支的 branch.*.remote 配置以确定推送位置。如果缺少配置，则默认为源。
当命令行未指定要推送的内容时...参数或 --all、--mirror、--tags 选项，该命令通过查阅 remote.*.push 配置来查找默认值，如果未找到，则遵循 push.default 配置来决定要推送的内容。
git config 的手册页说：
远程。。推
git-push[1] 的默认 "refspec" 集。参见 git-push[1]。
和
推送默认
定义 git push 在没有显式给出 refspec 时应采取的操作。不同的值非常适合特定的工作流程;例如，在纯粹的集中式工作流中(即获取源等于推送目标(，上游可能是您想要的。可能的值为：
什么都没有 - 除非明确给出 refspec，否则不要推送任何东西(错误(。这主要适用于那些希望通过始终明确来避免错误的人。
当前 - 推送当前分支以更新接收端上具有相同名称的分支。适用于中央和非中心工作流。
上游 - 将当前分支推送回其更改通常集成到当前分支中的分支(称为@{upstream}(。仅当您推送到通常从中提取的同一存储库(即中央工作流(时，此模式才有意义。
简单 - 在集中式工作流程中，像上游一样工作，如果上游分支的名称与本地分支的名称不同，则增加安全性以拒绝推送。
当推送到与您通常拉取的遥控器不同的遥控器时，请按电流工作。这是最安全的选择，适合初学者。
此模式已成为 Git 2.0 中的默认模式。
- 匹配 - 推送两端具有相同名称的所有分支。这使得你正在推送的仓库记住了将被推出的分支集(例如，如果你总是在那里推送 maint 和 master 而没有其他分支，你推送到的仓库将有这两个分支，而你的本地 maint 和 master 将被推送到那里(。
要有效地使用此模式，您必须确保在运行 git push 之前，您要推送的所有分支都准备好被推出，因为此模式的全部意义在于允许您一次性推送所有分支。如果您通常只在一个分支上完成工作并推出结果，而其他分支尚未完成，则此模式不适合您。此外，此模式不适合推送到共享的中央存储库，因为其他人可能会在那里添加新分支，或更新您控制之外的现有分支的提示。
这曾经是默认值，但自 Git 2.0 以来就不是了(简单是新的默认值(。
因此，设置与您想要的git push行为匹配的任何push.default值(simple是最佳选择，但如果您的 git 太旧，那么upstream就像 current 一样好(，然后您可以使用git push(首先尝试git push -n以确认如果您想安全会发生什么(。