Introduction to Source Control with GitHub

0:11Hi, guys. My name is Trevor Sullivan, and welcome to another CBT Nugget skill. In this skill, we are going to be introducing the GitHub platform, which is typically used for hosting source code for version-controlled software packages. And what we're going to be doing is taking a look at how to use GitHub as a revision control system. Now oftentimes, you're going to be working with a tool like GitHub by using the Git CLI or other tools like Microsoft Visual Studio code or other editors out there that you might be using to actually author your code locally on your dev system.

0:46But in this particular skill, we're going to be focusing on the actual web user interface so that, if you're new to GitHub, you don't have to worry about setting up any third-party tools. You don't have to worry about getting the Git CLI connected to GitHub and things like that, because that involves things like SSH keys and a little bit of extra configuration that's specific to the Git CLI tool. But we're going to be specifically exploring the GitHub user interface and understanding how to use that to do things like creating files, to create branches within a repository.

1:17We'll understand how organizations work, at least at a high level, and repositories, and some of the functionality that exists within those utilities like organizations and repositories. Those things have things like team management and issue tracking, project tracking, and a lot of advanced functionality that's available to help you manage your software projects. Now before we get too far deep into GitHub, I did want to point out that there's a lot of different tools out there that you can actually use in order to manage your source code. Now GitHub, obviously, the name implies that it's very Git-centric.

1:50But there's actually lots of other tools out there, as well, that don't necessarily reference Git in their name, but are actually using Git under the covers for doing version control. And some of those different tools are things like a AWS CodeCommit. So AWS CodeCommit is a managed hosting service that allows you to host source code using a Git revision control system and then integrate and do things like continuous integration using other services within the AWS ecosystem. Additionally, Microsoft Azure is another one of the big three cloud vendors out there.

2:23And they have a tool called Azure DevOps, which has a lot of similar overlapping functionality with GitHub, as well. And what they've got is things like a wiki for documentation. They've got things like your Git repository itself that you're actually pushing code to, things like pipelines for continuous integration and continuous deployment, as well, and some projects tracking things like creating these boards and creating issues and backlogs and things like that. So there's some project tracking things built into Azure DevOps, as well.

2:54And then if you're looking for something that's a little bit more self-hosted, there's actually tools like Gitea, which is basically an open-source package that you can run yourself. And it actually resembles the GitHub user interface. If you look at what the GitHub user interface looks like over here, you can see there's these different tabs across the top here. And if you were to drill into a specific repository within an organization, you'll see a different set of tabs that correlate to the different entities that are associated with a repository. And you can actually see that very similar structure right here in Gitea, where you've got things like an issue tracker, and pull requests, and releases, and a wiki for documentation, and things like that.

3:32So this is a fully-featured, self-hosted version of basically just a Git version control system, along with some project management capabilities. And then there's another pretty popular one out there, as well. It's built in Go. And this is called Gogs. And this is very similar. It's a self-hosted version of GitHub you can kind of think of it in a way. Obviously, it's a totally separate tool. But it is open source, and it's built in Golang. So these are just some alternative options that you have to GitHub. And they live in that ecosystem of doing things like version control for your software packages, as well as some project management capabilities like having an issue tracker, and the ability to create pull requests, and CI/CD functionality built in, and a wiki for building documentation for your software project, and a bunch of different capabilities like that.

4:23So what we're going to be doing in this particular skill is focusing on specifically GitHub, specifically within the web user interface and understanding how things like organizations and repositories work. And then we'll drill into actually how to use the GitHub UI to actually create some files in your project and then do things like open pull requests if you are going to submit some code to somebody else's project, for example, and things like that. So in any case, let's go ahead and jump into our next video. And we'll get started. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] Hey, guys and welcome back. In this video, we're going to take a quick look at organizations and understand what the capabilities of a GitHub organization looks like. Now, when you initially sign up for your GitHub account, you're going to have a username. My username just happens to be pcgeek86. That's my unique identifier that I use on various places online.

0:32And when you create a user account in GitHub, you'll have the ability to create code repositories within that user account. So for example, here are some different repositories that are directly associated with my user account. And I can push code to those repositories, I can create issues in those repositories. I can make them public or private, and configure them however I want to. They're basically just places for me to store my code. Now, if you are working in a team environment where you need to share access to a repository, it's oftentimes advantageous to create something known as an organization in GitHub.

1:10And once you're logged in to GitHub, you can actually just create that right here in the top right hand corner, they create a new organization. And then when you create an organization, this is just kind of a stub or a kind of a placeholder for your repositories that your company will be creating in the future. And so you can choose either a paid plan here, which includes some advanced features, or you can use the free tier here, which is pretty generous. You can have unlimited public and private repositories. You have the ability to do up to 2,000 automation minutes, using GitHub actions.

