为什么需要显式推送新分支？

我是新手，git正在练习。我创建了一个本地分支，但我发现当我这样做时，git push我的分支没有上载到存储库。我实际上必须这样做：git push -u origin --all。
为什么是这样？分支不是默认情况下要推送的新更改吗？为什么需要运行第二个命令？

实际原因是，在新的仓库（git init）中，没有分支（没有master，根本没有分支，零分支）

因此，当您第一次推送到一个空的 上游仓库（通常是一个裸仓库）时，该上游仓库没有相同名称的分支。

和：

• 在默认推送策略是“ matching”（推同名的所有分支，创建它们，如果它们不存在），
• 默认的推送策略现在为' simple'（仅推送当前分支，并且仅当它在上游具有类似名称的远程跟踪分支（从git 1.7.11开始）时才推送）

在这两种情况下，由于上游空仓库没有分支：

• 尚无匹配的命名分支
• 根本没有上游分支（具有或不具有相同名称！是否跟踪）

这意味着当地的第一推不知道：

• 在哪里推
• 推送内容（因为它找不到任何上游分支被记录为远程跟踪分支和/或具有相同名称）

因此，您至少需要执行以下操作：

git push origin master

但是，如果您仅这样做，则：

• 将master在上游（现在是非空仓库）上创建一个上游分支：好。
• 不会记录本地分支' master'需要推送到上游（origin）' master'（上游分支）：不好。

这就是为什么建议第一次进行以下操作的原因：

git push -u origin master

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

git checkout master
git push

这也适用于推送策略“ current”或“ upstream”。
在每种情况下，在执行initial之后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是没有必要的。

git push推送新分支时的输出

> 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 push假设当前本地分支正在跟踪的远程分支已经存在。如果不存在这样的远程分支，并且要创建它，则必须使用-u（的缩写形式--set-upstream）标志来指定。

为什么会这样呢？我猜想实施者会觉得在远程上创建一个分支是一项重大工作，以至于很难错误地做到这一点。git push是你一直在做的事情。

“默认情况下，分支不是要推送的新更改吗？” 我会说，Git中的“更改”是一个承诺。分支是指向提交的指针。对我而言，将推送视为将推送提交到其他存储库的想法更有意义。推送哪些提交取决于您所在的分支以及该分支与远程分支的跟踪关系。

您可以在Pro Git手册的“ 远程分支”一章中了解有关跟踪分支的更多信息。

我无法很快找到原始开发人员的理论依据，但是我可以根据几年的Git经验为您提供有根据的猜测。

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

此外，应该git push将所有分支机构发送到哪里？Git可以与多个遥控器一起使用，并且您可能希望在每个遥控器上具有不同的分支集。例如，一个中央项目GitHub存储库可能有发行分支；GitHub分支可能具有主题分支供审核；并且本地Git服务器可能具有包含本地配置的分支。如果git push将所有分支推送到当前分支跟踪的远程站点，则这种方案很容易搞砸。

HEAD是当前分支的缩写，因此git push -u origin HEAD可以工作。现在，为了避免每次我使用别名时进行此键入：

git config --global alias.pp'推-u origin HEAD'

之后，每次我想推送通过git -b分支创建的分支时，都可以使用以下命令推送它：

git pp

希望这可以为某人节省时间！

首先检查

步骤1：git remote -v
//如果找到git initialize，则删除或跳过步骤2

步骤2：git remote rm origin
//然后在全局配置您的电子邮件地址git

步骤3： git config --global user.email "youremail@example.com"

第4步： git initial

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

步骤6： git remote add origin %repo link from bitbucket.org%

步骤7： git push -u origin master

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

我有一个分支的名称feat/XYZ-1234-some-description是因为我正在研究1234年的Jira问题。在工作中，我创建了一个新的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

经过一番阅读之后，我意识到我可以src在上将 a设置为git push当前分支名称，或者HEAD适当时设置为：

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

如果您启用了第一次从新分支推送新更改。并出现以下错误：

*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'.