如何将本地 git 存储库推送到远程 github 存储库中的分支？

Question

我的组织阻止了推动掌握。相反，我需要在 GitHub 上显式创建一个单独的分支，并将我的代码推送到该分支，然后创建拉取请求。

我的代码位于本地存储库中。我运行过的命令：

git init
git add .
git commit -s -m <my-commit-message>
git remote add origin <repo-URL>
git branch -M main
git pull // not sure if this is necessary
git checkout -b feat/dev // the remote branch name
git push -uf origin:feat/dev main

会发生什么：

错误：feat/dev 似乎不是本地存储库

我做了什么：

git push -uf origin main

会发生什么：

代码被推送到名为 main 的新分支，我无法打开拉取请求，因为这两个分支具有完全不同的提交历史记录。

---

我做错了什么？

---

编辑：

在此处添加我的组织所需的 GitHub 步骤(?)：

1. 在本地创建您的项目。运行它，调试它，使其运行没有错误。（如果你愿意的话，可以在本地使用 git；我总是这样做：D）
2. 提出请求（用于请求 GitHub 存储库的内部门户）
3. 指定您需要的存储库的名称
4. 这不是我必须做的事情，而是将其添加到此处：运行创建新存储库工作流程。这将创建一个包含 Readme.md 和票证审批者预先选择的许可证的存储库。默认分支（仍然）是 master。
5. 创建一个名为 <whatever-you-want> 的新分支
6. 将您的代码推送到该分支。
7. 提出审核请求（这是在 JIRA 上而不是 GitHub 上）
8. 审查代码后，通过选择在我创建的分支和主分支之间进行比较来创建新的拉取请求。

---

我一直为我的个人项目所做的事情：

1. 创建项目并测试它。
2. 跑步git init
3. 跑步git add
4. 跑步git commit
5. 打开 GitHub 并使用 master 分支创建一个新的存储库。
6. git branch -M main本地运行
7. 跑步git remote add origin
8. 跑步git push -u origin main

这总是将代码推送到主分支，并且工作得很好。

Answer 1

\n

我的代码在本地存储库中...

\n

\n

您还有一个现有的 GitHub 存储库，其中包含一些提交集？（这是一个问题，但根据这一点以上文本的其余部分，我将假设答案是“是”。）

\n

因为 Git 存储库是提交的集合，并且您的目标是添加提交（而不是创建独立的提交），所以您需要从克隆现有存储库开始，而不是创建一个新的空存储库。所以这部分是错误的：

\n

\n

git init\n

\n

\n

因为它用于创建一个新的空存储库。（这并不是完全错误，也不是不可挽回的错误：git clone从运行开始git init！我们将看看您可以做什么来恢复。）

\n

同时，我先回答一下这个问题：

\n

\n

我做错了什么？

\n

\n

\n

git add .\ngit commit -s -m <my-commit-message>\n

\n

\n

This part is OK, except for one problem: if you created a new, empty repository with the git init step, this made a single initial commit in this new, previously-empty repository. That\'s not what you wanted. You wanted to add a new commit to an existing repository.

\n

\n

git remote add origin <repo-URL>\n

\n

\n

(This is also something git clone would have done for you. You do need this step, but using git clone would make it easier.)

\n

\n

git branch -M main\n

\n

\n

This is only necessary if you made a new, empty repository earlier and when you made your first (and now only) commit, Git chose to create the branch name master, but you want to use the name main. You probably don\'t want any of this, really; when you use git clone, you\'ll get one branch of your own, and it will be based on the branch names in the repository you\'re cloning, which will take care of all of this.

\n

\n

git pull // not sure if this is necessary\n

\n

\n

What git pull does is two-fold:

\n

\n

1. It runs git fetch. That, too, is something git clone would have done for you. This is appropriate to do.

   \n
\n

2. It runs a second Git command to merge or rebase your work (your new commits) with / onto some existing work ("their" commits as obtained by the git fetch step). The default action here is git merge and that\'s not what you wanted, but in any case, pull requires an upstream setting and you won\'t have one, so this second command just fails entirely. That means it causes no harm either.

   \n
\n

\n

\n

git checkout -b feat/dev // the remote branch name\n

\n

\n

The git checkout -b option creates a new branch name without using any remote-tracking names. This, too, is not what you want. This created a new branch name for your lone root commit: you now have main and feat/dev.