1:43Which is kind of a separate topic in and of itself for doing continuous integration and continuous deployment. It's actually free for public repositories. But if you have private repositories, you actually do get 2,000 minutes included for free with organizations, which is pretty cool. You also have the ability to use the GitHub package storage system, which allows you to store things like NPM packages or container images if you're using Docker as a deployment mechanism. You get packages and a whole bunch of other things. So you can actually host up to 500 megabytes for free on GitHub packages to serve as a repository to host your modules, and then be able to download and install those modules to different systems from GitHub packages.

2:23Very similar to how you would use tools like Docker hub, or the NPM registry, or NuGet registry, and things like that. There's also the ability to create issues and projects within your repositories as well, and community support, basically meaning, you don't really get official support plan from GitHub. But if you want to go post on the GitHub community forums, you're more than welcome to do that, and to try to get some assistance if you do happen to run into any bugs in the platform. So what you can do is just click on create a free organization here.

2:56And you can just give that organization a name. So I might call this something like cbttrevorgithub, for example. And then, you want to provide a contact email address for GitHub to be able to reach out in case there's a problem with the organization in the future. And so I'll just do Trevor.Sullivan@cbtNuggets.com as my email. And then I could either select that this belongs to just me personally, or I could associate it with a larger company here. So for now, I'll just choose my personal account and hit Next.

3:27And then once you've created that organization, you have the opportunity to search for other users. Within the GitHub platform, you can search for them based on their username, like my username up here is pcgeek86. So if you know somebody else's username, you can just add them very quickly like that. Or you can search for people based on their names. So you could search for people by name. Here's a bunch of other Trevors out there in the world. Or if you know what their email address is, you can just plug that in, and it'll look them up by email address. So you have the ability to add people to this organization.

3:57And then you can assign permissions to them. So for now, I'm just going to go ahead and skip this step. And it's going to kind of put you through this little wizard here that asks you for some basic information, if you'd like to. I'm just going to kind of skip that for now. And now, we've got an organization. And an organization really isn't anything in and of itself, it's basically just kind of a high level entity that allows you to ultimately host your source code repositories underneath of it. Now, if I did have any repositories in my organization, that would show up right down here under this section, where we have repositories.

4:31You also can pin repositories as well. So that gives you the ability to kind of highlight important repositories that are maybe frequently accessed by multiple teams within your organization. And you can host those right here under the pinned section. And then right here under repositories, this is kind of a master list of all the repositories within your organization. Allows you to search through those repositories to find one. Maybe, you're searching for something by a technology title like MySQL, or maybe you've got some interesting naming convention for your organization.

5:02So you can search for those repositories in here, and then go in and view that source code. Also, within the organization, we have that packages capability that allows us to our modules. So you can host things like container images if you're building those with Docker. If you're building things like ruby packages, those are known as ruby gems, you can host those gem modules right up here on GitHub packages as well. There's also support for NPM if you're building in JavaScript. NuGet, if you're doing .NET devlopment, as well as other things like Apache Maven if you're doing Java development.

5:32There's a bunch of different providers that are supported in GitHub packages so that you can host those packages up there, and then distribute them. If you're doing things like production deployments or dev test deployments you can actually just download those modules straight here from GitHub packages. And then over here, we've got the people section here. And this is where you can invite other people to participate in your organization. Now, I've actually got another organization that I'm going to navigate to, called github.com/cbttrevor. I've already got this one created.

6:03And if I go over to this people tab here, you can actually see that, Dan, the founder of CBT Nuggets is listed here as well. And both of us have owner permissions to this organization, so any of us can actually make any types of changes that we need to, to this particular organization. We have full control over it. However, you can also invite outside collaborators as well. You don't necessarily have to add users as members of the organization. You can invite outside users and just give them limited access to certain repositories within that organization.

6:36Now, another concept that is really helpful within organizations, especially if you are working in a very large company is the ability to create something known as teams. Now, when you create a team, the team allows you to essentially assign limited access to certain repositories. You can kind of think of a team as like a sub-filter within the overall organization. Though, in my organization here I've got all these different repositories here. But these repositories could actually belong by definition to other teams, to certain teams within the organization.

7:09So maybe these first three repositories belong to team A, maybe the next four repositories belong to team B. And they're just kind of mixed and matched in there. And so what you can do to kind of filter that down and make things a little bit more logical, if you have hundreds or thousands of repositories in your organization, is to create something known as a team. Now, a team is kind of a subset of users within your organization. And so I've created this team right here called CBT Nuggets. And as you can see, it has a single member right now, so I'm the only member of this particular team.

7:40But the team allows you to have limited team discussions that maybe don't apply to the entire organization. So I've just got a little conversation thread going right here with myself, because sometimes I'd like to talk to myself. But it gives you a nice place to just kind of have those intra-team discussions amongst, maybe, 5 or 10 people, rather than hundreds or thousands of different people that are just kind of seeing a whole lot of noise. You can add additional members to those teams. And then, you can actually assign certain repositories to teams as well.

