Introduction
So, here you are.
You've only lately started dipping your toes into the world of software dev.
You're enjoying it so far, but keeping track of each iterative update you make to your project has become maddening very quickly.
It feels a chore to manually manage different versions of your scripts and files, and keep track of the changes you make as your project evolves.
The hell-pits of yore
The solution I used most back when I was starting out was to simply save each iteration of my code as a new file, with its date and time in the filename.
Then, I would sort the containing folder by 'Date modified' to find the latest of the bunch. To anyone already familiar with Git, this will sound asinine.
This kind of thing became tedious and clunky very quickly.
Rather than simply tracking changes I made, this system had me creating copies and copies of the same few files, with minor differences between them, marked only by their dates and times in the filename, and, if I was feeling particularly sympathetic towards my future self, comments explaining what the bloody hell it was I'd actually changed.
In addition, as my projects grew, my solution did not. As I began moving on to focus on HTML, CSS and static webpages, this management became all the more complicated. I was now juggling files of different dates and times between servers and computers, and God forbid I wanted to work on anything at school.
It got to the point where I was honestly contemplating as to whether or not this 'development' stuff was even right for me.
It was then I decided. I was gonna bite the bullet and learn about all this fancy 'Git' stuff. It couldn't be that complicated... could it?
Why you should start using proper version control
If you're working like I once did, then I am telling you right here, right now, that it is time to stop. Yes, Janine, you. You too, John. I see you there. Your desk is a mess. Clean it.
My lack of a version control system put friction between me and my projects. It introduced a sort of 'inertia', whereby I felt so burdened by the need to keep track of my various files, iterations and upates that I was often deterred from making changes or updates at all.
Establishing a proper version control system like Git solves this issue, and does so beautifully.
It lets you write code, change your code, bop your code, twist your code, and will automatically register changes you make to any files to a 'commit', from which point Git gracefully handles the rest.
Sounds lovely, doesn't it?
The worries about version control and management more or less disappear, giving you the power to shift your focus back to where it should've been from the very start; making crap meme programs writing the best code you possibly can.
An introduction to Git
'Fine'. I hear you plead. 'I'm tired. I want change. I want to break free, but... what does any of this mean?!?'
You're in the right place. Let's cut the fat. We can work through this together. :)
What actually is Git?
Git is a version control system.
A version control system keeps track of the histories of files, and the changes we make to them. In our case, this tends to be our code!
So, put simply, version control systems (like Git) keep their own 'logs' of what we change in our files, where we change them, and when we make the changes.
Version control systems record changes to a file or set of files over time, so we can recall specific versions later (as said here in https://git-scm.com/book/ms/v2/Getting-Started-About-Version-Control).
What is a Git repo?
A Git 'repo' is just your project's folder (where you put your code), but with a special, hidden '.git' folder inside that keeps track of history and changes you make.
This makes Git really useful for collaborative work; you and your teammates or contributors can all have 'clones' of your repo, and these peers can all make changes on their own local machines, then send back the changes they make!
Send them back... to where?
Usually to a central, remote repo, hosted on something like GitHub!
If you're on this website, you've probably heard of GitHub. GitHub is basically a website you can use to host these remote 'repos' for your projects. They can be either private or public for all to see!
When you 'clone' a repo from GitHub, or a similar platform, you're essentially making a copy of the repo on your own computer. Then, you make your changes to this copy, acknowledge them with a Git 'commit', then 'push' your changes back to the origin, remote repo (from which you cloned your copy) in the form of these 'commits'.
Let's make an example to be clearer.
Let's say I'm building a website, right?
My project's code (my pages, assets, scripts, all that stuff) are all stored on GitHub's servers, inside my project's 'remote' repo.
On my computer, I've gone ahead and 'cloned' this repo; I've copied its contents and history, so I can make changes to them.
Then, once I'm done, I can 'commit' my changes (kind of like wrapping them up in a box and signing it with my name), and 'push' my changes back to the remote repo!
If any changes (commits) happen on the remote repo that aren't present on my local clone, I can 'pull' those changes to my local machine to bring it up to date with the remote repo.
Git is a 'distributed' version control system. What's that mean?!?
Git, rather than some other version control systems, is 'distributed' rather than 'centralised'.
This basically means that Git does not rely on a central server as a 'master' home for your code's history.
Unlike most 'centralised' systems, Git maintains a local copy of your project's repo, history and all, with history and version tracking abilities (https://en.wikipedia.org/wiki/Git), and does this locally on your own machine, regardless of wherever else the repo may exist.
Neither your own, local repo, or the remote repo hosted by GitHub, is a 'master' repo; they're both at parity and equality, as far as Git is concerned.
Your history is not just stored with a host like GitHub; it's stored on your own system, too. Then, when you're done making your changes (which you can make without internet!), you push them back to the remote repo on GitHub, and the changes are made there accordingly! Neat, huh?
Git and GitHub are not the same thing
The two have no affiliation in development. They're not made and maintained by the same people.
GitHub is just a website, on which people keep remote Git repos for their projects. GitHub is named after Git, but can manage a whole lot more than that: a project's 'issues', fancy things called 'pull requests', and all sorts of other mind-boggling features that we're probably not gonna get into here.
GitHub was acquired by Microsoft in 2018. As much as this annoys me given my disdain for many Microsoft efforts, I gave GitLab a shot earlier today and I really do prefer GitHub's user experience, though many swear by GitLab, and I'm silly.
It's important to keep in mind, though, that Git is independent of GitHub, and GitHub is not the only player in town.
If you felt so inclined, you could just have a local Git repository without any remote for changes to be pushed to, but in this guide, I'll walk you through the steps to get started with your first remote repo on GitHub.
Getting started
To get started, you'll need a GitHub account. Yes, yes, another account, but this one's important, promise!
Head to github.com, where, if you're in my depressing, generative-AI-obsessed age, you'll be presented with a screen like this.
Admittedly, I do think this graphic is quite pretty, assuming it was made by actual, expressionate organisms with emotional capacity.
Hit 'Sign up' in the top right corner, and you'll be taken to a screen where you can give another multi-billion dollar corporation your personal information.
Creating a GitHub account
Throw your email into the 'Email' field, then choose a secure password that you won't forget in ten minutes.
Once you're done contemplating about the fact that you're giving your email to yet another company for about the twelfth time this month, you can then start thinking about coming up with a username you won't hate.
While there's a chance there may be some repercussions of changing your username later on, it's possible to change it down the line, so you needn't worry too much. Just try not to be stupid about it, okay?
Then, you can most definitely read GitHub's Terms of Service, which you probably agree to have definitely understood in creating an account with them. Once you and your imaginary lawyer are finished, you can hit Continue.
If you're an unlucky sod, and your day has been ruined even further by some jackass who registered with your name on the 16th of March 2015 (only to make one contribution the same day and then leave) you may be forced to improvise.
In perhaps the most hypocritical twist I've seen on the internet, we're now tasked with proving we're not a robot.
Rather adorably, you may then receive a 'GitHub launch code' email to verify your email address.
Once that's done, you can log into your freshly created account!
You'll be immediately dumped to this Dashboard:
This is basically your GitHub homepage. Welcome!
Creating a new repository
Hit the button to create a new repository in the left pane.
Give it a sensible, mature name like the grown, functional member of society you are.
You can also give your repo a description almost as respectable.
Once you're done tweaking the options to your liking (like public visibility), you can click the big green 'Create repository' button!
Then, your repository will spring to life!
Actually interacting with (putting files into) your new GitHub repo
GitHub helpfully provides instructions for 'if you've done this kind of thing before'. If you haven't 'done this kind of thing before', though, don't fret. I'll walk you through it.
So, what you've just done is made a remote repository. Cool. But now you need to push your code to it.
It's showing us a bunch of commands to do this. We don't need to bother with these if we don't want; instead, we can install an app called GitHub Desktop.
Setting up GitHub Desktop
This does all the boring stuff for us; install it (https://desktop.github.com/download) and sign in with the same GitHub account.
If you're writing code, I trust in your ability to install a simple desktop app.
Cloning our remote repo onto our local machine
Once you're up and running with the app, you'll be presented with a 'Let's get started!' splash screen, from which you can select this 'Clone a repository from the Internet...' button.
Yep, we're doing the thing!
If you signed into the same GitHub account that has access to your newly created repository, it should appear in the list. Select it, then press Clone.
Once it's finished (this shouldn't take long given the fact that your repo is practically empty), you should be presented with a screen like this:
Hit 'Fetch origin' at the top. This basically checks to make sure that your clone (local repo) is up-to-date with the origin (remote repo on GitHub).
Now, by default, your GitHub Desktop app will have cloned your repo inside your Documents folder (usually inside Documents/GitHub/{your repo's name}).
Adding your code to your local copy of the repo
The next step is really tricky, but I believe in you. You now need to drag and drop your project's contents into this folder.
My project has two files: index.html for my homepage, and Ebb&FlowDemo.frsh.
You can see that, when I add them to my cloned repo's folder, they appear inside GitHub Desktop like so when I have the repo selected:
They have a plus (+) sign next to them because you've added them. Genius.
This'll be a yellow symbol if you've changed a file, or a red symbol if you've removed a file.
Selecting any of the files that the GitHub Desktop app has acknowledged as 'changed' will show you the differences (changes!) you've made.
Making your first commit (Committing your changes)
Once all your code is inside your cloned repo's folder, you can make your first 'commit'! This is basically tying together all the changes and putting them inside a little box to 'push' to your remote.
This box has a label on it, saying that you were the one who made the changes.
We can remember this the next time we contribute crap spaghetti code to a public project.
Give your commit a really creative, adventurous name (summary) in the box in the bottom left corner.
As you can see, mine is practically dripping with originality.
We don't really need to add a description here, but you can if you're feeling like even more of a unique unicorn than usual. Go on. Do it. I dare you, Georgina.
Hit 'Commit to main'.
'main' is the name of the 'branch' we're pushing our changes to, but this is super early on, so we won't delve into branches just yet.
Pushing our changes to the origin remote
And there we have it! Your first commit is done! We can now hit 'Push origin' to push our changes to our remote repo on GitHub!
If all goes well, we should then see your code inside the GitHub repo we created earlier in our browser!
Conclusion
And that's it! These are the very core, basic principles of Git and GitHub, in a nutshell!
Now, whenever you make your changes, rather than needing to make a new copy of your file or project, you can just make a commit, summarise what you've changed or updated, and, once you've finished building a new feature or squashing a bug, push it to the remote repo! How cool is that?!?
I hope you learnt something from this, and / or at least got a kick out of it. I hope I'm able to help someone with this. :)
GitHub is a vast platform of much functionality and many awesome projects, and I highly encourage you to have a poke around. :>
Thank you!
- oreo :)
copyleft the oreohive organisation | written and published to dev.to on the 1st of february 2025 | this work is licensed under CC BY-NC-SA 4.0 | attributions are required!
Top comments (0)