Understanding Git subtree
From what I understand, it add the subrepo directly to the main repo. So any changes in that repo now local to the main repo.
Someone replied:-
Sounds like it yes. But wonder for example what it does if a commit contains both changes in your main repo and in the subtree repo.
The responsibility of not mixing super and sub-project code in commits lies with you.
Ughh, I just did 😅
with submodules you can't make that mistake
but git push subtree still work as expected. Only the changes to the subrepo get pushed, while the commit on the main repo contain both changes.
but that maybe because I added the subtree inside a versioned dir.
So this is it:-
[TIP] In order to keep your commit messages clean, we recommend that people split their commits between the subtrees and the main project as much as possible. That is, if you make a change that affects both the library and the main application, commit it in two pieces. That way, when you split the library commits out later, their descriptions will still make sense. But if this isn’t important to you, it’s not necessary. git subtree will simply leave out the non-library-related parts of the commit when it splits it out into the subproject later.
btw, subtree basically two things:-
- subtree merge strategy.
- git subtree wrapper command.
The subtree merge strategy has long exist in git. The wrapper command just making with subtree merge easier. Also, there's no yet official command git-subtree, the wrapper currently exists in contrib dir as a shell script.
So long2 ago, even before git subtree exists, there's already subtree merge strategy that allow you to merge external repo into your current repo using the read-tree command.
this kind of more powerful than the theirs merge strategy.
while theirs merge the external repo to the whole repo, subtree merge can be restricted to only specific directory.