8:10So if there's a particular repository that you would like this team to have access to, you can just do a search for that repository. You can add that repository to this team. And so now, rather than seeing hundreds and hundreds of different repositories across my entire organization, my team is now limited to only seeing the actual repositories that are relevant to this particular team. You can do the same thing with projects as well. So if you have projects to find, you can go ahead and add those from within your repositories as well. And then add those at the team level, so that the team can kind of track those projects as well.

8:45So that's kind of what teams look like. So let's go back to our organization level right up here, and take a look at a couple of other things. Now, right over here, we've got the ability to create projects at the organization level. And then that's where we can also import them at the team level as well. So we could create a new project here and then we can track a project across our entire organization. And then we can add that project to the teams that are actually actively working on that project, that they're aware of where that project currently is.

9:16So let's go ahead and head over to repositories here. And we're going to create our first repository in the next video, and actually take a look at how to do some source control inside of our organization. I hope this has been informative for you. And I'd like to thank you for viewing.

0:11Hey, guys, and welcome back. So in the last video, we took a look at some of the high-level functionality that's available within the GitHub Organizations feature here. And now we're actually going to create our first repository from scratch. I know I've already got a whole bunch of repositories here. But we're just going to create a brand new one that's fresh, that doesn't actually have any files in it. And we'll just kind of learn how to use the GitHub web interface. In order to create and manage source code from our browser. So in my organization here, I'm just going to go ahead and click on a New Repository.

0:42And then if you have other organizations, you can actually just click this dropdown box and choose which organization you want it to belong to. I'm just going to choose my existing organization here called cbttrevor. And then you'll want to give the repository a unique name within your organization. So we could give this a name like github-intro-source-control, for example. And then you can provide a description that just kind of uniquely identifies this. So let's say this covers GitHub basics in the browser.

1:16And then you can choose a visibility level. So if you make it public, that means that anybody on the internet who has a GitHub account-- or even if they don't have a GitHub account, even if they're not logged into the GitHub user interface-- they'll be able to see your source code. So if you're working on a private project and you don't want the internet at large to be able to see your project, you want to make sure that you choose private here. And again, the nice thing about the free tier of GitHub organizations is that you can have unlimited private repositories. So you're not really having to pay for that functionality, unless you need some more of the advanced features of the paid tiers.

1:51Now, right down here, you have these options to initialize the repository with a few key files. And you don't have to choose any of these. I mean, these are really just kind of helpers that will basically just create stub files for you. But if you know what you're doing and you can just create these files from scratch, you can just leave these unchecked and just create a totally empty repository. Now, these files are special in GitHub repositories, because the file named README or README.md inside of the root of your repository will actually be rendered directly inside of your web browser when you visit that repository's page.

2:26So that'd kind of serve as a really nice landing point for any introductory level documentation. Or if you need to link out to other documentation, you can just add that README file. We'll take a look at how to do that manually. And then there's also the ability to add a gitignore file. And this is really important any time that you're working with the git version control system. Because if there are files being added to your project that are kind of temporary in nature, then you typically want to use this special file called gitignore to actually prevent those files from being committed to your source control repository.

2:57Otherwise, you'll get a whole bunch of junk inside your repository that doesn't actually pertain to your application's source code. And then down here, you've got the ability to choose a license. And there's a whole bunch of open source software licenses that are kind of prepackaged here. So if you don't want to have to go to a separate website and say, show me the MIT license, for example. And then click on this website, and then go and copy and paste the actual text of the license right here, and then copy it into your project. It just kind of saves that additional step, where you can just search for a license right here, choose that license, and GitHub will go ahead and just include that in your repository as a license file.

3:36So let's click on Create Repository here. And as you can see, we've got a fresh repository here. There's not really any code inside of it. We do have this license file that we just generated. So if we click into that, sure enough, GitHub has kind of detected that it's the MIT license. And you can see it's put in this copyright statement here for CBT Nuggets. And it's got the actual text of the MIT license itself. And they also give you kind of this brief overview. So if you're working with open source projects, it shows you what you can and can't do at a very high level. Obviously, it's not a substitute for legal advice.

4:08But it gives you kind of a high-level overview of whether it's permissible for businesses to use that software or if there's warranties included in the software, and things like that. But in any case, this is kind of a fresh git repository. And remember that with git, when you are working on a shared git repository on GitHub, or if you're using one of these privately-hosted solutions, or anything else, because git is a decentralized source control system, the GitHub repository that we have here is only going to be considered kind of the master repository for a team of people who are working on a project simply by consensus.

4:45So if I were to take a copy of this, and if I were to clone it locally using this SSH URI right here, then that would be entirely cloned down to my local system, and I'd have a full copy of everything that is on the GitHub server here, so to speak. So git itself is decentralized. And so you actually get an entire copy of this repository, if you were to clone that locally on your dev system. There's nothing really special about the git repository that's hosted on GitHub, other than the fact that my entire team kind of essentially agrees that this is going to be the central place where we collaborate on source code.

