I signed up for a college class thinking I’d be writing storylines for video games, but it is NOT that. So, I’m doing GitHub stuff and I am so confused.
I did a computer science fundamentals class last semester thinking it would be fun; it wasn’t. Technology is like magic mumbo jumbo and I cannot get a handle on it. Anyway, there are no other classes for summer I’m interested in, and I want to keep the credit hours I’ve signed up for.
What is a repository?
Commit?
Staging?
How does any of this work with coding? Or creating something?
And yes, I’ve watched the tutorials but I just don’t what these basics mean, and the videos just act like I should.
In: 9
Have you ever worked on a draft for a paper, or something, and saved a copy of your work? Then you add a few parts, not really sure you wanna keep them, so you save the file again, but you click “Save As…” instead of “Save” and keep it as a separate copy from the original? Then, at some point, you decide you don’t really like what you did, and you want to start over fresh from that original copy?
Maybe you end up doing this a lot. Each file has to have a unique name, so the place you keep your project starts piling up with files named something like `thing (3) (3) (final) (3) (actually final for real this time).docx`. Navigating this can be kind of hell if you take it too far. God forbid you have more than one file! It would be really nice if there was a kind of program that would do things like hiding all of the backup copies somewhere and only keeping the most up-to-date one around, but still allow you to jump back to any of your snapshots at any time…
That’s basically what **Git** does. Not GitHUB, or GitKRAKEN, just “Git”. Sorry if that’s confusing. I’ll get to that in a minute.
Git is, as lots of other commenters already pointed out, what they call a “version control” software. Its primary purpose is to, in a manner of speaking, take backup snapshots of your project from time to time, and keep the snapshots in a little filing cabinet for you. You tell it to “watch” a specific folder. Then, every time you tell it to save a snapshot, every single file in that folder (or only some of them, depending on how you set it up) will get saved in the snapshot. Even files within folders within folders all the way down, if you want. Then, as you work, if you ever want to “roll back” to one of your snapshots, you can do that. You just ask Git to open the filing cabinet and pull out the version of the project from the specific moment in history you ask it to. When it does this, all the files in the watched folder get replaced by the versions of the files that were there when the snapshot was taken. It doesn’t matter how many files changed, or how much they changed, or even if you added or deleted any files between snapshots. The folder will simply revert to whatever point in history you tell it to, like magic.
A **repository** in this analogy is the filing cabinet. Every project has a single filing cabinet where Git keeps all of that project’s snapshots. (It’s actually the folder called `.git` that gets created in the same folder as your project files. That’s where the snapshots live, along with some data Git uses to remember things like when they were taken and what order they come in.) A **commit**, when used as noun, is the fancy word for a snapshot. Using the word “commit” as a verb refers to the action of taking a snapshot.
Normally you would do this and all of the following actions in the command line. But if you’re not proficient or comfortable in the command line, there are several graphical user interface tools that will make interacting with Git easier, more like programs you’re probably more used to using with clickable buttons and such. **GitKraken** is one of these tools. There are many others, GitKraken is just one of them. It’s apparently the one you happened to stumble across first, either by your own research or because the people you are working with made you use it. It’s neither a strictly good nor bad thing, it’s just a different way to use Git.
Back to Git. Let’s say you edited your file a bit, and you’re ready to take a snapshot of it. Or, to use the proper terms, you’re ready to commit your changes to the repository. The first thing you have to do is stage your changes. What does that mean? Well, it’s mostly only useful in situations where your project has many files, not just one. Sometimes, after you’ve change several files since your last snapshot, you don’t want to save all of the changes in all of those files. You only want to keep some of them, you’re still on the fence with the other ones. That’s what the stage is for. When you **stage** a file, you are telling Git “next time I take a snapshot, only include these ones”. It’d be like… you’re at a family gathering, taking obligatory family photos, and someone suggests “okay, let’s do one of just the kids”. So you put only the kids in front of the camera. There are more people in the room than just the kids, but the kids are the only ones on the “stage”, so when the camera takes its snapshot, only the kids are in it.
So, this is all well and good. You have a fancy rollback tool now, and it can handle as many files as you want. Super. What else can it do?
Well, if you’ve ever worked on a long developed complex project, you’ll know that sometimes it can start going down several different paths simultaneously. Only the good ones will win in the end, but you might not know which one is the best one until you pursue a couple paths for a ways. You could say the project has “branched” out into multiple versions.
Git is designed with this feature in mind, too. Its snapshot history isn’t a straight timeline. You can branch that timeline like a tree. Say you make a commit at some point in your project, then start making some changes, and committing those changes. Then, you can roll back, start over, and go a different direction with new changes and new commits. You now have two branches of the project living in Git simultaneously, each one descended from that branching-off point. In fact, a **branch** is exactly what Git calls these. You can make as many branches as you want and Git will remember all of them, and you’ll be able to jump around to any of them at any point just like you would with the rest of your history.
The most important part, though, is that Git will let you take two different branches and **merge** them back together, incorporating changes from both branches into a single unified version. If the two branches changed totally unrelated parts of the project, Git can do this merging automatically. But if two parts of the project were modified in different ways, Git will dig its heels in the sand and go, “Okay, woah, hold up. I’m not made of magic. You’re gonna have to tell me which of these conflicting parts you want to keep.” They call this a “merge conflict” in the biz; kind of a pain if you don’t expect them and they tend to frighten new Git users, but keep in mind that what Git is really doing here: it auto-merges files together, but it marks the places where it needs an actual human to go in and referee things so it doesn’t clobber something it wasn’t supposed to.
Continued in part 2 below, sorry for length.
Latest Answers