Git started with Git - Shorts

[chrisreddington]

Planning to create a series of YouTube Shorts / TikToks focused on getting started with Git -

• What is Git / Why would you want to use it?
• Getting Git set up on your machine
• Setting up a new repository
• What is a branch? Why would I use it?
• Pushing local to remote
• Cloning a new repo locally
• What's a Pull Request?
• Baking in quality...
• Dealing with merge headaches
• What's going on behind the scenes?

[chrisreddington]

What is Git / Why would you want to use it?

Initial Script

Think of an important piece of work that you've been tasked with. Maybe an essay, a project plan, or... some code! And, you've finished it - so you've named it the 'Final' version.. My work Final.docx.

Buuut... then you spot another needed change. So you rename it to "My Work Final Final.docx"... And the loop goes on until you've submitted your completed piece of work. This approach does not scale, particularly in software development when filenames may have a particular meaning. Even more so when we try to scale this across a development team.

This is where version control comes in. Version Control is there to store 'stages' of a file over time. Imagine that you are a time traveller, and had the ability to revert files back to a given point in time. Not only that, but you could easily collaborate with other developers and bring your changes together.

There are different types of Version Control. Some, known as 'centralised', typically use a locking mechanism, so that developers have to 'check out' a file (e.g. like checking out a book from a library). When it's out, no one else can use it. Another format is 'distributed' version control, where each developer has a full copy of the codebase on their own machine. Rather than 'checking out' a file from a centralised repository, developers make changes in their local repository, and then 'merge' their changes into some authoritative upstream source.

Git is an example of a distributed version control system, as you have a full local copy of the codebase on your machine, and can sync the changes with some remote location.

So, in summary... Git enables you to be a time travelling, collaborating, software developer!

[chrisreddington]

Getting Git set up on your machine

You can think about Git like an extension to your file system, giving you capability to version changes over time, and store different 'areas' of code (known as branches). But these features aren't typically available in our native file system, so we first need to do some setting up on our machine!

Let's start by installing Git onto our machine! The steps will slightly change depending on our Operating System (available for Linux, MacOS and Windows). But in a nutshell, we need to download the installer and install it on our machine (or install from the appropriate package management tool).

Getting Git installed on your machine is one part of the puzzle. But, if you're not a fan of the command line - you might want an additional tool to help you out. Personally, there are two that I'm a fan of -

1. Visual Studio Code, which gives you editing capabilities as well as the Graphical User Interface support for interacting with Git.
2. GitHub Desktop, which gives you capability to interact with Git repositories on your local machine, and those hosted on GitHub as well.

There are plenty of other tools out there, which likely integrate with your favourite development tools. With that, you have Git installed on your machine! Stay tuned for another video on setting up a local Git repository, and key concepts!

[chrisreddington]

Setting up a new repository

Think of your favourite software project, maybe you're using PHP, Golang, .NET or another framework! You're probably storing that code in folders in a file system.

So what changes when you want to start using Git? Fortunately, not so much! Instead of storing our code in a folder, we store the project's assets in a 'Git' repository. But, a Git repository is just an enhancement to our local file system.

To create a new Git repository locally, we simply have to run the command git init. This special command creates a .git folder in that project folder. This magic .git folder is a bit like a database, and this is the magic behind different versions of our codebase. On a day-to-day basis, you don't need to interact with this folder though!

While we've created a repository, we haven't actually stored anything in it yet though! That is done in two phases.

1. Phase 1 - Staging files (i.e. letting Git know which files we intend to store in version control).
2. Phase 2 - Committing files (Actually storing those files in version control, and getting a hash in return). This hash that we receive is a unique indicator of this 'save' to Git. This is the identifier that we can use to 'time travel' between different versions of our codebase throughout time.

However, these 'committed' files are only on our local machine at the moment. What happens if our machine gets stolen, or the data gets corrupted? We've lost our files! We need to store them elsewhere, but more on that in another video!