5:24So just keep that in mind. It's a really important concept in git overall. Now, over here in the top left corner, you can see that we have this Branches section here. And traditionally, this has been called the master branch. But GitHub has actually renamed it to be called the main branch. It's basically just a name for the primary branch that's going to host your source code. However, you can create many other branches in here as well. And branches are typically used in git for things like creating new features. Or if you're working on some really advanced feature and it's going to take you a couple of weeks to kind of implement that feature and test it out, then you can create a separate branch for your code, and give it a name like my-new-feature, and go ahead and create that branch.

6:07And then any code that we now submit or commit to this particular branch is not going to impact the main trunk here, which allows us to kind of focus on our production-ready features that are actually ready to be deployed out to our actual end users. So using this branching capability is really helpful, if you need to work on a feature separately, or maybe work on a bug fix, and you don't want to risk breaking the code that is in your main branch. Oftentimes, if you're working in a team environment, you'll see lots of different branches listed here.

6:38Maybe those branches have new features. Maybe they're bug fixes. They could even be something as simple as just documentation branches, where somebody is working on building out a documentation platform that generates documentation, like MkDocs for Python, for example. Or maybe they're building a website in XJS or something to host those documentation. So they could work on that in a separate documentation branch. And then in the future, they could merge that, once it's kind of tested and ready to go, on the main branch here. And then in addition to branches, you also have the ability to see your git tags here.

7:10So if you've assigned a tag to a particular commit in your git repository, those tags would show up here. This is kind of what an empty repository looks like. We have these kind of more advanced features here that are specific to GitHub, not git itself as a version control system. But the GitHub platform has the issue tracker, the ability to create pull requests. There's actions, which is a CI/CD system. It allows you to automate different workflows within your project. You also have projects here, which allows you to do kind of project management and prioritize feature requests and bug fixes.

7:46We've got the wiki right here that allows us to build documentation. We also have security here. So we can assign certain security policies to do things like scanning against our repository for potential vulnerabilities. Those are some more advanced features that are specific to GitHub. But we're going to focus a little bit more on the Code section here and actually understand how to create files in our project. So if we had a totally empty repository-- let's just pretend that this license file doesn't even exist in our repository-- we can add a file to our repository simply by clicking on Add File over here.

8:17And then you can either upload a file from your local file system, which is kind of convenient, because if you have a code file that you've-- maybe a script that you've been developing locally and you just want to add it into your repository, you can upload that. Or if you actually want to just create a new one in your web browser, we can click on Create New File. Now, that's going to take us over to this other user interface here, where we can give the file a name. So we could call this something like myscript.ps1. ps1 just happens to be the file extension for PowerShell scripts. And then down here, we can go ahead and just edit our code.

8:51So I could do something like Get-ChildItem or Get-Process, for example. And this is going to basically allow us to edit our code directly in the web browser without having to go through the process of cloning our repository locally, and then committing locally, and then pushing back up to GitHub. Anything that we commit right here is just going to be committed directly to our source code repository that is hosted on GitHub. So once you've made some changes to your file here, if we just scroll down a little bit, you can see we've got this commit.

9:21And this is going to allow us to add a commit message. I'll say adding my first PowerShell script. Of course, this could be any type of code that you want it to be. You could create a Python file, a Ruby file, a Java file, pretty much anything you'd like to. I just happen to be creating a kind of PowerShell sample script file here. And then you'll be able to choose different email addresses that you have associated with your account. Apparently, I don't have my CBT Nuggets email listed right here. But you can just choose one of the email addresses that you want to be used when you are creating this commit.

9:53You can also add an extended description here to kind of describe what changes you're making. And then you can either commit directly to the main branch, or if you have a named branch or you want to commit to a new branch, then you can just choose that option right down here. And I could just call this something like powershell-scripts. And this will create a brand new branch for my project. But for now, I'm just going to go ahead and commit to main. Let's choose Commit New File. And sure enough, you can see that this file has now been added to my source code repository. I can click into it.

10:23And you can see the GitHub user interface on the web interface for GitHub is actually showing us the syntax highlighting for our script here. So because it's PowerShell and it has the ps1 extension here, GitHub knows that this is a PowerShell script file. And so they're able to do some syntax highlighting and make it look a little prettier for our editing needs. All right, so that's how we can add a new script to our repository here and how we can create a brand new repository in our GitHub organization.

10:54I hope this has been informative for you, and I'd like to thank you for viewing.

0:11Hey, guys, and welcome back. In the last video, we took a look at how to create this new script file, called myscript.ps1, in the root of our project here, and we committed that file to the main branch in our source code repository called GitHub Intro Source Control right up here. And that's part of our GitHub organization called cbttrevor right here. So now that we've added this file, what if we wanted to make some changes to that file? Well, right over here on the right-hand side of the user interface. You have a few different options. So this button right here called Raw that just allows us to see the actual raw text without any extra formatting, like syntax highlighting, being applied to it.

