(upbeat music)
- Hello, Qiskiters.
Today we're gonna be doing a GitHub 101 video
where we are gonna cover the basics
of what you need to know to get started with Git and GitHub.
But to get us started,
let's first clear up a few things
around what actually is the difference
between Git and GitHub.
They're quite similar concepts
and people often get them confused.
So Git is what's called a version control software.
It's an open-source software
that you can install locally on your machine,
on your laptop.
It is a command line tool,
so that basically means
that you interact with it via your terminal.
And essentially what it is,
is a tool for managing different versions
of edits to your files,
so you can track over time
who has changed which different lines
within any given code file that you have.
GitHub, on the other hand, is software as a service.
It is hosted on the web.
It has a graphical user interface
that you might be familiar with.
And it's essentially a platform
that provides the space to store those versions
and that history of code changes that is powered by Git.
So you use Git to communicate with GitHub.
Git is the technology
that facilitates the tracking of the changes
and GitHub is the platform
that keeps all of that information in one place for you.
So let's get started with our friend Alice here.
Alice has an online GitHub account,
and in that GitHub account,
she has one code repository called test-repo
or otherwise known as a repo for short.
This repository is essentially a folder
that contains different code files for that project.
And this is what it might look like
on the GitHub platform itself.
If you are like Alice and you like it in dark mode,
it will be this dark color. It might look a bit different
if you prefer light mode on your machine.
And the version of the test-repo code that we see here
is the main branch.
GitHub uses,
and Git uses branching as a metaphor
to describe the lifecycle of your code.
So you can kind of imagine your code repo is a tree
that is constantly growing and changing.
Your main branch here is your default branch,
it's the main trunk of that tree
and it tracks a timeline of your code.
It's sometimes also referred to as the master branch.
And we can track the history of code on this main branch
by building up a history of commits.
You can kind of think of commits like checkpoints.
It keeps a log of the changes that you've made
so you can go back to them if you need to.
So Alice can go to to her commit tab on GitHub
and see a historical log of all of the changes
that she has made throughout the history of her code,
ever since that very first commit
that she made at the start.
It's good practice to commit little and often.
Each commit could be just a small change
that touches only one file
or it could change a lot of files,
but it's better to have those commits be small,
maybe only touching one or two files,
so that when you go back and look at your history,
it's easier to see, where did something go wrong?
Oh, you changed like,
at this commit, you changed these couple of files
and that's where a problem occurred.
Each commit also has a long ID like this
called a commit hash,
but we don't really need to worry
about that too much as users,
what we really care about are the commit messages,
which are human-readable messages
to kind of describe a bit about what was changed
in that file.
There's a lot of best practices
around how to write good commit messages
and you can find information online
on different ways of doing it,
but basically you want to summarize
as succinctly as possible
what key things that you did in that piece of work.
So did something is a bad commit message,
it doesn't really tell me what happened there,
whereas something like added hello-world file
is much more explicit in telling me
what changes actually in that commit.
Next up, I wanna talk about branching.
So as we've spoken about already,
the kind of history of a repo can be kind of represented,
kind of like a tree,
where we have our main branch being the trunk of that tree.
But just like any other real tree,
we can have different branches of that,
which represent different offshoots of our code.
So for example,
let's say our friend Alice wants to develop a new feature
without breaking stuff that's kept in that main branch,
or maybe she's working with her friend Bob
and they don't want to interfere with each other
in the work that they're doing.
So what Alice can do is she can make branches
for each feature that she is working on
and Bob could do the same.
And this is generally a good practice,
and you wanna keep your main branch
for the final production-ready features of your code.
And in the GitHub kind of platform,
you can see in your branches tab
a list of all the branches that you have
and who was the last person to update them.
Okay, so we've spoken a bit about
what those repositories look like,
what the code is,
as it currently exists on GitHub.
But let's say for example,
Alice gets a new laptop and she wants all of the code
that she kept in her test-repo in GitHub on her new laptop.
All of that code that she was previously working with
that we were showing you
was kept in the GitHub platform in the cloud,
and we call that her origin repository.
But she has this new laptop,
it doesn't have any of her code on it,
so what she's going to need to do
is she's going to need to clone that origin repo
onto her local machine.
And to do that, it's very simple,
she can go into her GitHub platform.
On the homepage,
there's a big green button that says Code
and that gives you instructions on how to clone your repo.
Then what she can do is go to her terminal
on her local machine, on her new laptop,
and then she can type in git clone
and then the URL of the repo
that she wants to get a copy of onto her machine.
And what this does is it essentially makes a copy
of all the code that was hosted on the GitHub platform
and copies that to her local laptop.
From there,
now Alice has a local copy on her machine of her code
that is now free for her to do local development work with
in the way that she might normally do
in her favorite code editor.
And these two repos now,
her origin, her remote origin repo,
and her local repo will now evolve separately.
It's also always a good idea when you're working locally,
once you've cloned,
just make sure that you've actually moved
into the right project repo
so you can start working in your terminal
in the right place.
Depending on how your terminal is set up,
you might also get some helpful information here,
like which branch you're working on.
By default, when you clone your repo
and then you move into that,
Git will kind of show
that you are working in the main branch.
But for example,
let's say that Alice wants to move between branches.
She doesn't wanna work on her main branch,
she wants to move into a different branch.
She can do that with the git checkout command.
So she just types in git checkout
and then the name of the branch she wants to move into.
And then you can see now she's moved into that new branch,
and any work she does will only make changes on that branch,
it won't make changes in main where she was before.
If she wants to create a new branch,
she can do that by adding the -b flag when she checks out.
So if she does git checkout -b new-branch,
this will create a new branch for her called new-branch
branching off of main
and it will also kind of move her into that branch,
so when she does any code work,
she'll be working in that branch.
And now that she's in her new branch,
she wants to start working on things,
and she can start making code changes
and also building up more of that commit history
that we mentioned earlier.
So maybe she wants to add a Hello World file.
So to do that, she adds that file,
but then to make that log actually appear
in her commit history,
she has to do git add and then the name of the file.
And then like we saw earlier,
each commit has to have a commit message that goes with it.
So what Alice will do
is then she will type in git commit -m
followed by whatever message
that she wants to add to show what she's done.
So in this example here,
she's made changes in her Hello World file.
She has added Hello World to a staging area,
and then she's committed that by adding a message as well.
And she can do this with multiple files.
Maybe she made changes to different files,
then she would add the files twice,
git add hello-world and maybe git add hello-new-world,
and again, write a commit.
So you can have multiple files
associated with a single commit.
If you've added,
if you've changed a lot of files
and you want to add all of them to your commit history,
you can use git add and then a full stop,
which will add everything that's kind of been changed
into a single commit for you.
And if at any point you wanna check what changes you've made
and what's actually in your staging area
waiting to be committed,
then you can type in git status
and the terminal will print out a list of files for you
of things that are changed
and are ready to be added to a commit.
Okay, so next up,
now she has some new features that she's worked on
in her local machine that's in her new branch,
but now Alice wants to update her repository
in her GitHub account
with the changes that she's made locally.
Because remember, at this point,
her local repository and her origin repository in GitHub
have been evolving separately.
Everything she'd been doing has been
in her local new-branch,
but now she wants to update the repository in GitHub
with those changes.
So to do that, she needs to make a connection
between her local repository and her origin repository.
And to do that, she needs to add her origin
as a remote for her machine.
She can do this with git remote add origin,
followed by the same URL
that she used to clone the repo before.
And then she can check that she's added it.
And then once she has that new branch
ready to be added to her origin repository,
she can then do git push origin new-branch,
and that will mean that now her remote origin repository
is up to date with the latest work that she's done
in that new branch.
So once you've done that,
a push is essentially taking code that you have locally,
pushing it up to the cloud, up to GitHub.
And once you've done that
and you can go to the GitHub platform,
you'll normally be able to see any new changes
that you've made there.
So you can see now that her new branch is here
and so her remote repository has been updated.
And she can keep making commits,
she can keep adding files, making changes,
and do repeat pushes
to keep that remote GitHub repository updated
with what she's been doing locally.
But the one thing that you wanna be aware about and not do
is always make sure that when you are making a push,
you are pushing stuff from a branch on your local machine.
Make sure that you are always gonna be pushing it
to the same branch in your origin repo in GitHub.
So you never really wanna be getting to a situation
where you are in your new,
like a feature branch thing here,
and you should not then be doing git push origin main.
Do not do this, bad things will happen.
Merge conflicts will occur.
It's not a fun time.
So make sure that you're always doing this,
you're pushing from your feature branch
to the same feature branch in your remote origin repository.
Don't do this.
So always double-check before pushing anything.
I've made this mistake many times myself,
so I'm really trying to emphasize the point here.
Okay, so let's say Alice has been working locally,
but how does Alice keep her local machine,
her local repository updated with any changes
that were made in the origin remote repository.
So for example, maybe she was working,
she pushed some changes from a different laptop
up to that GitHub profile.
Maybe her friend Bob was also pushing stuff
or adding new branches.
And these,
her local repository and her origin repository in GitHub
have been evolving separately as we said.
So, how does she get all of these updates here
onto her local machine?
Well, what she's gonna need to do
is she's going to need to fetch those changes
from the origin by running git fetch origin.
What fetch does is it will basically take any new changes
that were in that GitHub repository
and add them to her local repository.
It does kind of a shallow kind of fetching,
it downloads it to her repo,
but it doesn't actually merge any changes
into her branches that she's working on.
So for example,
say she's working on branch one
and there have been changes made to branch one in GitHub.
She can fetch those
to kind of show that those branches are appearing locally,
but if she actually wants to merge
any of those changes into her work,
she'll then have to do git pull origin branch1 as well.
So it's always a good idea to fetch and then pull.
If you have any new branches that were added in GitHub,
you'll need to fetch them to make the branch show up locally
so that you can then move into that branch
and start working on it.
So you're gonna need to wanna use those two commands
in parallel.
Okay, so,
and let's say now that she wants
to take any changes that she's made in main
into her new branch, feature branch.
She can, in this case, do git pull origin main.
This is more acceptable than doing push main,
pushing to main, you should never push to main,
but it's perfectly okay to pull from main.
So long as you're aware
of kind of what changes have been happening in main,
you might wanna keep your feature updated
with anything that has changed
in the main trunk of your repository.
Sometimes, though, when you do this,
you will encounter a merge conflict.
If you have not yet encountered merge conflicts
in your GitHub journey,
don't worry, I guarantee you will experience these
at some point.
But the key thing to remember is don't panic,
it happens to the best of us,
happens to me on pretty much a daily basis.
But don't panic,
there are plenty of,
it seems scary at first,
but there are plenty of different tips and tricks
to getting around that.
I really recommend this article on Medium.
Go and check that out.
We'll put the link in the description as well.
And yes, if you ever get into a situation
where you've got conflicts in your merges,
don't worry, you can get out of it.
Okay, and that completes our first GitHub 101 session today.
Next time we're gonna talk more
about using GitHub with other people.
Thanks very much for listening.
(upbeat music)