188: Git: Keep Track Of Your Files As They Change. Part 3.

Programming involves change and managing that change is the only way to make sense of it. You’ll learn about branching and what it means to commit your changes in this episode. Git is more than a system that allows you to checkout a file, make some changes, and then check it in again. That’s how libraries work. And when the book you want to read is already checked out by somebody else, you have to wait. Libraries also treat each book separately. Programming is different. First of all, the bits that make up a file can be copied as many times as you have hard drive space with no real limit to how many people can be working on a file at any time. And secondly, you’re most likely going to need to work with several files each time you make a change. For a large project and a large change, you might need to work with hundreds of files at a time. Git can handle all of this and it encourages you to make smaller changes and record those changes often. This makes tracking changes easier. The last thing you want is for your version control system to have an initial commit and then six months later a giant commit with a comment that says everything is now ready to release version 1.0 of your software. That’s exaggerating things quite a bit. And I’m also getting ahead of myself. Listen to the full episode to learn about branching, committing changes, and how you can use branches to manage your work. You can also read the full transcript below. Transcript You’ll learn about branching and what it means to commit your changes in this episode. Git is more than a system that allows you to checkout a file, make some changes, and then check it in again. That’s how libraries work. And when the book you want to read is already checked out by somebody else, you have to wait. Libraries also treat each book separately. Programming is different. First of all, the bits that make up a file can be copied as many times as you have hard drive space with no real limit to how many people can be working on a file at any time. And secondly, you’re most likely going to need to work with several files each time you make a change. For a large project and a large change, you might need to work with hundreds of files at a time. Git can handle all of this but it encourages you to make smaller changes and record those changes often. This makes tracking changes easier. The last thing you want is for your version control system to have an initial commit and then six months later a giant commit with a comment that says everything is now ready to release version 1.0 of your software. That’s exaggerating things quite a bit. And I’m also getting ahead of myself. Let’s go back to the beginning. I’ve worked with other version control systems before that would allow you to check out a file to make changes. The system would actually change every file in your project to be read-only and make you check out a file before it would allow you to save your changes. Many editors were perfectly happy to allow you to open these read-only files and even make changes to the file. I would sometimes forget to check out the file first and would be reminded when I tried to save my changes. That’s when the editor would complain that it couldn’t write the changes to a read-only file on disk. That’s also when I would switch over to the version control system to check out the file. As long as nobody else had changed the file, this was okay. But if somebody else had changed the file, then when I would check it out, my local copy of the file on disk would be updated with the latest changes. But those changes would not be included in what my editor was ready to write back to disk. Because I had no way to know what the changes were or how they might conflict with what I was about to write, I would usually choose to abandon my work and start over again. That’s not fun. Sometimes, if I had a lot of changes,