SVN：外部在Git中相当于？ [英] SVN:externals equivalent in Git?

问题描述

我从另一个SVN仓库使用两个SVN项目，使用 svn：externals 。

如何在Git中拥有相同的存储库布局结构？

解决方案

< Git有两种类似的方法，但不完全等同于svn：externals：

$ b

• 子树合并

  strong>将外部项目的代码插入到您的仓库中的单独子目录中。这有一个详细设置过程，然后很容易其他用户，因为它在存储库检出或克隆时自动包含在内。这可以是一种方便的方法，可以在项目中包含依赖项。
  
  从其他项目中很容易地获取更改，但很难将更改提交回来。如果另一个项目必须从你的代码中合并，项目历史将被合并，并且两个项目实际上成为一个。
//help.github.com/submodules/rel =noreferrer> Git子模块 （ -r 的外部项>论据。子模块易于设置，但所有用户都必须管理子模块，这些子模块不会自动包含在结帐（或克隆）中。

尽管可以很容易地将更改提交回其他项目，但这样做如果回购变更可能会导致问题。因此，将修改提交回正在积极开发的项目通常是不适当的。

I have two SVN projects in use from another SVN repository using svn:externals.

How can I have the same repository layout structure in Git?

解决方案

Git has two approaches similar to, but not exactly equivalent to svn:externals:

• Subtree merges insert the external project's code into a separate sub-directory within your repo. This has a detailed process to set up and then is very easy for other users, because it is automatically included when the repository is checked out or cloned. This can be a convenient way to include a dependency in your project.
  It is easy to pull changes from the other project, but complicated to submit changes back. And if the other project have to merge from your code, the project histories get merged and the two projects effectively become one.

• Git submodules (manual) link to a particular commit in another project's repository, much like svn:externals with an -r argument. Submodules are easy to set up, but all users have to manage the submodules, which are not automatically included in checkouts (or clones).
  Although it is easy to submit changes back to the other project, doing so may cause problems if the repo has changed. Therefore it is generally not appropriate to submit changes back to a project that is under active development.

这篇关于SVN：外部在Git中相当于？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！