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.
