Git vs GitHub Explained
Key Points
- Git is a local version‑control system that records snapshots of your code so you can track changes, revert to previous states, and avoid losing work.
- GitHub and GitLab are cloud‑hosted services that run Git repositories and add collaboration features, turning individual version control into a shared platform for teams and the open‑source community.
- Together they enable multiple developers to work on the same codebase simultaneously, merge each other’s contributions, and maintain a reliable history of all modifications.
- The workflow is highly flexible, supporting pure local development, integration into CI/CD pipelines, automated testing, and automated build‑and‑deploy processes.
- Most interactions with Git are done via the command‑line interface on your machine, which communicates with the remote repository hosted on GitHub or GitLab.
Sections
- Untitled Section
- Git/GitHub Flexibility and Trunk Development - The speaker outlines Git’s local command‑line use versus GitHub’s web interface, highlights its integration into DevOps pipelines for automated testing and deployment, and introduces trunk‑based development where developers branch from and merge back into a main code line.
- Coordinating Branch Commits and Merges - The speaker outlines committing changes to a feature branch and pushing them to GitHub, then describes a coworker needing to pull and merge the main branch into his own branch before merging his work, illustrating the workflow and potential merge conflicts.
- Conclusion: Git, Demo, and Next Steps - The speaker wraps up the application demo, explains Git’s relationship to GitHub and GitLab, invites viewer questions, and encourages likes, subscriptions, and earning free IBM CloudLabs badges.
Full Transcript
# Git vs GitHub Explained **Source:** [https://www.youtube.com/watch?v=wpISo9TNjfU](https://www.youtube.com/watch?v=wpISo9TNjfU) **Duration:** 00:10:05 ## Summary - Git is a local version‑control system that records snapshots of your code so you can track changes, revert to previous states, and avoid losing work. - GitHub and GitLab are cloud‑hosted services that run Git repositories and add collaboration features, turning individual version control into a shared platform for teams and the open‑source community. - Together they enable multiple developers to work on the same codebase simultaneously, merge each other’s contributions, and maintain a reliable history of all modifications. - The workflow is highly flexible, supporting pure local development, integration into CI/CD pipelines, automated testing, and automated build‑and‑deploy processes. - Most interactions with Git are done via the command‑line interface on your machine, which communicates with the remote repository hosted on GitHub or GitLab. ## Sections - [00:00:00](https://www.youtube.com/watch?v=wpISo9TNjfU&t=0s) **Untitled Section** - - [00:03:07](https://www.youtube.com/watch?v=wpISo9TNjfU&t=187s) **Git/GitHub Flexibility and Trunk Development** - The speaker outlines Git’s local command‑line use versus GitHub’s web interface, highlights its integration into DevOps pipelines for automated testing and deployment, and introduces trunk‑based development where developers branch from and merge back into a main code line. - [00:06:15](https://www.youtube.com/watch?v=wpISo9TNjfU&t=375s) **Coordinating Branch Commits and Merges** - The speaker outlines committing changes to a feature branch and pushing them to GitHub, then describes a coworker needing to pull and merge the main branch into his own branch before merging his work, illustrating the workflow and potential merge conflicts. - [00:09:26](https://www.youtube.com/watch?v=wpISo9TNjfU&t=566s) **Conclusion: Git, Demo, and Next Steps** - The speaker wraps up the application demo, explains Git’s relationship to GitHub and GitLab, invites viewer questions, and encourages likes, subscriptions, and earning free IBM CloudLabs badges. ## Full Transcript
What is Git, and what's it used for?
What's the difference between Git and GitHub, or GitLab?
I'm Nathan Hekman from IBM Cloud and I'm going to answer that for you today,
but before I do, please hit that "Subscribe" button.
Now let's "git" started with an example.
Let's say you work for a media streaming company
and you're tasked with building a music player app.
So, you want to be able to be able to play music of all sorts of genres on a device
and you're tasked with developing this application with a team of developers, right - it's not just you.
How do you work with that team of developers
and write code at the same time as them
on the same code base or project without conflicting?
Well, that's where Git and GitHub, or GitLab, come in.
So, what is Git, right?
So, Git is what's known as a version control system.
That might not mean a whole lot to you right now, but we'll jump into what exactly that means.
How about GitHub?
Or GitLab?
Well, GitHub or GitLab are actually hosted ... Git.
So, where Git is actually the underlying system that runs on your local machine,
GitHub or GitLab is hosted maybe in the cloud,
or hosted via the web,
to host that Git system, as well as add a few more useful features.
You may know GitHub or GitLab as a very diverse community, open source community,
where developers from all over the world can work together and collaborate on different code or projects.
So, let's talk about some of the benefits and and aspects
of Git and GitHub and how they work together.
So, first of all, it allows you to track your changes.
So, you always have a state tracking exactly what changes were made at any time.
Kind of going along with that, it's a historical backup using ...
... basically you can think of them as snapshots, right?
So, it's it's kind of like a "Save as" button.
So, you're probably familiar with that.
You basically can keep a previous version and revert to it if you need to
while still copying and then making changes on top of that previous version.
So, if you introduce a bug or mess something up
you can always go back with a historical backup that it provides
and revert those changes.
What else?
So, maybe one of the biggest benefits that Git and GitHub allow
are just team-based development.
So, like we were talking about over here,
it allows a team of developers to actually work on the same code simultaneously
and then merge their changes in together to make progress on a project.
Pretty cool.
Next, it's also very flexible,
so it allows you to work locally on a project
or Git or GitHub can be used as part of your DevOps flows
so that you can integrate your repository, which we'll talk about in a second,
and your project and actually have it be part of an automated test,
so kick off automated testing, or be part of your automated build and deploy processes.
So, that's a really neat aspect, it's very flexible.
And then finally, so, Git is typically ... you interact with it using the command line on your local machine
versus GitHub is on the web, right - it's a website, and that's how you interact with GitHub or GitLab.
And, finally, a concept that I think is important to understand
about Git and GitHub, or GitLab, is that it's trunk-based development.
So, what does that mean? Think of a trunk like a tree, right?
So, you have this main ... you can think of main code,
and you as a developer maybe will want to branch off of that main branch of code,
make some changes and then merge your code back into that main branch.
And, over here, you might have another developer that branches off of the main branch,
makes some changes, and then merges back into that main branch.
That's trunk-based development.
All right, let's dive into our example and see what exactly this looks like.
So, let's say that you have what's called a repository.
So, repository.
What's a repository?
It's a place to store your code and your changes to code,
and in this case it's going to be hosted on the cloud or in the web on GitHub or GitLab.
And, at the same time, let's say over here that I am working.
I want to work on this this code base on my local machine, right.
So, how do I do that?
Well, I need to do what's called "clone" this repo onto my local machine and I create,
... remember our trunk based development?
I create a branch of code called "Nathan-branch".
So, that's where I'm going to be making my changes to the code base.
And let's say ... well, what changes do I want to make?
Well, I'm a huge Bluegrass fan, OK?
So, I want to make the home page of the application feature Bluegrass.
So, down here, let's say that I have my application
and we call this our working copy.
So, this is where I'm going to actually be making changes
to that working copy to feature Bluegrass music on the application homepage.
Great!
So, once I'm happy with those changes what I'm going to do is I'm going to actually commit them,
say "commit",
those changes to Nathan-branch,
and then, once I'm happy there, everything's committed,
I'm going to go ahead and push those changes
back over to our cloud-hosted repo in GitHub.
So, I'm going to go ahead and push those changes.
Perfect!
Happy with that, right? Let's make it a little more complicated.
So, over here my co-worker, Greg,
is also wanting to make some changes to the application home screen,
and now he happens to be making these changes before I pushed up my Bluegrass changes back to the ...
... we'll call this the main-branch.
So, he doesn't have my changes yet, so when he clones down to his local machine
he wants to make some changes, he has a little different style preference for music.
He's a huge Rock fan, OK?
And so, over here on his working copy,
he's going to make the home screen feature Rock music.
And so when he goes ahead and he makes those changes
and then he commits them back to what we call "Greg-branch",
he's happy with those changes, he wants to go ahead and merge those
and push them back to the main-branch.
So, let's see, what does he need to do in order to do that?
Well, he'll actually need to pull and merge whatever is in the main-branch,
because at this point as he's been working I've already pushed up my Bluegrass changes.
So, now he has to pull those down into his Greg-branch and merge them.
Uh-oh. Guess what?
There is what's called a "merge conflict", that happens right here, right?
So, when he's pulling down those changes he's been modifying the same code.
So, there's a conflict that he needs to resolve there.
So, what does he do?
Like any good co-worker he compromises, right?
So, he makes the main screen of the app feature both Bluegrass and Rock.
So, he makes those changes in his branch,
and he's ready to actually get those back in the main-branch.
So, the next step he needs to take is:
he needs to submit what's called a "pull request".
You may have heard folks talk about a "P.R.", right? That's what a pull request is.
What is it? It's basically
a way for him to say, "Hey, these are the changes that I want to make",
and it can be viewed in GitHub or GitLab
so that anyone on the development team, like Nathan,
I can go ahead and look at those changes and I say, "Good job Greg, looks great!"
And I can approve the pull request and then get those changes merged into the main-branch.
So, you'll see the final version of the application looks awesome,
Bluegrass and Rock both featured on the main page. Awesome!
So, hopefully this makes it clear about what exactly Git is,
how is it related to GitHub and GitLab,
and how they are fundamental to developing applications not only by yourself,
but as a team of developers.
Thank you.
If you have questions please drop us a line below.
If you want to see more videos like this in the future, please like and subscribe.
And don't forget,
you can grow your skills and earn a badge with IBM CloudLabs
which are free, browser-based interactive Kubernetes labs.