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
This post is quite long, and it may all seem quite arcane and complex. I suppose it is. But after a while the basics will really feel relatively natural.
# Basics
Git is a version control system. A repository for files. Basically “a folder with timestamped versions of its content” – you can save folder state like you would save in a video game. Git was mostly made to work with plain text files (because code is mostly stored in plain text files), but it works with all kinds of files.
Why is this good? Because programming is hard, and programmers make mistakes, and it’s good to be able to come back to an earlier save. And for teamwork, but more on that later.
GitKraken is a git client – a software to use git with. There are many. Git by itself is used from the command line, which I wouldn’t recommend.
GitHub is a git hoster. It’s like a webmail website, but instead of for mails, it’s for git repositories. There are others, but github is the biggest and best-known one. Why does one need a git hoster? If one works alone, mostly as a backup, or to show/offer your code to others. But if you work in a team, the hosted (we say *remote*) git repository becomes the central repo you and your colleagues work on.
# In Practice (alone)
OK, so how does this work?
On your computer, you have a folder, and you create a git repository in that folder. Nothing changes; it’s still just a folder (technically, a hidden folder named “.git” is created in that folder).
Now when you add, delete, or change files in that folder, your git client will show you thse changes. Once you are at a point that you would like to save, you mark all the changes you want to save – this will be added, removed, and renamed files, and changes in files. This is called *staging*.
Once you’ve staged all your changes, you make a *commit*. That’s essentially a savegame of what is currently in your folder. You give it a comment (“made the login button pink”), and you click *commit*. Confusingly, both the savegame and the action of creating it are called *commit*. Or, put another way, you commit files to the repository, and this set of changes is then also called a commit. A commit is identified by a long cryptic combination of numbers and letters, its SHA1 hash. You don’t need to know what that is, just that this is basically the commit’s identity – like your social security number.
Then you continue working, and if you made a big mess, you can go back to any earlier commit. Or if you did something good, you make a new one.
# Teamwork
When you work in a team, you also *push* your commit to the *remote* repository (the copy of the repository that lies on github), so your colleagues also see all your changes.
And if a colleague made a change, you *pull* their changes down onto your computer, into your local git repository.
If your colleague made a change while you were also making changes, you will have to *merge* their changes into your repository. Git does this automatically in most cases: It takes your changed files and the colleague-changed files, and it automatically creates a *commit* which it helpfully calls a *merge commit*. This resulting commit is nothing special, it’s just a savegame that contains both your and their changes.
Sometimes, you and your colleague worked on the same file. You will get a conflict, and whoever of you was the last will have to *resolve* that conflict by looking at both versions of the file and creating one that makes sense (often choosing one version or the other).
In plain text files, git can understand when you worked on different lines of the file, and it will not generate a conflict, but merge the files together with your changes in the lines you changed and your colleagues’ in the lines they changed. This works surprisingly well.
In other types of files, images for instance, git can’t do that, and if both you and your colleague changed the file, you will have to pick which version gets to live.
When you’re done with the *merge*, you should *push* the merge commit, so your colleague can *pull* it.
# Branches
Branches are cool, but they’re not basic. I won’t get into them here.
Latest Answers