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

在另一个 git 仓库中维护 git 仓库

发布于 2024-10-11 04:00:26 字数 200 浏览 1 评论 0原文

我想要的是：

REPO-A
  /.git
  /otherFiles
  /REPO-B
    /.git
    /moreFiles

我希望能够将 REPO-A 的全部内容推送到 REMOTE-A，仅将 REPO-B 内容推送到 REMOTE-B。

可能的？

原文

Here's what I'd like:

REPO-A
  /.git
  /otherFiles
  /REPO-B
    /.git
    /moreFiles

I want to be able to push all of REPO-A's contents to REMOTE-A and only REPO-B to REMOTE-B.

Possible?

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

扫码二维码加入Web技术交流群

发布评论

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

评论（10）

陌上芳菲 2024-10-18 04:00:26

听起来您想使用 Git 子模块。

Git 使用子模块解决了这个问题。子模块允许您将 Git 存储库保留为另一个 Git 存储库的子目录。这使您可以将另一个存储库克隆到您的项目中并保持提交独立。

It sounds like you want to use Git submodules.

Git addresses this issue using submodules. Submodules allow you to keep a Git repository as a subdirectory of another Git repository. This lets you clone another repository into your project and keep your commits separate.

回复 原文
暖树树初阳… 2024-10-18 04:00:26

我一直使用符号链接来维护两个独立且不同的存储库。

I have always used symlinks to maintain two separate and distinct repos.

回复 原文
又爬满兰若 2024-10-18 04:00:26

是的，您可以使用您绘制的文件层次结构完全按照您的要求进行操作。 Repo-B 将是独立的，并且不了解 Repo-A。 Repo-A 将跟踪它自己的文件和 Repo-B 文件中的所有更改。

但是，我不建议这样做。每次您更改文件并在 Repo-B 中提交时，您都必须在 Repo-A 中提交。 Repo-B 中的分支会与 Repo-A 混淆，而 Repo-A 中的分支会很不稳定（删除文件夹等时出现问题）。子模块绝对是最佳选择。

Yes, you can do exactly what you're asking with the file hierarchy you drew. Repo-B will be independant and have no knowledge of Repo-A. Repo-A will track all changes in it's own files and Repo-B's files.

However, I would not recommend doing this. Every time you change files and commit in Repo-B you'll have to commit in Repo-A. Branching in Repo-B will mess with Repo-A and branching in Repo-A will be wonky (trouble removing folders, etc.). Submodules are definitely the way to go.

回复 原文
九命猫 2024-10-18 04:00:26

您可以在父 A 存储库中使用 .gitignore 文件（忽略 B），但首先确保 B当前未跟踪 code> 存储库：在添加第二个 B 存储库之前提交父级 .gitignore。

You can use a .gitignore file in the parent A repository (ignoring B), but firstly making sure that the B repository is not currently being tracked: commit the parent .gitignore before adding the second B repository.

回复 原文
不再让梦枯萎 2024-10-18 04:00:26

对于在问题首次发布几年后来到这里的人们：

git subtree 就是您正在寻找的：

$ git clone https://..../REPO-A
$ cd REPO-A

# Create a remote alias for the REPO-B, for convenience
$ git remote add REPO-B  https://..../REPO-B

# clone REPO-B
$ git subtree pull --prefix=REPO-B REPO-B main --squash

# Develop as you wish, do commits to both REPO-A and REPO-A/REPO-B
# All changes will be pushed to REPO-A but not to REPO-B

# When/if you want to merge things back to REPO-B
$ git subtree push --prefix=REPO-B REPO-B main

# When you want to pull new changes for REPO-B just repeat the pull
$ git subtree pull --prefix=REPO-B REPO-B main --squash

如果其他人克隆 REPO-A，他们也将获得 REPO -B 的内容（与 git submodule 不同），但它们没有远程规范。对他们来说，REPO-A 就好像一个单一的存储库。

您可以在以下位置阅读有关 git subtree 的更多信息：https:// www.atlassian.com/git/tutorials/git-subtree

For people coming here a few years after the question was first posted:

git subtree is what you're looking for:

$ git clone https://..../REPO-A
$ cd REPO-A

# Create a remote alias for the REPO-B, for convenience
$ git remote add REPO-B  https://..../REPO-B

# clone REPO-B
$ git subtree pull --prefix=REPO-B REPO-B main --squash

# Develop as you wish, do commits to both REPO-A and REPO-A/REPO-B
# All changes will be pushed to REPO-A but not to REPO-B

# When/if you want to merge things back to REPO-B
$ git subtree push --prefix=REPO-B REPO-B main

# When you want to pull new changes for REPO-B just repeat the pull
$ git subtree pull --prefix=REPO-B REPO-B main --squash

If someone else clones REPO-A they will also get REPO-B's contents (unlike git submodule) but they won't have the remote spec. To them it'll be as if REPO-A is a single repository.

You can read more about git subtree at: https://www.atlassian.com/git/tutorials/git-subtree

回复 原文
暗恋未遂 2024-10-18 04:00:26

您可以通过使用“git-subrepo”来实现您想要的（REPO-A 存储库包含所有文件，包括文件夹 REPO-B 中的文件，而不仅仅是参考）：

https://github.com/ingydotnet/git-subrepo

如果您的某些贡献者没有安装 subrepo 命令，它仍然有效；他们将看到完整的文件夹结构，但无法提交对子存储库的更改。

You can achieve what you want (that REPO-A repo contains all the files, including those in folder REPO-B instead of only a reference) by using "git-subrepo":

https://github.com/ingydotnet/git-subrepo

It still works if some of your contributors don't have the subrepo command installed; they will see the complete folder structure but won't be able to commit changes to the subrepos.

