什么时候使用git子树? [英] When to use git subtree?

问题描述

git subtree解决什么问题? 我什么时候以及为什么要使用该功能?

我已了解到它用于存储库分离.但是，为什么我不只是创建两个独立的存储库，而不是将两个不相关的存储库合并为一个存储库?

此GitHub教程介绍了如何执行Git子树合并.

我有点知道如何使用它，但不知道何时使用(用例)和为什么使用，以及它与有何关系href ="https://git-scm.com/book/en/v2/Git-Tools-Submodules"> git submodule .当我依赖于另一个项目或库时，我将使用子模块.

解决方案

在'subtree'时，您应该小心地明确说明您在说什么>，因为这里实际上有两个独立但相关的主题:

git-subtree 和 git子树合并策略.

TL; DR

与子树相关的两个概念都可以有效地使您在一个仓库中管理多个仓库.与 git-submodule 相比，在后者中，元数据仅存储在根存储库中，格式为 .gitmodules ，并且您必须单独管理外部存储库.

更多详细信息

git子树合并策略基本上是使用您引用的命令的手动方法.

git-subtree 是一个包装Shell脚本，用于促进更自然的语法.实际上，这仍然是contrib的一部分，并且没有与常规手册页完全集成到git中.相反，将文档存储在脚本的旁边

以下是用法信息:

NAME
----
git-subtree - Merge subtrees together and split repository into subtrees


SYNOPSIS
--------
[verse]
'git subtree' add   -P <prefix> <commit>
'git subtree' add   -P <prefix> <repository> <ref>
'git subtree' pull  -P <prefix> <repository> <ref>
'git subtree' push  -P <prefix> <repository> <ref>
'git subtree' merge -P <prefix> <commit>
'git subtree' split -P <prefix> [OPTIONS] [<commit>]

当我计划编写自己的博客文章时，我遇到了很多有关子树的资源.如果我愿意的话，我将更新这篇文章，但现在这里有一些有关手头问题的信息:

您正在寻找的很多东西都可以在此Atlassian博客，由 Nicola Paolucci 的以下相关部分

:

为什么使用子树而不是子模块?

有几个原因 您可能会发现subtree更适合使用:

• 简单工作流程的管理很容易.
• 支持git的旧版本(甚至在v1.5.2之前).
• 超级项目的clone完成后，即可使用子项目的代码.
• subtree不需要存储库的用户学习任何新知识，他们可以忽略您正在使用subtree管理依赖项的事实.
• subtree不会像submodules那样添加新的元数据文件(即 .gitmodule).
• 可以修改模块的内容而无需 依赖项的独立存储库副本.

我认为缺点是可以接受的:

• 您必须了解新的合并策略(即subtree).
• 为子项目贡献代码upstream稍微复杂些.
• 在提交中不混用上层项目代码和下层项目代码的责任在于您.

我也很同意这一点.我建议您阅读这篇文章，了解它的一些常用用法.

您可能已经注意到他还写了一篇跟进此博客文章也非常有用.作者在混合中添加了他称为git-stree的第三个子树方法.这篇文章值得一读，因为他在比较这三种方法方面做得很好.他给出了自己对做什么和不喜欢做什么的个人看法，并解释了为什么他创建了第三种方法.

其他

• 列出git-subtrees
• 分离子目录

结束思想

本主题既显示了git的功能，又显示了当功能仅丢失标记时可能发生的细分.

我个人对git-submodule感到厌恶，因为我发现它使贡献者难以理解.我还希望在项目中对所有依赖项进行全部管理，以提供易于重现的环境，而无需尝试管理多个存储库.但是，git-submodule当前广为人知，因此意识到这一点并根据可能会影响您决定的听众而定显然是一件好事.

What problem does git subtree solve? When and why should I use that feature?

I've read that it is used for repository separation. But why would I not just create two independent repositories instead of sticking two unrelated ones into one?

This GitHub tutorial explains how to perform Git subtree merges.

I kind of know how to use it, but not when (use cases) and why, and how it relates to git submodule. I'd use submodules when I have a dependency on another project or library.

解决方案

You should be careful to note explicitly what you are talking about when you use the term 'subtree' in the context of git as there are actually two separate but related topics here:

git-subtree and git subtree merge strategy.

The TL;DR

Both subtree related concepts effectively allow you to manage multiple repositories in one. In contrast to git-submodule where only metadata is stored in the root repository, in the form of .gitmodules, and you must manage the external repositories separately.

More Details

git subtree merge strategy is basically the more manual method using the commands you referenced.

git-subtree is a wrapper shell script to facilitate a more natural syntax. This is actually still a part of contrib and not fully integrated into git with the usual man pages. The documentation is instead stored along side the script.

Here is the usage info:

NAME
----
git-subtree - Merge subtrees together and split repository into subtrees


SYNOPSIS
--------
[verse]
'git subtree' add   -P <prefix> <commit>
'git subtree' add   -P <prefix> <repository> <ref>
'git subtree' pull  -P <prefix> <repository> <ref>
'git subtree' push  -P <prefix> <repository> <ref>
'git subtree' merge -P <prefix> <commit>
'git subtree' split -P <prefix> [OPTIONS] [<commit>]

I have come across a pretty good number of resources on the subject of subtrees, as I was planning on writing a blog post of my own. I will update this post if I do, but for now here is some relevant information to the question at hand:

Much of what you are seeking can be found on this Atlassian blog by Nicola Paolucci the relevant section below:

Why use subtree instead of submodule?

There are several reasons why you might find subtree better to use:

• Management of a simple workflow is easy.
• Older version of git are supported (even before v1.5.2).
• The sub-project’s code is available right after the clone of the super project is done.
• subtree does not require users of your repository to learn anything new, they can ignore the fact that you are using subtree to manage dependencies.
• subtree does not add new metadata files like submodules does (i.e. .gitmodule).
• Contents of the module can be modified without having a separate repository copy of the dependency somewhere else.

In my opinion the drawbacks are acceptable:

• You must learn about a new merge strategy (i.e. subtree).
• Contributing code back upstream for the sub-projects is slightly more complicated.
• The responsibility of not mixing super and sub-project code in commits lies with you.

I would agree with much of this as well. I would recommend checking out the article as it goes over some common usage.

You may have noticed that he has also written a follow up here where he mentions an important detail that is left off with this approach...

git-subtree currently fails to include the remote!

This short sightedness is probably due to the fact that people often add a remote manually when dealing with subtrees, but this isn't stored in git either. The author details a patch he has written to add this meta data to the commit that git-subtree already generates. Until this makes it into the official git mainline you could do something similar by modifying the commit message or storing it in another commit.

I also find this blog post very informative as well. The author adds a third subtree method he calls git-streeto the mix. The article is worth a read as he does a pretty good job of comparing the three approaches. He gives his personal opinion of what he does and doesn't like and explains why he created the third approach.

Extras

• listing git-subtrees
• Detach Subdirectory

Closing Thoughts

This topic shows both the power of git and the segmentation that can occur when a feature just misses the mark.

I personally have built a distaste for git-submodule as I find it more confusing for contributors to understand. I also prefer to keep ALL of my dependencies managed within my projects to facilitate an easily reproducible environment without trying to manage multiple repositories. git-submodule, however, is much more well known currently so it is obviously good to be aware of it and depending on your audience that may sway your decision.

这篇关于什么时候使用git子树?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！