You would also be required to add --allow-unrelated-histories in the merge command. I used that particular command to merge git repositories while preserving their individual histories. I didn't use git-subtree because we abandoned the original repositories.
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.
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...
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.
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?
Wondering what happens if you add subtrees without --squash and update it with --squash or vice versa, and what happens if you directly make changes in the subtree folder.
You can think of a subtree as just merging the history of another repo into yours, that's what it looks like in the git history, which makes 'git log's output look a bit confusing. Each time you update you'll get linkage to the history brought in. Squashing it usually makes sense if you don't care about the history between sync points. I have used submodules far more extensively than subtrees. In general if you can do a mono repo and avoid both, that's usually the best path.
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!
Good question and this is a topic of much debate. My preference is always to avoid subtrees and submodules if at all possible and just use a monorepo. There's so much more work when trying to break code out into separate repos and track that content at the super project level. The feasibility of that workflow is very project specific, so unfortunately I can't really recommend the best approach without talking to you about your project for about an hour lol. Thanks for watching!
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!
You can split the history of a repository out by directory, but that creates a brand new repo and isn't a subtree mechanism. See this vid: czcams.com/video/P5r_jONyuHo/video.html If you split your repo as desired, then you could easily make the public part a subtree of another project, if that's what you're ultimately after. Thanks for watching!
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...
The subtree state will be consistent in the mysim repo after it's been imported. Subsequent clones of mysim will get the same state of trick as when it was first imported. It will stay the same until the subtree is updated and that state is shared via push/merge with others. If you choose not to track trick at all, different developers could be using different states of trick, which could be a problem depending on your workflow.
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.
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
I don't think subtrees support that, but you could literally just merge two repos together and you'll end up with both repo's top level directory structure interleaved together. Of course then you can't push to the subtree remote anymore, not sure if that's a problem for your use case. Thanks for watching!
I dont have a video on it, but all you do is make one repo a remote of the other and then git merge one branch into another. You can merge any two git repos even if they have no common commits.
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.
C. I always recommend fewer repos if possible. Submodules are often (mis)used as a way to separate logically different content but that's usually a poor decision. Things that need each other to test should live in the same top level project unless there's a good reason they can't. Thanks for the kind words!
@@DanGitschooldude IMHO it strongly depends on a tooling at your exposure. From a single developer viewpoint I would agree. From an enterprise PoV with thousands of repositories, this would be bad from many different points. Licensing, compliance, security, etc, etc. There are tools to handle submodules. Zuul CI, Bazel, Gerrit, Repo, Jiri, etc. They are designed to work with a ton of separate repositories while on a surface they "feels" (DX) like a single monorepo.
Correction near 5:50 the second command (that I didn't even execute) should read 'git merge trick/master' not 'git merge origin/master'
You would also be required to add --allow-unrelated-histories in the merge command. I used that particular command to merge git repositories while preserving their individual histories. I didn't use git-subtree because we abandoned the original repositories.
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.
Thanks for the feedback!
Wow. The most transparent subtree explanation I have ever seen. Thank you so much! I will definitely subscribe.
Pls provide explaination on the git subtree split and git push subtree... thanks for the excellent content 🙏🏻
i'm quite of sad there is not a subtree push video
Hi, amazing!
Could you show us more about git subtree split and how to push just subtree and how to push the parent project?
Thanks for sharing it really help me while really concerning not loose the history of the log .
Very clear and understandable video!
Great Video! Very useful, thanks for sharing.
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...
using --squash would cause lots of merge conflicts when subtree add or pull
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.
0:56 git remote show origin
2:13 git subtree add
Thankyou!!
what about git subtree push? you know now that we have the trick subtree how can we maintain it if needed?
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?
Wondering what happens if you add subtrees without --squash and update it with --squash or vice versa, and what happens if you directly make changes in the subtree folder.
You can think of a subtree as just merging the history of another repo into yours, that's what it looks like in the git history, which makes 'git log's output look a bit confusing. Each time you update you'll get linkage to the history brought in. Squashing it usually makes sense if you don't care about the history between sync points. I have used submodules far more extensively than subtrees. In general if you can do a mono repo and avoid both, that's usually the best path.
@@DanGitschooldude So if a subfolder is a dependency that doesn't couple too much with the main repo, subtree will be a good choice for this folder?
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!
Good question and this is a topic of much debate. My preference is always to avoid subtrees and submodules if at all possible and just use a monorepo. There's so much more work when trying to break code out into separate repos and track that content at the super project level. The feasibility of that workflow is very project specific, so unfortunately I can't really recommend the best approach without talking to you about your project for about an hour lol. Thanks for watching!
@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!
You can split the history of a repository out by directory, but that creates a brand new repo and isn't a subtree mechanism. See this vid: czcams.com/video/P5r_jONyuHo/video.html If you split your repo as desired, then you could easily make the public part a subtree of another project, if that's what you're ultimately after. Thanks for watching!
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...
The subtree state will be consistent in the mysim repo after it's been imported. Subsequent clones of mysim will get the same state of trick as when it was first imported. It will stay the same until the subtree is updated and that state is shared via push/merge with others. If you choose not to track trick at all, different developers could be using different states of trick, which could be a problem depending on your workflow.
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.
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
I don't think subtrees support that, but you could literally just merge two repos together and you'll end up with both repo's top level directory structure interleaved together. Of course then you can't push to the subtree remote anymore, not sure if that's a problem for your use case. Thanks for watching!
@@DanGitschooldude do you have a demo for merging repository your demo on subtree really helped a lot
I dont have a video on it, but all you do is make one repo a remote of the other and then git merge one branch into another. You can merge any two git repos even if they have no common commits.
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.
C. I always recommend fewer repos if possible. Submodules are often (mis)used as a way to separate logically different content but that's usually a poor decision. Things that need each other to test should live in the same top level project unless there's a good reason they can't. Thanks for the kind words!
@@DanGitschooldude IMHO it strongly depends on a tooling at your exposure. From a single developer viewpoint I would agree. From an enterprise PoV with thousands of repositories, this would be bad from many different points. Licensing, compliance, security, etc, etc. There are tools to handle submodules. Zuul CI, Bazel, Gerrit, Repo, Jiri, etc. They are designed to work with a ton of separate repositories while on a surface they "feels" (DX) like a single monorepo.