\n

\n

git push -uf origin:feat/dev main\n

\n

\n

This won\'t work at all: the syntax for git push is:

\n

git push <remote> <refspec>\n

\n

and in your case, the remote part is just plain origin. That\'s the name you gave to your git remote add above.

\n

The somewhat scary term refspec is Git jargon, and for most users of git push, is overkill: what goes here is simply a branch name.

\n

When that didn\'t work ...

\n

\n

git push -uf origin main\n

\n

\n

Be careful with -f! This will overwrite any existing branch on the other (GitHub) end, if they accept the force option. If this is your own fork of some GitHub repository, though, you won\'t actually damage anything other than your own fork. (But you might damage your fork: if there was a main there before, now it\'s gone, replaced with your lone commit.)

\n

\n

Code gets pushed to a new branch named main and I cannot open a pull request for the 2 branches have entirely different commit histories.

\n

\n

Right: this sent, to your GitHub repository, your lone commit on main.

\n

Fixing the mess

\n

The exact fix will depend on several things:

\n

\n

• Do you have your own fork?

  \n
  \n
  • If not, was there a main in the GitHub repository before?
  \n
  • If so, did you wreck it?
  \n
  \n

  If there was a main and you wrecked it, and it was your own fork, you can definitely recover.

  \n

  If there was a main and you wrecked it and this was a shared GitHub repository, someone else may need to fix it. We\'ll leave the "shared repository, someone else needs to fix it" out entirely.

  \n
\n

\n

In any case, let\'s start by making a new clone. This isn\'t really required\xe2\x80\x94we could do all the fixing-up in your existing clone\xe2\x80\x94but it\'s probably the best way to go. To make a new clone of your GitHub fork, change to a new empty directory / folder on your laptop (or whatever computer you\'re using) and run:

\n

git clone <github-url>\n

\n

This does the git init / git remote add / git fetch stuff for you, creating a new Git repository by taking the URL and stripping off any final .git and leading slash stuff. By doing the clone into an empty directory, when the clone finishes, you\'ll have just one sub-directory here with one name, and that will be the new clone, so it will be really easy to find. (You can move it afterward.)

\n

Your new clone has copied all the commits from the GitHub repository, which I\'m assuming here is your own fork. Now, if you wrecked your fork\'s main, the next step is to fix that, and to do that we need to use git remote add to add the shared repository as a second remote. This part gets a little complicated and is only going to be used here for the fixing purpose:

\n

git init\n

\n

