190: Git: Keep Track Of Your Files As They Change. Part 5.

Programming involves change and managing that change is the only way to make sense of it. You’ll learn about submodules in this episode and how that enables you to reference code from other repositories. There’s a concept in programming called refactoring. I could spend several episodes about this one topic and will in future episodes. For now though, I’ll just say that you normally don’t want to repeat code. In other words, you don’t want similar or even the same source code spread out in multiple places in your project. That’s because if you ever need to change this code or fix a bug, then you need to make sure to change each location. It’s too easy to miss places. What you need is a way to use code from another repo inside your own repo. And Git has two options available for you. Listen to the full episode or read the full transcript below to learn about Git subtrees and Git submodules and why I prefer submodules. Transcript You’ll learn about submodules in this episode and how that enables you to reference code from other repositories. There’s a concept in programming called refactoring. I could spend several episodes about this one topic and will in future episodes. For now though, I’ll just say that you normally don’t want to repeat code. In other words, you don’t want similar or even the same source code spread out in multiple places in your project. That’s because if you ever need to change this code or fix a bug, then you need to make sure to change each location. It’s too easy to miss places. If instead that code was in a single place, and exposed as a class or even just a single method, then it can still be used in multiple places. But the code itself is now in a single place. Any changes or bug fixes can be made directly to the one spot. That’s a great way to design code to be reused throughout your project. It can be so useful that you might find yourself wanting to use the code in other projects too. Then what do you do? One option is to just copy the code into your new project and then make sure that it’s used from just that single location. You’ll soon realize that all you’ve done is take the same old problem and just made it bigger. You still have to remember all the other projects that might be using your code when it comes time to fix a bug. Another option is to just put all your projects in one big Git repository. That’s not a very good idea either. Maybe the code you want to reuse isn’t even your code. Maybe it already exists in another Git repository and you want to be able to benefit from any enhancements or bug fixes done to the original code. You don’t want to be copying it to your repository even if the license says that you can. What you need is a way to use code from another repo inside your own repo. And Git has two options available for you. I’m only going to briefly mention the first option and really should mention this option last because I’m not a big fan of using subtrees. The only reason to mention subtrees first is so we can move past it quickly. Git allows you to copy the code from another repo and include the files and folders as if they were part of your own repo. Any commits you make can include changes to your files as well as the files in the code that you’re reusing. It’s a simple solution that you don’t have to think about too much. It just works. But there’s a catch. When it comes time to update your borrowed code to pick up any bug fixes or maybe you want to contribute a few of your own changes back to the original repo, it becomes hard to separate your commits. Subtrees make it harder to update changes by pushing extra work onto the person doing the merging. I’ve seen professional software development teams use subtrees like this before and they ended up just giving up on merging and decided to only make changes t