Correction near 5:50 the second command (that I didn't even execute) should read 'git merge trick/master' not 'git merge origin/master'

It would be great if you begin your videos with a summary of why this features exists in the first place, what's the use of it etc. Love your tutorials.

Very clear and understandable video!

Thanks for sharing it really help me while really concerning not loose the history of the log .

Pls provide explaination on the git subtree split and git push subtree... thanks for the excellent content 🙏🏻

Great Video! Very useful, thanks for sharing.

i'm quite of sad there is not a subtree push video

Wow. The most transparent subtree explanation I have ever seen. Thank you so much! I will definitely subscribe.

Hi, amazing! Could you show us more about git subtree split and how to push just subtree and how to push the parent project?

please pt2 for the git subtree commands!, this is very interesting. I want to know how to use subtrees tu push changes to several git repos, git pulls and so on...

0:56 git remote show origin 2:13 git subtree add

Thankyou!!

That was extremely informative and nothing like seeing it in action. Now time to get my hands dirty and use this. Also curious if there is a way for another user to pull down the refs to provide the history. I can see that being pretty valuable from time to time.

using --squash would cause lots of merge conflicts when subtree add or pull

Thanks for the tutorial. Other than git submodule and git subtree, I'm also checking out Git subrepo. The graph of the history however, is currently really beyond my understanding. It would be nice if git subrepo is covered as well.

@Dan Gitschooldude What if we have to clone project to existing directory and make it as subdirectory

Great vids Dan! I am just wondering if there's a way to subtree only selected directories from the trick repo? In my scenario, I have a private repo on Github which I kinda want to keep private, except the web directory that I would like to expose to webdevs. The logic that renders the web layer in the project lives in my private repo, but the webdevs will need to have some basic logic that can render the pages stored in the web directory they will work on, so the subtree looks like something I could use if I move the web directory to a separate repo, but in all subtree examples I have seen so far it is the contents of the whole repository that get included with subtree and it does not look like I can pick some directories and omit others. Or perhaps there's a way to do this? Any hints will be appreciated!

Hi Dan! Thanks for the great video. I have a quick question: is it best practice to keep the sub-project commits as part of parent's repository commit history? I have read it is best practice to keep super and sub-project code organized in separate commits. If a commit only contains changes to sub-project code, why should it stay as part of the parent history? If it shouldn't, what would be the best way to clean them from the log? Thanks!

Hey so I have a git repo called Projects where I have a bunch of subfolders with small toy projects. This repo includes my portfolio. How can I host my portfolio on heroku without having to include the entire repo?

what about git subtree push? you know now that we have the trick subtree how can we maintain it if needed?

Is there a way we can copy the same directory structure while creating a subtree. Right now if I use the subtree command it creates a folder and then copy all the code inside the folder. I dont want to do that and I want to keep the same directory structure and copy in the main folder

What if trick's master branch has changed when I clone the mysim repo? It isn't automatically update trick, right? I can't see the advantage... I don't want to have all the trick's files in my mysim repo...

Thanks for a great explanation of git subtrees and git submodules. I had never understood them with such great depth before. If we have a software project which consists of two (or more) "pieces", say one piece is a Chrome Extension, another piece is a CLI (which in this case is written as a Ruby gem, but it could be written as a Node.js module), such that the 2 pieces share common messaging between them, such that new features (i.e. messages) are being added historically in time, would you suggest to have : (A) the 2 pieces in 2 separate git repos, and keep them in sync using the same git tags in each, (B) have a super-project and add these 2 pieces as submodules or subtrees in the super-project, or (C) have one repo and put these 2 pieces simply as 2 subdirectories ? Both pieces are not "slow-moving 3rd party dependencies" but they are actually fast moving co-dependent projects.