0:49That's a really nice view. If you just want to copy some text to your clipboard really quick, you can just go into this raw view and copy of that to your clipboard and then paste it into another application. I do that on a fairly regular basis. You also have this blame option here that's kind of cool because it'll actually show you who made changes to which specific lines in a file right here. So you can see that Trevor Sullivan right here made changes to lines 1 and 2. But if another user came along and added a third line or maybe changed something on line number 1, then that would actually show you.

1:21It would kind of blame that particular person for making a particular change to a specific file in your source repository. So that's a really useful feature as well. And then right over here, we have the option to use the GitHub desktop app, which we're not going to talk about right now. We can also delete the file from our repository. But then, right here in the middle, we've got this little pen. And if you hover over that, you'll see that you can edit that file. We're back in this Editor view, where we initially authored our file. And so this interface, once we have an existing file, it's going to allow us to do things like rename the file, for example.

1:55We could actually change the file name right up here. We could also make some changes to our script right here and just say get process for each thought process. It's kind of a dangerous thing. And we'll just kind of attempt to stop all processes on your system. But we could make that change, and we could add additional commits here. We have the same options to commit directly to the main branch, or we could commit to a new branch here. But what I wanted to show you right here is that if we wanted to actually move this file-- so right now, this file is in the root of our repository right here.

2:27So we don't have any folders in our project at the moment. But if we wanted to put this file into a folder, we would actually edit the file. And then right up here in the file name, we could type a folder. Let's say we wanted to create a subfolder called scripts. So I'll just type scripts and then put a forward slash. And GitHub will automatically detect that I want to create a folder, and so then it'll allow me to change the name of this particular file and actually place it into a folder. So that's kind of cool.

2:57So you can also hit backspace. And even though it's not necessarily too obvious that you can actually do that, if you just go to the beginning of this box here, if I wanted to change the name of that folder to something like PowerShell, for example, I could put a forward slash there. So if you want to change the name of a folder or if you want to-- if you're nested several folders deep in this file name, you can actually just hit backspace right there, and that'll allow you to either remove a folder from the path or correct the name of one. So let's go ahead and commit this change then. So essentially, we're just moving this file over to PowerShell.

3:30We'll come down here and just say moving to folder. And we'll say commit changes. And if we go up into the root of our repository right here, you can now see that we've got a folder here by this folder icon called PowerShell. And then if we drill into that, sure enough, you can see that we've got this myscript.ps1 file in here. All right, so that's how we can kind of manage our folders here. But what if we wanted to do some branch management as well? So let's say that we wanted to add a new feature into our project, but we wanted to put that on a totally separate branch?

4:05Well, right now, I've actually got this branch right here called my-new-feature. So let's actually click into that. And actually, there's nothing here. So why is that happening? Well, let me hit the Back button on my mouse here really quick, and I'll explain why that's happening. So if we go back to the root of our source control repository and we now try to go over into my new feature, check out what happened. Well, back when we created this branch called my new feature, remember, we didn't actually have that PowerShell script file created. So the only file that actually existed inside of the repository is this license file.

4:39So after we created this branch, we went back to the main branch. And then we added that script file into the root. And then we renamed that script file to essentially move it into a folder here. So because I am in this PowerShell folder right here at the moment, if I try to switch over to my-new-feature, well, this page doesn't exist because the PowerShell folder doesn't actually exist inside of the new feature branch. So that's why we're getting that 404 message when we're in the PowerShell folder, and we tried to navigate to a different branch that doesn't even have that folder as part of that branch.

5:17That's why we're seeing that 404 error message. So if we just go to the root of our repository and then navigate over to that branch, OK, now, we can kind of see that we have just this single file here. And we don't have that PowerShell script. Now what else is helpful here is that it tells you that this branch is two commits behind main. And so what that's telling us is that somebody else on our team-- well, in this case, it was just me-- but somebody on our team has actually added code by committing to the main feature branch here.

5:47And so this branch is now in front of the my new feature branch. And we can see that. If we click on the Branches little icon right here, this will actually show us all of the branches right here. And so if we just go to all branches, it'll actually show us that the main feature branch was updated two minutes ago, and my-new-feature was updated 13 minutes ago. And it tells you which user name in GitHub has actually made those changes. So we can see that my-new-feature is definitely older in terms of time than the main feature branch here.

6:21So one of the things that we can do is actually to suck in the changes that were made to the main feature branch back into the my-new-feature branch. So what we can do is create a new pull request, and we can basically say that we want the base to be my-new-feature. And then I want to bring in the changes from the main branch here. We'll say importing main, and we'll say create pull request. And then I'll just go ahead and approve this merge request right away.

6:52So I'll just say confirm merge. And once we do that, we've now merged the main feature branch back into the my-new-feature branch. And so now, our feature branch should be up to date with the main branch. So now, let's go back to my-new-feature branch. And sure enough, you can now see that the PowerShell folder does exist inside of the my-new-feature branch because we effectively basically took all the changes in main, and we imported those over into our feature branch right here.

