DEV Community

Cover image for Okay, but... what the hell is a Git?!?
oreo
oreo

Posted on

1 1

Okay, but... what the hell is a Git?!?

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.

The GitHub website's homepage, as of the 1st of February 2024

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.

'speedysnail' (speedy snail) being denied as a valid username, since it has been taken
'thespeedysnail' (the speedy snail) being accepted as a valid username, and a 'Continue' button that can be selected to proceed with creating the account

In perhaps the most hypocritical twist I've seen on the internet, we're now tasked with proving we're not a robot.

A CAPTCHA test that must be completed in the creation of this account by the user, to verify that they are not a robot

Rather adorably, you may then receive a 'GitHub launch code' email to verify your email address.
A partial screenshot of a 'GitHub launch code' email, which is sent containing a verification code. The email appears to read 'Here's your GitHub launch code!', followed by a larger, central rocket emoji of some kind, and 'Continue signing up for GitHub by entering the code below:'.

Once that's done, you can log into your freshly created account!
The GitHub login screen

You'll be immediately dumped to this Dashboard:
The GitHub dashboard on a newly created account
This is basically your GitHub homepage. Welcome!


Creating a new repository

Hit the button to create a new repository in the left pane.

The screen for creating a new repository and specifying its details on the GitHub website
Give it a sensible, mature name like the grown, functional member of society you are.
The term 'penis' being entered into the field for the repository name

You can also give your repo a description almost as respectable.
The phrase 'help me' being entered into the field for the repository's description

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!

How this freshly created repository looks without files; it guides the user and details steps on how to interact with it from a command line


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.
The four, larger, more central buttons shown to a new user when no repositories seem to be cloned in GitHub Desktop. The button at the top is blue, rather than grey, and reads 'Create a tutorial repository...'. The second button down reads 'Clone a repository from the Internet...' and appears to be selected. The one below this reads 'Create a New Repository on your local drive...', and the one below that reads 'Add an Existing Repository from your local drive...'. All four of these buttons have accompanying symbols / glyphs.
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.
Blue 'Clone' button next to grey 'Cancel' button

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:
GitHub Desktop 'No local changes' starting screen for newly cloned repo

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:
Two files, 'Ebb&FlowDemo.frsh' and 'index.html' appearing as having been added in GitHub Desktop's changes pane

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.
Section to the bottom left of GitHub Desktop that enables the user to input a summary and optional description. The summary field has, typed inside, the phrase 'initial commit', typical of initial commits, in which users may stage or add lots of files at once.
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

The GitHub Desktop app's display of 1 local commit ready to be pushed to the origin

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)

πŸ‘‹ Kindness is contagious

Please leave a ❀️ or a friendly comment on this post if you found it helpful!

Okay