187: Git: Keep Track Of Your Files As They Change. Part 2.

Programming involves change and managing that change is the only way to make sense of it. You’ll learn about merging in this episode. With this knowledge, you can take your source code control system to a new level by going beyond just managing old versions. You’ll be able to try different things and incorporate just the pieces you want. And you’ll know how to work in a team. Merging is not the same as how traffic merges together on the road. There are two separate streams of cars that have no relation to each other that merge on a highway. The cars find openings to fit in and hopefully the other cars will be nice enough to allow those openings. Merging source code is different. You start out with something common. This is an older version of your file. That version of the file that’s common is what allows Git to figure out how to do the merging. Most of the time, you don’t have to do anything special. Listen to the full episode or read the full transcript below for a simple example of merging files. And don’t forget to subscribe to the podcast on iTunes, Google Play, Stitcher, or almost any other podcast directory. Subscribing lets you receive new episodes as they’re released. Transcript You’ll learn about merging in this episode. With this knowledge, you can take your source code control system to a new level by going beyond just managing old versions. You’ll be able to try different things and incorporate just the pieces you want. And you’ll know how to work in a team. Merging is not the same as how traffic merges together on the road. There are two separate streams of cars that have no relation to each other that merge on a highway. The cars find openings to fit in and hopefully the other cars will be nice enough to allow those openings. Merging source code is different. You start out with something common. This is an older version of your file. That version of the file that’s common is what allows Git to figure out how to do the merging. Most of the time, you don’t have to do anything special. Let me give you an example. Let’s say you start out with a file containing three lines of text, a, b, and c. That just means you created this file by typing the letter a, then the enter key, then the letter b and the enter key, and then the letter c and the enter key. Each letter is on it’s own line. A very simple file. It’s not programming source code but I can describe this a lot better than real source code. Listen to the previous episode for more information about text files. This file is going to form our starting point. You open the file and change the first line to aa instead of just a. You like that change, so you save the file and commit your changes in Git. I’ll explain what it means to commit your changes in another episode. For now, just know that committing your changes means that you let your version control software know that you’re done making changes and it can store the current version of the file where it’ll be kept safe. Now maybe this change you did to the first line is going to take some time to test. When programming, it’s always a good idea to test your changes to make sure they work as expected. I know, this is not a real programming file I’m explaining. Just pretend for a moment that changing the first line to aa is a big deal and could have unintended consequences. That doesn’t mean it’s a bad change. It’s just going to take a while to make sure everything’s okay. While you’re busy testing your changes, your manager lets you know about a critical bug affecting customers that has to be fixed right away. You need to drop everything and fix this new issue right away. You eventually track the problem down to the third line in the same file and realize that it really should have been cc instead of just c. Let me make one thing clear that may not be obvious right