7:22So now, they're kind of in sync with each other. And you can actually see that this branch is one commit ahead of main only because we applied this merge request as a pull request in GitHub from the main branch. So later on, we'll go ahead and actually merge this feature branch back into main. But first, let's go ahead and make a change to this particular branch. So we'll add another file to this branch. And let's just call this something like package.json, and we'll just create an empty JSON object here.

7:53Package.json is commonly used in JavaScript projects. So we'll just kind of pretend that we're creating a JavaScript project here. And I'll say adding package.json to root of project. And then we'll go ahead and commit it to my-new-feature branch. Now, in this case, you can actually see that this radio button here is not referring to the main feature branch because, in the GitHub user interface-- I'm going to middle-click to open a new tab here-- I actually already had this feature branch selected so any time that I add a new file or if I go in and try to edit a file, the commit is actually going to be applied to the feature branch that you are currently on.

8:32So you want to be paying attention to which feature branch or which branch in Git you are committing to so that you're not accidentally committing to the wrong feature branch. All right, so now, we've added this kind of new-- let's just call it a feature. We've added this new file into our project, and it's now under the feature branch. So now, if we go back to our main trunk here, our main branch, you can actually see that it does not incorporate that package.json file. So you can see right here the GitHub has detected that our feature branch has had recent commits against it.

9:05And so GitHub is kind of hinting to us as developers that maybe we want to incorporate this new feature into our main branch here. So to do that, it gives us this little shortcut to basically do a comparison and a pull request, kind of like what we did before. But in this case, instead of importing main into our feature branch, we actually want to take what's in our feature branch right here and import that back into main. And see this little arrow right here. It's kind of pointing at whatever branch you're looking at on the right-hand side is going to be sucked in to the branch on the left-hand side.

9:38So I'm going to rename this pull request and say importing my-new-feature or importing new feature into main branch. And I could leave a little message for my team here kind of indicating what changes were made. Let's go ahead and create this pull request. And so, now, we've got a pull request, and we can go ahead and just merge it, like I did before where I merged main into the feature branch. But before we do that, let's actually take a look at some of the options that we have here in the pull request. So before we actually merge the pull request, let's say we actually want to review what changes were made.

10:10The write-up here, we've got commits. And this allows us to see a history of all the commits that were made to this particular branch. I should say, more correctly, actually, that it's all the commits that were made as part of this particular pull request. So you can see that we have a pull request that we previously had merged the main branch into our feature branch. So that was the first commit that we had into the feature branch. And then just a minute ago, we added this package.json file into our feature branch as well.

10:41So basically, any changes that were made as part of these two commits will then get merged back into the main branch. If we actually click on one of these right here-- so let's go ahead and drill into one of these. And so we can see in package.json, for example. We can actually see a list of files right here. And you can collapse them or expand them so that you can see all the different files. But what it's showing us right here is it's showing us that these two lines were added to this file called package.json. This gives us a very granular way to review exactly what changes were made to this particular file as part of this commit here.

11:16Now, if there were multiple files that were modified or added as part of this commit, we would see all of those changes listed down here. We could review those. And then we could come back to our conversation area here and then say, OK, I've reviewed this. Let's go ahead and just confirm that merge request or pull request. And then once that feature has been sucked back into the main branch, you can then clean up that branch that was specifically designated for that new feature by simply choosing Delete branch right here. So now, at this point, if we come back into our repository here and we take a look at the branches in our project, you can see that that my-new-feature request branch has now disappeared because we are completed adding that feature.

11:59We've merged the code back into the main branch here, which you can see we've got a package.json file here. And we deleted that branch from the pull request. And so now, that branch has been cleaned up keeping our Branches section nice and tidy here. You can also see right here that the branch is now down to one branch. We go over to all branches. We are now stuck with just our main branch, instead of that feature request branch that is now defunct because we're done using it. All right, so that's how we can do some merge requests between different branches.

12:30I know it's kind of an advanced topic. But it's a very common function that you'll be doing inside of GitHub. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] Hey, guys, and welcome back. One of the other features of Git as well as GitHub is the ability to create tags on your repository. Now, when we look at the branches section right here you can see we've only got the main branch right now. And in the last video, we actually had that second feature branch. But we've got this little tab right here next to Branches called Tags.

0:34So if we click on Tags, you can see that right now there is nothing in there. If we go to View All Tags, that actually takes us to a completely separate screen here where it says "there aren't any releases." And we've got this little tag icon indicating that we're doing something pertaining to tags on our Git repository. So Git itself without GitHub is the concept of being able to tag a commit with a particular version number. And this is really useful if you're creating different releases, maybe you've got like a 0.1 release, a 0.2 release, 0.3, et cetera, et cetera, and eventually you work your way up to like a 1.0 release.

1:13And so you can actually use these tags to refer to specific historical commits in your history if you're in your commit history here. So if you click on Commits, you can see all these historical commits. And we can use a tag to point to a particular commit and give it a label. You can think of a tag like a label almost and it allows you to kind of zoom to a particular point in time. And you can see the source code for your software based on the version tag that you associate with it. Now, a tag doesn't have to be a version number, you can use whatever you want to for a tag.