回复 原文
美胚控场 2024-10-18 04:00:26

就我而言，我不想将存储库 A 与存储库 B 合并，因此存储库内的存储库工作得很好。只需仔细更新两个 repos 的 .gitignore 即可。
并确保在使用 git 命令时位于各自的目录中。

一些简短的说明：

  1. 两个 repos 将独立运行，因此无法合并。
  2. 父存储库将包含子文件夹和文件内的所有更改
    除非添加到其 .gitignore
  3. 子存储库将包含所有
    除非添加到其子文件夹和文件中，否则会更改
    .gitignore。
  4. 父级和子级的 .gitignore 文件将起作用
    彼此独立。
    因此，例如，如果您想忽略子存储库中的文件但想要
    要将其推送到父存储库中，只需将文件添加到子存储库的 .gitignore 中。
  5. 如果需要合并两个 repos，则上述指南将被视为无效。因此，在使用回购策略中的回购时，应适当研究整体情况。

In my case, I didn't want to merge repo A with repo B so the repo inside the repo works perfectly fine. Just carefully update the .gitignore for both repos.
And make sure to stay inside the respective dir while using git commands.

Some quick notes:

  1. Both repos will act independently and thus can not be merged.
  2. Parent repo will contain all the changes inside subfolders and files
    unless added to its .gitignore
  3. Child repo will contain all the
    changes inside its subfolders and files unless added to its
    .gitignore.
  4. Parent and Child's .gitignore files will act
    independently of each other.
    So, for example, if you want to ignore a file in the child repo but want
    to push it in the parent repo, just add the file in the child repo's .gitignore
  5. In case both repos need to be merged, the above guide will be considered invalid. So, the overall case should be studied properly to use the repo inside the repo strategy.
回复 原文
无妨# 2024-10-18 04:00:26

有很多选择，最好的选择取决于您的目的：

  • 如果希望将父级保留为不同应用程序的容器，并且其中一些最终可能成为存储库 ，只需使用裸 Git 将它们视为不同的存储库（没有子模块就没有子存储库）。无需了解更多 git 功能。

  • 如果您希望将父级保留为不同存储库的“项目”，并在管理不同协作者的访问时感到安全，那么对不同存储库文件夹使用符号链接的解决方案是一个不错的选择。再次强调，无需学习更多 git 功能。

说明：

如果其中一个应用程序成为存储库，只需在那里进行 git init，添加远程存储库并忘记 git 教程，然后将时间花在应用程序上。它只是工作，并且在父存储库中，提交对于其余应用程序来说仍然是原子的，有时会有额外的提交，是的，但是您不需要需要为每个提交提交parentA回购协议B。您可以对两个存储库应用不同的权限（尽管父级可以拥有 repoB 代码，除非您使用 .gitignore 忽略 repoB）。

Lots of choices, the best one depends on your purpose:

  • if want to keep the parent as a container of different apps, and some of them could eventually become repos, just use bare Git to treat them as different repos (no submodules no subrepos). No need to learn more git features.

  • if you want to keep the parent as a "project" of different repos and feeling safe on managing access for different collaborators, the solution of using symbolic links for different repo folders is a good option. Again, no need to learn more git features.

Explanation:

If one of the app becomes a repo, just git init there, add the remote repo and forget git tutorials and spend that time for the apps. It just work, and in the parent repo the commits can still be atomic for the rest of apps, and sometimes there will be extra commits,yes, but you do not need to commit parentA for each commit of repoB. You can apply different permisions on both repos (although parent can have repoB code unless you use .gitignore to ignore the repoB) .

回复 原文
痞味浪人 2024-10-18 04:00:26

还有一种方法可以处理这个问题。您可以将存储库（即子模块）放置为每个单独的独立存储库。并且可以创建到主存储库内的子模块存储库的软链接。

$ ls
$ main-repo submodule1 submodule2 

$ ln -s submodule1 main-repo/submodule1
$ ln -s submodule2 main-repo/submodule2

一旦列出了 main-repo 中的文件，就会列出子模块 SoftLinks

$ ls main-repo/
$ other-files submodule1 submodule2

There is one more way this could be handled. You can place the repos(that are submodules) as each separate independent repository. And can create softlinks to the submodule repos inside the master repo.

$ ls
$ main-repo submodule1 submodule2 

$ ln -s submodule1 main-repo/submodule1
$ ln -s submodule2 main-repo/submodule2

Once files inside main-repo are listed, the submodules SoftLinks are listed

$ ls main-repo/
$ other-files submodule1 submodule2
回复 原文
铁轨上的流浪者 2024-10-18 04:00:26

我发现最简单的是编辑 REPO-A 的 .git/info/exclude

$vim .git/info/exclude

它应该看起来像这样。刚刚添加了下面的最后一行。

# git ls-files --others --exclude-from=.git/info/exclude
# Lines that start with '#' are comments.
# For a project mostly in C, the following would be a good set of
# exclude patterns (uncomment them if you want to use them):
# *.[oa]
# *~
REPO-B/

Simplest I found is to edit REPO-A's .git/info/exclude

$vim .git/info/exclude

it should look something like this. Just added the last line below.

# git ls-files --others --exclude-from=.git/info/exclude
# Lines that start with '#' are comments.
# For a project mostly in C, the following would be a good set of
# exclude patterns (uncomment them if you want to use them):
# *.[oa]
# *~
REPO-B/
回复 原文
~没有更多了~

关于作者

鼻尖触碰

暂无简介

0 文章
0 评论
23 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

linfzu01

文章 0 评论 0

§对你不离不弃

文章 0 评论 0

可遇━不可求

文章 0 评论 0

枕梦

文章 0 评论 0

qq_3LFa8Q

文章 0 评论 0

JP

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文