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
Author Of article : oreo Read full article