1:47You could give it like a name. If you're naming your different software releases, then you could call it some funny name like a platypus or something. And you don't necessarily have to use version numbers specifically, but you do just want to give it some kind of identifier that allows your team to recognize that release of a particular piece of software is like a production release or a dev release or something like that. So on the GitHub user interface, so now if we shift away from talking about Git tags specifically over to the GitHub user interface, on the right hand side, you'll see this releases section in each repository.

2:23So every single repository as releases. And you don't have to use this feature necessarily if you don't want to, but it does allow you to pinpoint points in time where you are releasing a specific version of your software package. And it allows you to include some binaries as well as inline documentation as well. And you can associate these releases with tags in your Git repository. So when we're looking at tags right up here in the top-left corner in the branches dropdown right here you're also going to want to be looking at this releases section right down here because this is where you are going to see any released tags in your repository.

3:04All right, so let's go ahead and say that we wanted to take our current repository here and create a new release from it and therefore tag our repository. So what we could do is either just come over here to Tags and say View All Tags. That's going to take us over to the releases section. And we can click on Create new release because at the moment, we don't have any tags in our repository. That takes us over to the releases tab here. And if we click on Choose a Tag right here, you can see that we don't have any tags listed.

3:34So we could choose Create New Tag, but if you don't type anything in this little text field here, then it doesn't actually create a tag. So we can type something here. So let's say this is version 0.1 of our software. And you can see that text changes right here where it's going to create a new tag when we publish this software release. So it hasn't actually created the tag yet, even though it looks like it kind of committed that change there it doesn't. It hasn't actually committed that tag to our repository yet until we actually scroll down and hit Publish Release. But before we do that, let's talk through some of the other options here.

4:08So right here we can pick the target for this particular tag. So we could use the head of the main branch, so where the main branch currently is at-- I'm going to middle click this here again to open up a new tab so we don't lose our spot. But we could basically take this code right here-- the latest commit where the head is on our commit history-- and basically say I want this commit right here to be the pointer for my tag or I should say, the entity that's being pointed to by the tag 0.1.

4:41And so that has a commit ID right over here. Here's the full commit ID right here. And so our tag would essentially be pointing to this particular commit because that is where the head of the main branch is currently at. Now, if you don't want to necessarily use the latest commit or the head of the main branch as your tagging target, then you can click on recent commits over here and GitHub will show you a list of the recent commits that we were just looking at. So these commits right here you can see we've got EC042.

5:13Though if we go back and actually look at our repository-- click on Commits right here-- you can actually see that this commit history right here along with all these commit messages corresponds directly to what we're seeing in this recent commits right here. So we can also search for these commits. And then we can just choose one of those commits as being our target. So I can choose a specific commit in history and it doesn't necessarily have to be the latest commit in the main branch. So once we've chosen a commit that we want to point to-- I'm just going to choose the latest one here-- you can give the release a title.

5:49And you could say this is a production release 0.1. And then down here, you have the full markdown capabilities where you can format the release. So if you want to use headings or you can use the hash signs to do an H3 heading or a H2 heading. We'll say "production release 0.1" and "congrats team on 0.1 release." Awesome. And then you can just preview that right over here. So you can see this as a heading or H2 heading and then this is just some random text right down here.

6:22Of course, you can add in other advanced features using markdown capabilities like links or checkboxes or bullet point lists and things like that. But basically we'll just use this as a release right here or release text. And then right down here, you can see that we can actually drag and drop binary files and attach them to the release. So if your software deployment process involves compiling some binaries and you want to distribute those binaries to your end users, you can actually just drop those right here and indicate that those are associated with a particular software release at this commit here.

6:58Though, you also have this checkbox right down here called "this is a pre-release." And this is basically just an indicator, it's kind of just like a flag to the GitHub platform that this is a pre-release so it's not ready for production release yet. And so this is especially good if you're publishing open source publicly accessible software projects just to kind of indicate to users who may not be intimately familiar with your software package that this is not really ready for full production and that only more advanced users should really be using that pre-release.

7:29So at this point, if I click on Publish Release, you can see we've now got this new release. We've got our release title right up here. We have this little tag here that, based on that checkbox that we just checked indicating that this is a pre-release version, a preview version that's not ready for production deployment. It shows us the commit. And we can actually click on that commit to go directly to that latest commit to see what changes were made for this particular release. We have our release notes right down here. This is a really good spot for you to be very thorough with your release notes to indicate what new features have been added to your software or what bugs have been fixed in your software.

8:05Generally, this is a really good spot to indicate to your users what those things are specifically. And then you can see, even though we didn't personally attach any assets or binaries to our release, we didn't drag and drop anything into that drop point on the form, however GitHub has automatically taken a snapshot of our source code as both zip formats as well as tar.gz formats. And it's attached to our release that we can just download that source code locally onto our local system and extract that.

