当前位置：文江博客话题详情

将远程分支获取到仅包含一个分支的现有存储库中

发布于 2025-02-12 02:57:27 字数 539 浏览 1 评论 0原文

我一直在克隆单个分支

git克隆-b v1.1.1 -single -branch [myrepo] .git

我已经进行了更改，实际上应该在分支V1.1.2上github。

我正在尝试将v1.1.2获取到我现有的存储库中，然后将我所有未承诺的文件从v1.1.1移动到v1.1.2

我尝试过：

git clone -b v1.1.2-- single -branch [myrepo [myrepo ] .git，

但获取

致命：目标路径[myrepo]已经存在，并且不是一个空目录

也是从目录中

git fet fetch v1.1.2

，但获取

致命：V1.1.2似乎不是Git存储库
致命：无法从远程存储库中阅读

任何人都可以帮助将另一个分支提供给现有仓库吗？然后将我的更改转移到新分支？

谢谢

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

御守 2025-02-19 02:57:27

您并没有真正“获取分支”（无论是什么意思：术语 branch 在git中是模棱两可的）。¹您真的很fet fetch consist em>。但是，在提交提交过程结束时，git提取 can 也可以在本地存储库中更新各种名称。通常这些是远程跟踪名称（git正式调用远程跟踪分支名称，但是那个可怜的单词 branch ，已经几乎被杀死了，在这句话中没有做任何有用的事情）。

我一直在克隆单个分支[via]
git克隆-b v1.1.1 -single -branch [myrepo] .git

这创建了git所谓的“单脑克隆”。那是一个克隆，其中git获取操作默认为：

从远程存储库中的单个特定分支名称中获取consits ;并
仅更新本地存储库中的一个远程跟踪名称。

git通过设置remote.origin.fetch（假设遥控器命名为Origin）到+refs/heads/v1.1.1：refs/remotes/remotes/oincom /V1.1.1。

我正在尝试将v1.1.2获取到我现有的repo

，换句话说，如果我们遵循git提供的模型（不是一个很好的模型，而是。）。这需要更改默认的获取设置。幸运的是，您无需直接使用remote.origin.fetch line（s）来做到这一点。 git Remote命令可以为您执行此操作：

git remote set-branches --add origin v1.1.2

将完成工作，添加正确的第二remote.origin.fetch line。

（旁注：v名称在许多存储库中都保留用于 tag 名称，而不是 branch 名称。但这只是一个约定，显然是一个您的存储库拒绝。 /code> git存储库中的分支在Origin中。

然后将我所有的所有文件从v1.1.1移动到v1.1.2

May 可能会有可能：您可以尝试运行git switch v1.1.2（使用- -猜猜模式基于v.1.1.2基于onement/v1.1.2）。但这可能是不可能的。（有关何时可能的血腥详细信息，请参阅当前分支上有未承诺的更改时，请结帐另一个分支。如果您不能切换，要么进行提交，也许使用git stash。代码> git switch -c 或git Checkout -b，然后提交，然后切换到v1.1.2，然后cherry cherry cherry pick pick the the the the临时提交分支。）

¹，由于术语 branch 的定义很差，我们可以说，我们获取的任何提议都是“分支”，然后我们提取了“一个分支” 。但这是定义 glory> glorory 。我发现整个事情不满意：太接近 begggggggggggg begggggge 的哲学谬论。也就是说，我们首先说“ git取出分支”，然后将“分支”定义为任何git提取的东西，而我们最终没有比开始时更明智的。

You don't really "fetch a branch" (whatever that would mean: the term branch is ambiguous, in Git).¹ You really fetch commits. However, at the end of the commit-fetching process, git fetch can update various names in your local repository as well. Normally these are remote-tracking names (which Git formally calls remote-tracking branch names, but that poor word branch, already nearly bludgeoned to death, is doing nothing useful in that phrase).

I have been cloning a single branch only [via]
git clone -b v1.1.1 --single-branch [myrepo].git

This creates what Git calls a "single-branch clone". What that is, is a clone in which git fetch operations default to:

fetching commits reachable from a single particular branch name in the remote repository; and
updating only that one remote-tracking name in the local repository.

Git achieves this by setting remote.origin.fetch (assuming the remote is named origin) to +refs/heads/v1.1.1:refs/remotes/origin/v1.1.1.

I'm trying to fetch v1.1.2 to my existing repo

What you want, in other words, is what we might call a "two-branch clone" if we follow the model Git provides (not a very good model, but...). This requires altering the default fetch setting. Fortunately, you don't have to fiddle directly with the remote.origin.fetch line(s) to do this. The git remote command can do this for you:

git remote set-branches --add origin v1.1.2

will do the job, adding a correct second remote.origin.fetch line.

(Side note: v names, in many repositories, are reserved for tag names rather than branch names. But that's just a convention, and apparently one your repository rejects.) After that, just run git fetch origin and origin/v1.1.2 will appear, assuming of course that there's a v1.1.2 branch in the Git repository over in origin.

then move all my uncommitted files from v1.1.1 to v1.1.2

That may be possible: you can try running git switch v1.1.2 (using the --guess mode to create a v.1.1.2 based on origin/v1.1.2). But it may not be possible. (For the gory details on when it's possible, see Checkout another branch when there are uncommitted changes on the current branch. If you can't just switch, either make a commit, or perhaps use git stash. I personally don't like git stash: I'd make a new branch first with git switch -c or git checkout -b, then commit, then switch to v1.1.2, then cherry-pick the commit made on the temporary branch.)

¹Since the term branch is so poorly defined, we could just say that whatever commits we fetched were "the branch", and then we fetched "a branch". But that's kind of the Humpty Dumpty way of defining glory. I find the whole thing unsatisfying: too close to the philosophical fallacy of begging the question. That is, we start by saying "git fetch fetches a branch", then define "branch" as whatever git fetch fetches, and we end up no wiser than when we started.

回复收藏 0 原文

短叹 2025-02-19 02:57:27

从现有存储库中，您可以从[myRepo] .git中获取所需的分支v1.1.2。 1.2 ）：

git fetch origin v1.1.2:v1.1.2

或者如果回购不称为Origin，则为

git fetch [myrepo].git v1.1.2:v1.1.2

的左：是要获取的分支/commit
的权利：是新的本地分支名称，

如果您省略：v1.1.2 part，则获取的提交将以fetch_head临时可用。
您可以将其用于运行git分支V1.1.2 fetch_head或git Checkout -B v1.1.2 fetch_head手动。

笔记：
如果您希望单支存储库在将来自动获取v1.1.2，则可能需要调整.git/config之后。

From within the existing repository, you can fetch the desired branch v1.1.2 from [myrepo].git into a new local branch with the same name (v1.1.2):

git fetch origin v1.1.2:v1.1.2

or if the repo isn't known as origin, then

git fetch [myrepo].git v1.1.2:v1.1.2

Left of : is the branch/commit to be fetched
Right of : is the new local branch name

If you omit the :v1.1.2 part, then the fetched commit will be temporarily available as FETCH_HEAD.
You could use that to e.g. run git branch v1.1.2 FETCH_HEAD or git checkout -b v1.1.2 FETCH_HEAD manually.

Note:
You probably want to adjust your .git/config after, if you want the single-branch repository to automatically fetch v1.1.2 in future.

回复收藏 0 原文

~没有更多了~