推送新分支时git推送的输出

> git checkout -b new_branch
Switched to a new branch 'new_branch'
> git push
fatal: The current branch new_branch has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin new_branch

一个简单的git推送假设已经存在一个当前本地分支正在跟踪的远程分支。如果不存在这样的远程分支，而您想要创建它，则必须使用-u(——set-upstream的缩写形式)标志指定。

为什么会这样?我猜实现者认为在远程上创建分支是一项非常重要的操作，因此应该很难出错。Git push是你一直在做的事情。

“分支难道不是默认情况下推出的新更改吗?”我会说Git中的“一个更改”是一个提交。分支是指向提交的指针。对我来说，将push看作是将提交推到其他存储库的东西更有意义。推送哪些提交取决于您所在的分支以及该分支与远程上的分支之间的跟踪关系。

你可以在Pro Git书的远程分支章节中阅读更多关于跟踪分支的内容。

我无法这么快就从最初的开发人员那里找到一个基本原理，但我可以根据几年的Git经验给您一个有根据的猜测。

不，不是每个分支都是你想要推向外部世界的东西。它可能代表一个私人实验。

此外，git应该在哪里推送所有的分支?Git可以与多个遥控器一起工作，您可能希望在每个遥控器上有不同的分支集。例如，一个中心项目GitHub回购可能有发布分支;GitHub分支可能有主题分支供审查;本地Git服务器可能有包含本地配置的分支。如果git push将所有分支推到当前分支跟踪的远程，这种方案很容易搞砸。

实际原因是，在一个新的repo (git init)中，没有分支(没有master，根本没有分支，零分支)。

因此，当你第一次推送到一个空的上游回购(通常是一个空的)时，那个上游回购没有同名的分支。

And:

默认的推送策略是'matching'(推送所有同名的分支，如果它们不存在就创建它们)， 默认的推送策略现在是'simple'(从git 1.7.11开始，只推送当前分支，并且只有当它在上游有一个类似命名的远程跟踪分支时才会推送)

在这两种情况下，由于上游空回购没有分支:

还没有匹配的命名分支 根本没有上游分支(有或没有相同的名称!)跟踪与否)

这意味着你当地的第一个推送不知道:

推到哪里 推送什么(因为它找不到任何上游分支被记录为远程跟踪分支，和/或具有相同的名称)

所以你至少需要做一个:

git push origin master

但如果你只这样做，你:

将在上游创建一个上游主分支(现在是非空回购):很好。 不会记录本地分支'master'需要推送到上游(origin)'master'(上游分支):坏。

这就是为什么建议，在第一次推送时，做一个:

git push -u origin master

或者，使用Git 2.37和新的全局选项推送。autoSetupRemote:

git config --global push.autoSetupRemote true
git push

这将记录origin/master作为远程跟踪分支，并将使下一次推送自动将master推到origin/master。

git checkout master
# Git 2.23+
git switch master
git push

这也适用于“当前”或“上游”的推送政策。 在每种情况下，在初始git push -u origin master之后，一个简单的git push就足以继续将master推到右侧的上游分支。

你不知道，请看下面

我觉得这个“功能”相当烦人，因为我并不是想把火箭发射到月球上，只是推我该死的树枝。你可能也知道，否则你就不会在这里了!

下面是解决方案:如果你想隐式地推送当前分支，而不管该分支是否存在于原点，只要发出这个命令一次，你就永远不会在任何地方再次执行:

git config --global push.default current

如果你做这样的分支:

git checkout -b my-new-branch

然后做一些提交，然后做

git push -u

让它们回到原点(在那个分支上)如果分支不存在，它会为你创建这个分支。

注意-u位确保如果您稍后要从该分支进行拉取，则它们是链接的。如果您不打算稍后再拉这个分支(或者如果您这样做的话，可以使用另一个代码行)-u是不必要的。

HEAD是当前分支的缩写，所以git push -u origin HEAD工作。现在，为了避免每次我使用alias时键入这种类型:

Git配置——全局别名。pp 'push -u origin HEAD'

在此之后，每次我想通过git -b branch创建分支时，我都可以使用:

git pp

希望这能为别人节省时间!

第一次检查

步骤1:git remote -v //如果发现git初始化，则删除或跳过步骤2

步骤2:git remote rm origin //然后全局配置你的邮箱地址git

步骤3:git配置——全局用户。电子邮件“youremail@example.com”

步骤4:git初始化

步骤5:git commit -m "Initial Project" //如果已经添加项目repo，则跳过步骤6

步骤6:git远程添加来源%从bitbucket.org的回购链接%

步骤7:git push -u origin master

如果您第一次启用从新分支推送新更改。 和getting below error:

*git push -f
fatal: The current branch Coding_Preparation has no upstream branch.

要推动当前分支并将远程设置为上游，请使用

git push -u origin new_branch_name


** Successful Result:** 
 git push -u origin Coding_Preparation
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 599 bytes | 599.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote:
remote: Create a pull request for 'Coding_Preparation' on GitHub by visiting: ...
 * [new branch]      Coding_Preparation -> Coding_Preparation
Branch 'Coding_Preparation' set up to track remote branch 'Coding_Preparation' from 'origin'.

我刚刚经历了这个问题的进一步排列。

我有一个名为feat/XYZ-1234-some-description的分支，因为我正在处理Jira第1234版。在工作期间，我创建了一个新的Jira问题来跟踪一个较小的工作，当我来推送时，我决定推送到一个带有这个新问题编号的分支名称:

git push -u origin feat/XYZ-5678-a-different-description # failed

这给了我在这个SO线程中讨论的错误。但是，由于我试图推到与当前分支不同的分支名称，所以我的问题与这里描述的不同。我最终重命名了我的本地分支之前，我可以推它:

git branch -m feat/XYZ-1234-some-description feat/XYZ-5678-a-different-description
git push -u origin feat/XYZ-5678-a-different-description # now works

经过更多的阅读之后，我意识到我可以在 git push，可以是当前的分支名，也可以是HEAD，如果合适的话:

git push -u origin feat/XYZ-1234-some-description:feat/XYZ-5678-a-different-description # also works