One of the things I found most frustrating about Git, the most popular of version control systems, was simply trying to understand what it was. People would tell me about tagging, forking, merging, cloning, conflicts, branching… it was all very confusing. I wish there was something out there that gave a “for Dummies” intro to Git without getting into the nitty gritty. No code, no diagrams, no confusing jargon. Just the basics.
So, I wrote one.
Git, simply, is a way to write code with others, without getting in anyone else’s way.
First, you have to grab the code you want to work with. In the biz, this pile of code is called a repository, or repo. To get your copy, you clone the repo. And that’s exactly what you are doing; getting an exact copy of the code that you can alter on your own environment.
But what if you make changes to the same file someone else is in? This will generate conflicts. Oh no!
Git is smart enough to know this will happen. Think, for a moment, about a dance. Stepping on each other will happen. Git allows you to gracefully handle those mistakes. Instead of tumbling to the ground during your Brazilian Tango, you can stutter-step and continue on. Git tells you about those conflicts and it will allow you to merge your file to the ones in the original pile of code.
Once you’ve made your corrections, your conflicts are resolved. You can then commit your changes to the original pile of code. Committing is like printing a shipping label: you haven’t sent it yet, but you’re ready! Once you commit your code, you have to push it out to the original pile of code. That’s the equivalent of dropping that package in the mail box.
And really, that’s it. That’s the worst of it. You get some code, you change some code, and, if there are no problems, you send your changes back to the original.
There are, of course, more intricacies and nuances that I didn’t cover, but when you are starting with Git, that’s what you need to know.