在另一个项目中使用 Git 存储库中的项目

发布于 2024-10-18 05:43:37 字数 156 浏览 0 评论 0原文

我正在构建一个框架,以使一些常见功能(数据库连接)更容易,并希望在另一个项目中使用它。我总是可以复制并粘贴它,但我正在努力并不断扩展它。每当我在 Git 存储库中进行提交时,让它复制更新后的自身会容易得多。

我可以使用 Git 自动更新其他项目中的框架吗?还是必须寻找其他解决方案?

I have a framework I am building to make some common functions (database connection) easier and would like to use it in another project. I could always just copy and paste it, but I am working on it and expanding it constantly. It would be much easier to just have it copy its updated self over whenever I do a commit in my Git repo.

Could I use Git to automatically update the framework in my other project or will I have to find another solution?

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

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

发布评论

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

评论(2

梦屿孤独相伴 2024-10-25 05:43:37

使用 git 子树或 git 子模块。

上次我检查时,子模块有一些重大问题(但我听说它们在最近的版本中得到了一些改进)。请参阅此处了解详细信息:Git 子模块工作流程

简而言之:

子树是常规的 Git 分支,使用特殊的合并策略进行合并,将其所有文件放入主机存储库工作副本的子目录中。除了合并策略(仅在创建合并提交时才重要)之外,Git“子树”是一个完全正常的 Git 分支。

优点:

  • 不需要额外的工具支持,除非您需要从子树中提取新的更改,即使这样,所有支持都是 -s subtree 命令行选项(请参阅 此处了解完整的工作流程)。仅当您执行子树拉取时才需要记住子树。

缺点:

  • 所有子树提交都在宿主项目的历史记录中可见。
  • 不要将更改提交到子树所在的主机存储库目录,否则在下一个子树拉取时会遇到冲突。

子模块是主机存储库内的 Git存储库

优点:

  • 更清晰的历史记录,更好地与主机存储库分离。
  • 人们可以直接从子模块存储库直接提交到子模块上游(或者我认为是这样)。

缺点:

  • 对于每个(或许多)Git 命令,您都记得您正在处理带有子模块的存储库,以及许多令人讨厌的极端情况(或者当我查看时是这样)。处理存储库的每个克隆都需要特殊的工具支持。

免责声明:我对子模块有偏见。亲自尝试看看哪种方法更适合您的工作流程。

Use either git subtrees or git submodules.

Last time I've checked, submodules had some major issues (but I've heard that they were improved a bit in recent versions). See here for details: Git submodules workflow

In short:

Subtrees are regular Git branches, merged with special merge strategy, which puts all their files into a subdirectory of the host repository working copy. Aside of the merge strategy (which matters only when merge commit is created), Git "subtree" is a perfectly normal Git branch.

Pros:

  • No extra tool support needed, except when you need to pull in new changes from the subtree, and even then all support is the -s subtree command line option (see here for the full workflow). You need to remember about subtree only when you do the subtree pull.

Cons:

  • All subtree commits are visible in the history of the host project.
  • Don't commit changes to the host repository's directory where subtree lives in or face conflicts on next subtree pull.

Submodules are Git repositories inside the host repository.

Pros:

  • Cleaner history, better separation from the host repository.
  • One may commit directly to the submodule upstream from the submodule repository directly (or so I think).

Cons:

  • For each (or many) Git command you have remember that you're dealing with repository with submodules, lots of nasty corner cases (or so it was when I looked). Special tool support required to work with each clone of the repository.

Disclaimer: I'm biased against submodules. Try and see for yourself, what approach is better for your workflow.

短叹 2024-10-25 05:43:37

git 子模块。

在不同地方更新时您会遇到一些问题,但应该可以解决。

git-submodules.

You will have a few issues with updating in different places, but it should work out.

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