8:36And then we can see an exact snapshot of our code at that point in time. In case there's any bugs or unexpected behaviors that we need to debug, we can take a look at that source code without having to worry about cloning it from this commit here. And then right down here we've got a little smiley face emoji. And if you click on that, you can basically just react to the release. You can get people excited about it and say, oh yeah, this is our first release. And people can react and click on the different emojis just to indicate their level of excitement about it. Now, once we've got this release, if we go back to the main user interface here for our repository and click on the branches dropdown here and then go to tags, we'll check it out, before we didn't have any tags but because we went through that release process it actually created a Git tag for us.

9:23And we can now click on that Git tag and it'll take us over to our repository at that particular image, that snapshot. And you can see right here we've actually got that EC042A9 commit ID-- that commit hash rather-- that indicates to us that is what this tag is pointing to. So GitHub itself uses this concept of releases in order to create these tags on your Git repository itself so that you can release software based on specific commits and keep track of your tags through this tagging section right here.

10:00I hope this has been informative for you. And I'd like to thank you for viewing.

0:11Hey guys, and welcome back. In the last video, we took a look at releases and tagging specific commits so that you can link different versions of your software, different releases with a particular commit and then release that as a release over on the GitHub UI here in your repository. Now, one of the other cool features about GitHub is the ability to link pull requests and issues together so that you can streamline your process of resolving bugs and adding features and things like that. So bear with me here for a second as we just go through a mock scenario.

0:45So let's say that there is an issue with our project. Let's say there's something like a missing file, for example, or something. And somebody, some third party user out there, comes along and opens an issue. So they go to the issue tracker, they create an issue, and they say, hey, script2.ps1 is missing. All right, so we'll submit that issue. And so now we have our first issue inside of our code repository here. So now let's switch back. So put on a different hat here and say, OK, I as a software developer, I'm going to go ahead and take ownership of this issue and fix it.

1:19So of course, one of the first things I'd probably do is just assign myself as the owner of that particular issue. And so GitHub will then just update and basically say that I've assigned myself. And you can see that right here, pcgeek86 self-assigned. But now we actually need to implement the fix for this particular issue. So the issue ID here is number three. So just keep that in mind as we're going along right here. So what we're going to do is come over here into code and we are going to fix this by let's say, adding a script called scripts2.ps1.

1:53OK, so we're just going to quickly add a new file here, and create new file scripts2.ps1 and just put in some random code, do something a high 100 times. All right, and so we're going to add this new script file but in our commit message here, we are going to add something special. And I am going to say adding script2 and I'll say fixes number three. So if I do fixes hashtag three, that's referring to issue number three in the issue tracker for this particular repository.

2:29So now I can go ahead and open up a new feature branch here. So let's call this fix-issue-3, for example. And we'll say propose new file. All right, so now we've got to this new branch that we've created. And if I just middle-click here and go over to the UI, you can see that we've got this new branch fix-issue-3. And that's what we're on right here for this pull request screen. So what I want to do is essentially open up a pull request and say, hey, I need somebody to peer review this fix. And I'm going to take this fix-issue-3 branch and I want to merge it back into main.

3:03So I'll go ahead and say create pull request. All right, so if we go over to Issues right here, you can see that this issue is still open. Nothing has changed in that regard. Nobody's come in here and commented on it or closed it or anything like that or changed the status of it. The only thing that we did is we opened a new issue, and we self-assigned ourselves as the developer who's going to fix this issue. So if we drill into this issue here, you can now see that this new entry has been added to the issue log because we opened a pull request that references this particular issue.

3:37So by adding that hashtag 3 into our commit message, we've now bound it to this particular issue. And it's now tracked the fact that we've opened up a new pull request against this particular issue. So the pull request is still open. It's still pending. We haven't actually merged that fixed branch back into the main branch yet. But once we do that, look what happens. I'm going to go back over to my pull requests here, the pull request itself has an ID of 4. Let's open up this pull request. And so I'm going to come in here and basically just kind of peer review this and say, all right, looks good.

4:12Here's the commit. Let's take a look at the commit really quick. All right, it adds script2.ps1. So that file now exists. All right, everything looks good. So I'm going to say merge the pull request. And we'll do a confirm merge and check it out. So we've merged just like we did in an earlier video. And we can clean up that bug fix branch now that we are done fixing the bug and we no longer need it. But check out what's happened here. So if we come back over to Issues, all of a sudden, that issue disappears. Now we have zero open issues, and we have one closed issue.

4:44So this is just kind of a workflow enhancement that GitHub provides in addition to the issue tracker and the pull request management capabilities. It's basically said, all right, this issue was automatically closed because it was referenced in a pull request that has now been merged into the main feature branch. So now we can assume that that issue has been safely fixed and GitHub has automatically closed that for us saving an extra step in the issue tracking process. I hope this has been informative for you, and I'd like to thank you for viewing.