(If you don\'t need to fix anything up, you can skip this set of commands entirely. The git remote rm r2 step above tore down all the extra stuff and your fork should be back to the way it was before you wrecked it. If you wrecked a shared GitHub repo, get someone else to fix it as there\'s no guarantee that any of your own repositories have the right stuff in them any more, but someone else is almost certain to have what\'s needed.)

\n

Now that you have a good clone, you can get to work

\n

What you need to know:

\n

\n
• A Git repository is basically a big collection of commits.
\n
• Each commit stores a full snapshot of every file (frozen for all time so that one can get them all back, provided you have the right hash ID for the commit), plus some metadata, or information about that commit itself, such as who made it and when.
\n
• A Git repository also contains a collection of names: branch names, tag names, and something Git should call remote-tracking names. (Git actually calls them remote-tracking branch names, but the word branch here is, I think, just a bad idea.)
\n

\n

Git actually finds commits by their big, ugly, random-looking hash IDs. These are impossible for humans to work with, so we just don\'t. We use things like branch names. What the branch names do\xe2\x80\x94what Git gives us when we use them\xe2\x80\x94is that the name turns into the right hash ID. Git needs the hash ID. We give it a name (main or feat/dev) and Git looks up the hash ID from that.

\n

Now, the tricky part with git clone is this:

\n

\n
• git clone creates a new, empty repository (git init) that has no commits and no branch names;
\n
• then git clone adds a remote, named origin, and does a git fetch, which gets all of some other repository\'s commits; but
\n
• git clone does not create the same branch names in the new repository!
\n

\n

Instead, Git takes each of their (the remote\'s) branch names, like main and develop and feat/ure, and renames them. Your own Git repository, on your laptop, winds up with names like origin/main and origin/develop and origin/feat/ure. Each of these is a remote-tracking name and it\'s just a renamed copy of the other guy\'s branch names.

\n

When you run git fetch, your Git (your Git software running with your repository) reaches out to their Git (their software on their repository, whoever "they" are over at origin) and finds any new commits they have that you don\'t. Your Git brings those into your repository. Every commit gets a unique hash ID, so these have new unique IDs, never used before; they will never be used for any future commit either, so that the IDs Git sees here now are the right IDs forever. Your Git stuffs the new commits into your repository and updates your remote-tracking names.

\n

This way, your origin/main holds a memory of where their main was, the last time your Git reached out to their Git. Your remote-tracking names remember their branch names: both the name (with origin/ stuffed in front) and the hash ID. But these are not your branch names. That means you can create a branch name and not worry that it will get overwritten if someone else creates the same name in their repository.¹ Their branch hello becomes origin/hello, which can\'t possibly collide with your branch hello. Just don\'t name any of your branches origin/whatever.²

\n

Having run the initial git init, git remote add, and git fetch, your git clone now does one last thing: it creates one branch name for you. The branch name that git clone creates, in your new clone, is the one you specify with your git clone command\'s -b option, when you run:

\n

git clone -b xyz <url>\n

\n

But, wait a minute, we didn\'t run with a -b option. Now what?

\n

Well, absent the -b option, your Git software asks their (origin\'s) software which branch name their repository suggests. That\'s almost always main these days (and used to be master). So that\'s what comes out as the recommendation, and that\'s the one branch name your Git creates, in your repository.

\n

A branch name must select some particular commit. So the commit your Git chooses is the one named by your remote-tracking name that corresponds to the branch name here. If they recommended main, you have an origin/main remote-tracking name, remembering their main. That name specifies one particular commit. That\'s the one particular commit your Git uses to make your name main.

\n

The end result is that you get one branch in your new clone, matching one branch in the repository you cloned. It\'s all a very roundabout and complicated way of doing something ridiculously simple\xe2\x80\x94which is a good description of a whole lot of things that Git does.

\n\n

¹When using GitHub forks, this is not a real problem. But if you use Git the way it was before GitHub came along, it is a real problem: you might pick a branch name like fix-xyz-command, and Bob might pick the same name for a different fix for that command. So in real world situations, this was a problem, and remote-tracking names solved it. Within the GitHub world, it almost never comes up, though there are more complicated situations where it still can.

\n

²This is technically not a problem either, because your local branch names are in a separate name space. But while Git won\'t get confused if you name a local branch origin/main, you probably will, so just don\'t do it.

\n\n

Grabbing the code you worked on earlier

\n

You\'re probably ready now to create your feature branch in your new clone:

\n

git switch -c feat/dev\n

\n

or:

\n

git checkout -b feat/dev\n

\n

These both do exactly the same thing: they create a new name, feat/dev, that selects the same commit you have out right now (the one from main, probably). Then, having created this new name, they switch to that branch.

\n

Now you need to get the files from the other repository you made. There are several ways to do that, but one somewhat magical one is this:

\n

git --work-tree=/path/to/wrong/repo add .\n

\n

A more direct way is to just copy the files from the "wrong" repository\'s working tree into the new one\'s working tree, and then run git add . as you did earlier.

\n

I always like to run:

\n

git status\n

\n

and then:

\n

git diff --staged\n

\n

at this point, to check that I have the right files "staged for commit", and see what I have changed. Only then, having reviewed my work and checked it over for any obvious errors, do I run:

\n

git commit\n

\n

(or git commit -s³) and write up a commit message. This updates the current branch (now feat/dev) with the new commit, and now I can run:

\n

git push -u origin feat/ure\n

\n

to create branch feat/ure in my GitHub fork and make a pull request on GitHub (using gh, the GitHub CLI, or using the web site).

\n\n

³该-s选项进行签名提交。对于您或任何人所做的任何 Git 提交，任何人都可以声称自己是他们想要的任何人。我可以做出声称由 Barack Obama 或 Volodomyr Zelenskyy 撰写的承诺。有些人喜欢添加数字签名，使用PGP或GPG或ssh数字签名技术。这些可以（至少在没有量子计算机的情况下）用于验证这些实际上是由您而不是由冒名顶替者完成的。然而，我发现签署的承诺是严重的矫枉过正和痛苦；我更喜欢 Git 项目的简单签署官方发布标签的方法。

\n