Introduction to Source Control with GitHub

0:11Hi, guys.

0:12My name is Trevor Sullivan, and welcome to another CBT Nugget

0:15skill.

0:15In this skill, we are going to be introducing the GitHub

0:19platform, which is typically used

0:21for hosting source code for version-controlled software

0:25packages.

0:25And what we're going to be doing is taking a look

0:27at how to use GitHub as a revision control system.

0:31Now oftentimes, you're going to be working

0:33with a tool like GitHub by using the Git

0:36CLI or other tools like Microsoft Visual Studio code

0:40or other editors out there that you might

0:42be using to actually author your code locally

0:44on your dev system.

0:46But in this particular skill, we're

0:47going to be focusing on the actual web user interface

0:50so that, if you're new to GitHub,

0:52you don't have to worry about setting up

0:53any third-party tools.

0:55You don't have to worry about getting the Git CLI connected

0:57to GitHub and things like that, because that involves

1:00things like SSH keys and a little bit

1:02of extra configuration that's specific to the Git CLI tool.

1:06But we're going to be specifically exploring

1:08the GitHub user interface and understanding

1:11how to use that to do things like creating files,

1:14to create branches within a repository.

1:17We'll understand how organizations work, at least

1:19at a high level, and repositories, and some

1:21of the functionality that exists within those utilities

1:25like organizations and repositories.

1:27Those things have things like team management and issue

1:30tracking, project tracking, and a lot of advanced functionality

1:33that's available to help you manage your software projects.

1:37Now before we get too far deep into GitHub,

1:39I did want to point out that there's

1:40a lot of different tools out there that you can actually

1:43use in order to manage your source code.

1:46Now GitHub, obviously, the name implies

1:49that it's very Git-centric.

1:50But there's actually lots of other tools out there, as well,

1:53that don't necessarily reference Git in their name,

1:56but are actually using Git under the covers

1:58for doing version control.

2:01And some of those different tools

2:02are things like a AWS CodeCommit.

2:04So AWS CodeCommit is a managed hosting service

2:07that allows you to host source code using a Git revision

2:10control system and then integrate and do things

2:13like continuous integration using other services

2:16within the AWS ecosystem.

2:19Additionally, Microsoft Azure is another one of the big three

2:22cloud vendors out there.

2:23And they have a tool called Azure DevOps, which

2:25has a lot of similar overlapping functionality with GitHub,

2:29as well.

2:29And what they've got is things like a wiki for documentation.

2:34They've got things like your Git repository

2:37itself that you're actually pushing code to,

2:40things like pipelines for continuous integration

2:42and continuous deployment, as well,

2:44and some projects tracking things

2:46like creating these boards and creating issues and backlogs

2:50and things like that.

2:51So there's some project tracking things built into Azure DevOps,

2:54as well.

2:54And then if you're looking for something that's

2:56a little bit more self-hosted, there's

2:57actually tools like Gitea, which is basically

3:00an open-source package that you can run yourself.

3:03And it actually resembles the GitHub user interface.

3:05If you look at what the GitHub user interface looks like over

3:08here, you can see there's these different tabs across the top

3:10here.

3:11And if you were to drill into a specific repository

3:14within an organization, you'll see a different set

3:16of tabs that correlate to the different entities that are

3:19associated with a repository.

3:22And you can actually see that very similar structure

3:25right here in Gitea, where you've got things like an issue

3:28tracker, and pull requests, and releases,

3:30and a wiki for documentation, and things like that.

3:32So this is a fully-featured, self-hosted version

3:35of basically just a Git version control

3:38system, along with some project management capabilities.

3:41And then there's another pretty popular one out there, as well.

3:44It's built in Go.

3:45And this is called Gogs.

3:46And this is very similar.

3:48It's a self-hosted version of GitHub

3:51you can kind of think of it in a way.

3:53Obviously, it's a totally separate tool.

3:54But it is open source, and it's built in Golang.

3:57So these are just some alternative options

3:59that you have to GitHub.

4:01And they live in that ecosystem of doing

4:04things like version control for your software packages,

4:07as well as some project management

4:09capabilities like having an issue tracker,

4:12and the ability to create pull requests,

4:14and CI/CD functionality built in,

4:16and a wiki for building documentation for your software

4:20project, and a bunch of different capabilities

4:23like that.

4:23So what we're going to be doing in this particular skill

4:25is focusing on specifically GitHub,

4:27specifically within the web user interface

4:30and understanding how things like organizations

4:32and repositories work.

4:34And then we'll drill into actually

4:36how to use the GitHub UI to actually create

4:39some files in your project and then do things like open pull

4:42requests if you are going to submit some code to somebody

4:45else's project, for example, and things like that.

4:48So in any case, let's go ahead and jump into our next video.

4:50And we'll get started.

4:52I hope this has been informative for you,

4:53and I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:11Hey, guys and welcome back.

0:12In this video, we're going to take a quick look

0:14at organizations and understand what

0:16the capabilities of a GitHub organization looks like.

0:20Now, when you initially sign up for your GitHub account,

0:23you're going to have a username.

0:25My username just happens to be pcgeek86.

0:28That's my unique identifier that I use on various places online.

0:32And when you create a user account in GitHub,

0:35you'll have the ability to create code repositories

0:38within that user account.

0:40So for example, here are some different repositories

0:43that are directly associated with my user account.

0:46And I can push code to those repositories,

0:49I can create issues in those repositories.

0:51I can make them public or private,

0:53and configure them however I want to.

0:54They're basically just places for me to store my code.

0:58Now, if you are working in a team environment

1:00where you need to share access to a repository,

1:04it's oftentimes advantageous to create something known

1:07as an organization in GitHub.

1:10And once you're logged in to GitHub,

1:11you can actually just create that right here

1:13in the top right hand corner, they create a new organization.

1:17And then when you create an organization,

1:18this is just kind of a stub or a kind

1:21of a placeholder for your repositories

1:23that your company will be creating in the future.

1:26And so you can choose either a paid plan here,

1:29which includes some advanced features,

1:31or you can use the free tier here, which is pretty generous.

1:35You can have unlimited public and private repositories.

1:38You have the ability to do up to 2,000 automation minutes,

1:41using GitHub actions.

1:43Which is kind of a separate topic in and of itself

1:45for doing continuous integration and continuous deployment.

1:48It's actually free for public repositories.

1:50But if you have private repositories,

1:52you actually do get 2,000 minutes

1:53included for free with organizations,

1:56which is pretty cool.

1:57You also have the ability to use the GitHub package storage

2:00system, which allows you to store things

2:02like NPM packages or container images

2:05if you're using Docker as a deployment mechanism.

2:08You get packages and a whole bunch of other things.

2:10So you can actually host up to 500 megabytes

2:12for free on GitHub packages to serve as a repository

2:16to host your modules, and then be able to download and install

2:20those modules to different systems from GitHub packages.

2:23Very similar to how you would use

2:25tools like Docker hub, or the NPM

2:27registry, or NuGet registry, and things like that.

2:31There's also the ability to create issues and projects

2:34within your repositories as well,

2:36and community support, basically meaning,

2:38you don't really get official support plan from GitHub.

2:41But if you want to go post on the GitHub community forums,

2:44you're more than welcome to do that,

2:46and to try to get some assistance

2:47if you do happen to run into any bugs in the platform.

2:51So what you can do is just click on create a free organization

2:55here.

2:56And you can just give that organization a name.

2:58So I might call this something like cbttrevorgithub,

3:03for example.

3:04And then, you want to provide a contact email

3:06address for GitHub to be able to reach out

3:08in case there's a problem with the organization in the future.

3:11And so I'll just do Trevor.Sullivan@cbtNuggets.com

3:15as my email.

3:16And then I could either select that this belongs to just me

3:19personally, or I could associate it with a larger company here.

3:23So for now, I'll just choose my personal account and hit Next.

3:27And then once you've created that organization,

3:30you have the opportunity to search for other users.

3:33Within the GitHub platform, you can search for them

3:35based on their username, like my username up here is pcgeek86.

3:38So if you know somebody else's username,

3:40you can just add them very quickly like that.

3:42Or you can search for people based on their names.

3:44So you could search for people by name.

3:46Here's a bunch of other Trevors out there in the world.

3:49Or if you know what their email address is,

3:51you can just plug that in, and it'll

3:52look them up by email address.

3:54So you have the ability to add people to this organization.

3:57And then you can assign permissions to them.

4:00So for now, I'm just going to go ahead and skip this step.

4:02And it's going to kind of put you through this little wizard

4:05here that asks you for some basic information,

4:08if you'd like to.

4:09I'm just going to kind of skip that for now.

4:11And now, we've got an organization.

4:13And an organization really isn't anything in and of itself,

4:17it's basically just kind of a high level entity that

4:19allows you to ultimately host your source code

4:22repositories underneath of it.

4:25Now, if I did have any repositories

4:26in my organization, that would show up right down here

4:29under this section, where we have repositories.

4:31You also can pin repositories as well.

4:34So that gives you the ability to kind of highlight

4:37important repositories that are maybe frequently accessed

4:40by multiple teams within your organization.

4:43And you can host those right here under the pinned section.

4:46And then right here under repositories,

4:48this is kind of a master list of all the repositories

4:50within your organization.

4:52Allows you to search through those repositories to find one.

4:55Maybe, you're searching for something

4:56by a technology title like MySQL,

4:58or maybe you've got some interesting naming convention

5:01for your organization.

5:02So you can search for those repositories in here,

5:04and then go in and view that source code.

5:06Also, within the organization, we

5:08have that packages capability that allows us to our modules.

5:12So you can host things like container images

5:14if you're building those with Docker.

5:15If you're building things like ruby packages,

5:17those are known as ruby gems, you

5:19can host those gem modules right up here on GitHub packages

5:23as well.

5:23There's also support for NPM if you're building in JavaScript.

5:27NuGet, if you're doing .NET devlopment,

5:29as well as other things like Apache Maven if you're doing

5:31Java development.

5:32There's a bunch of different providers

5:34that are supported in GitHub packages

5:36so that you can host those packages up there,

5:38and then distribute them.

5:39If you're doing things like production deployments or dev

5:42test deployments you can actually just

5:43download those modules straight here from GitHub packages.

5:47And then over here, we've got the people section here.

5:50And this is where you can invite other people to participate

5:54in your organization.

5:55Now, I've actually got another organization that I'm going

5:58to navigate to, called github.com/cbttrevor.

6:02I've already got this one created.

6:03And if I go over to this people tab here,

6:06you can actually see that, Dan, the founder of CBT Nuggets

6:09is listed here as well.

6:11And both of us have owner permissions

6:13to this organization, so any of us

6:16can actually make any types of changes

6:17that we need to, to this particular organization.

6:20We have full control over it.

6:21However, you can also invite outside collaborators as well.

6:25You don't necessarily have to add users

6:27as members of the organization.

6:29You can invite outside users and just

6:31give them limited access to certain repositories

6:34within that organization.

6:36Now, another concept that is really

6:38helpful within organizations, especially

6:40if you are working in a very large company

6:43is the ability to create something known as teams.

6:47Now, when you create a team, the team

6:49allows you to essentially assign limited access

6:52to certain repositories.

6:54You can kind of think of a team as like a sub-filter

6:56within the overall organization.

6:59Though, in my organization here I've got

7:00all these different repositories here.

7:02But these repositories could actually belong by definition

7:06to other teams, to certain teams within the organization.

7:09So maybe these first three repositories belong to team A,

7:12maybe the next four repositories belong to team B.

7:15And they're just kind of mixed and matched in there.

7:18And so what you can do to kind of filter that down

7:20and make things a little bit more logical,

7:21if you have hundreds or thousands of repositories

7:24in your organization, is to create

7:26something known as a team.

7:27Now, a team is kind of a subset of users

7:30within your organization.

7:32And so I've created this team right here called CBT Nuggets.

7:34And as you can see, it has a single member right now,

7:37so I'm the only member of this particular team.

7:40But the team allows you to have limited team discussions that

7:43maybe don't apply to the entire organization.

7:46So I've just got a little conversation thread

7:48going right here with myself, because sometimes I'd

7:50like to talk to myself.

7:52But it gives you a nice place to just kind of

7:54have those intra-team discussions amongst, maybe,

7:575 or 10 people, rather than hundreds or thousands

7:59of different people that are just kind

8:01of seeing a whole lot of noise.

8:03You can add additional members to those teams.

8:05And then, you can actually assign certain repositories

8:09to teams as well.

8:10So if there's a particular repository

8:12that you would like this team to have access to,

8:15you can just do a search for that repository.

8:18You can add that repository to this team.

8:20And so now, rather than seeing hundreds and hundreds

8:22of different repositories across my entire organization,

8:25my team is now limited to only seeing

8:27the actual repositories that are relevant

8:31to this particular team.

8:33You can do the same thing with projects as well.

8:35So if you have projects to find, you

8:36can go ahead and add those from within your repositories

8:39as well.

8:40And then add those at the team level,

8:41so that the team can kind of track those projects as well.

8:45So that's kind of what teams look like.

8:47So let's go back to our organization level

8:49right up here, and take a look at a couple of other things.

8:53Now, right over here, we've got the ability to create projects

8:57at the organization level.

8:59And then that's where we can also import them

9:01at the team level as well.

9:03So we could create a new project here

9:04and then we can track a project across our entire organization.

9:08And then we can add that project to the teams that

9:10are actually actively working on that project,

9:13that they're aware of where that project currently is.

9:16So let's go ahead and head over to repositories here.

9:19And we're going to create our first repository

9:21in the next video, and actually take

9:23a look at how to do some source control

9:24inside of our organization.

9:26I hope this has been informative for you.

9:28And I'd like to thank you for viewing.

0:11Hey, guys, and welcome back.

0:12So in the last video, we took a look

0:14at some of the high-level functionality that's

0:16available within the GitHub Organizations feature here.

0:19And now we're actually going to create our first repository

0:22from scratch.

0:23I know I've already got a whole bunch of repositories here.

0:25But we're just going to create a brand new one that's fresh,

0:28that doesn't actually have any files in it.

0:30And we'll just kind of learn how to use the GitHub web

0:33interface.

0:33In order to create and manage source code from our browser.

0:38So in my organization here, I'm just

0:40going to go ahead and click on a New Repository.

0:42And then if you have other organizations,

0:45you can actually just click this dropdown box

0:46and choose which organization you want it to belong to.

0:49I'm just going to choose my existing organization here

0:51called cbttrevor.

0:53And then you'll want to give the repository a unique name

0:56within your organization.

0:58So we could give this a name like

1:00github-intro-source-control, for example.

1:05And then you can provide a description

1:06that just kind of uniquely identifies this.

1:08So let's say this covers GitHub basics in the browser.

1:16And then you can choose a visibility level.

1:19So if you make it public, that means that anybody

1:21on the internet who has a GitHub account--

1:23or even if they don't have a GitHub account, even if they're

1:26not logged into the GitHub user interface--

1:28they'll be able to see your source code.

1:30So if you're working on a private project

1:32and you don't want the internet at large

1:34to be able to see your project, you

1:36want to make sure that you choose private here.

1:39And again, the nice thing about the free tier

1:40of GitHub organizations is that you can have

1:43unlimited private repositories.

1:45So you're not really having to pay for that functionality,

1:47unless you need some more of the advanced features of the paid

1:50tiers.

1:51Now, right down here, you have these options

1:53to initialize the repository with a few key files.

1:56And you don't have to choose any of these.

1:58I mean, these are really just kind

2:00of helpers that will basically just create stub files for you.

2:03But if you know what you're doing

2:05and you can just create these files from scratch,

2:07you can just leave these unchecked

2:08and just create a totally empty repository.

2:11Now, these files are special in GitHub repositories,

2:14because the file named README or README.md inside

2:18of the root of your repository will actually

2:21be rendered directly inside of your web browser

2:23when you visit that repository's page.

2:26So that'd kind of serve as a really nice landing

2:28point for any introductory level documentation.

2:31Or if you need to link out to other documentation,

2:33you can just add that README file.

2:34We'll take a look at how to do that manually.

2:36And then there's also the ability

2:38to add a gitignore file.

2:39And this is really important any time

2:41that you're working with the git version control system.

2:43Because if there are files being added to your project that

2:47are kind of temporary in nature, then you typically

2:50want to use this special file called

2:52gitignore to actually prevent those files from being

2:55committed to your source control repository.

2:57Otherwise, you'll get a whole bunch of junk

2:59inside your repository that doesn't actually

3:01pertain to your application's source code.

3:04And then down here, you've got the ability

3:06to choose a license.

3:07And there's a whole bunch of open source software licenses

3:10that are kind of prepackaged here.

3:12So if you don't want to have to go to a separate website

3:14and say, show me the MIT license, for example.

3:17And then click on this website, and then go and copy

3:20and paste the actual text of the license right

3:22here, and then copy it into your project.

3:25It just kind of saves that additional step, where

3:27you can just search for a license right here,

3:29choose that license, and GitHub will go ahead and just

3:32include that in your repository as a license file.

3:36So let's click on Create Repository here.

3:38And as you can see, we've got a fresh repository here.

3:41There's not really any code inside of it.

3:44We do have this license file that we just generated.

3:46So if we click into that, sure enough,

3:48GitHub has kind of detected that it's the MIT license.

3:51And you can see it's put in this copyright statement

3:53here for CBT Nuggets.

3:55And it's got the actual text of the MIT license itself.

3:58And they also give you kind of this brief overview.

4:00So if you're working with open source projects,

4:02it shows you what you can and can't do at a very high level.

4:05Obviously, it's not a substitute for legal advice.

4:08But it gives you kind of a high-level overview

4:10of whether it's permissible for businesses to use that software

4:13or if there's warranties included in the software,

4:16and things like that.

4:17But in any case, this is kind of a fresh git repository.

4:20And remember that with git, when you are working on a shared git

4:25repository on GitHub, or if you're

4:27using one of these privately-hosted solutions,

4:29or anything else, because git is a decentralized source control

4:32system, the GitHub repository that we have here is only

4:37going to be considered kind of the master repository

4:40for a team of people who are working on a project

4:43simply by consensus.

4:45So if I were to take a copy of this,

4:47and if I were to clone it locally using this SSH URI

4:51right here, then that would be entirely cloned down

4:55to my local system, and I'd have a full copy of everything

4:58that is on the GitHub server here, so to speak.

5:02So git itself is decentralized.

5:04And so you actually get an entire copy of this repository,

5:09if you were to clone that locally on your dev system.

5:12There's nothing really special about the git repository

5:15that's hosted on GitHub, other than the fact

5:17that my entire team kind of essentially

5:19agrees that this is going to be the central place where

5:22we collaborate on source code.

5:24So just keep that in mind.

5:25It's a really important concept in git overall.

5:28Now, over here in the top left corner,

5:30you can see that we have this Branches section here.

5:32And traditionally, this has been called the master branch.

5:34But GitHub has actually renamed it

5:36to be called the main branch.

5:37It's basically just a name for the primary branch that's

5:41going to host your source code.

5:42However, you can create many other branches in here as well.

5:46And branches are typically used in git for things

5:49like creating new features.

5:51Or if you're working on some really advanced feature

5:53and it's going to take you a couple of weeks

5:55to kind of implement that feature and test it out,

5:57then you can create a separate branch for your code,

6:00and give it a name like my-new-feature,

6:04and go ahead and create that branch.

6:07And then any code that we now submit or commit

6:09to this particular branch is not going

6:12to impact the main trunk here, which allows us

6:15to kind of focus on our production-ready features

6:18that are actually ready to be deployed out to our actual end

6:21users.

6:22So using this branching capability

6:23is really helpful, if you need to work on a feature

6:26separately, or maybe work on a bug fix,

6:29and you don't want to risk breaking the code that

6:31is in your main branch.

6:33Oftentimes, if you're working in a team environment,

6:36you'll see lots of different branches listed here.

6:38Maybe those branches have new features.

6:41Maybe they're bug fixes.

6:42They could even be something as simple as just documentation

6:45branches, where somebody is working on building out

6:47a documentation platform that generates documentation,

6:51like MkDocs for Python, for example.

6:53Or maybe they're building a website in XJS or something

6:56to host those documentation.

6:58So they could work on that in a separate documentation branch.

7:00And then in the future, they could merge that,

7:02once it's kind of tested and ready to go, on the main branch

7:06here.

7:06And then in addition to branches,

7:08you 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

7:14repository, those tags would show up here.

7:18This is kind of what an empty repository looks like.

7:20We have these kind of more advanced features here

7:23that are specific to GitHub, not git itself as a version control

7:28system.

7:28But the GitHub platform has the issue tracker, the ability

7:32to create pull requests.

7:34There's actions, which is a CI/CD system.

7:37It allows you to automate different workflows

7:39within your project.

7:40You also have projects here, which

7:41allows you to do kind of project management

7:43and prioritize feature requests and bug fixes.

7:46We've got the wiki right here that allows

7:48us to build documentation.

7:50We also have security here.

7:51So we can assign certain security policies

7:54to do things like scanning against our repository

7:56for potential vulnerabilities.

7:57Those are some more advanced features

7:59that are specific to GitHub.

8:00But we're going to focus a little bit more

8:02on the Code section here and actually understand how

8:05to create files in our project.

8:07So if we had a totally empty repository-- let's just

8:10pretend that this license file doesn't even

8:11exist in our repository-- we can add a file to our repository

8:15simply by clicking on Add File over here.

8:17And then you can either upload a file from your local file

8:20system, which is kind of convenient,

8:22because if you have a code file that you've-- maybe a script

8:24that you've been developing locally and you just want

8:26to add it into your repository, you can upload that.

8:29Or if you actually want to just create

8:30a new one in your web browser, we

8:32can click on Create New File.

8:34Now, that's going to take us over to this other user

8:36interface here, where we can give the file a name.

8:40So we could call this something like myscript.ps1.

8:44ps1 just happens to be the file extension for PowerShell

8:47scripts.

8:47And then down here, we can go ahead and just edit our code.

8:51So I could do something like Get-ChildItem or Get-Process,

8:54for example.

8:55And this is going to basically allow

8:57us to edit our code directly in the web browser

8:59without having to go through the process of cloning

9:02our repository locally, and then committing locally, and then

9:06pushing back up to GitHub.

9:07Anything that we commit right here

9:09is just going to be committed directly

9:10to our source code repository that is hosted on GitHub.

9:15So once you've made some changes to your file

9:18here, if we just scroll down a little bit,

9:20you can see we've got this commit.

9:21And this is going to allow us to add a commit message.

9:25I'll say adding my first PowerShell script.

9:29Of course, this could be any type of code

9:30that you want it to be.

9:31You could create a Python file, a Ruby file, a Java file,

9:35pretty much anything you'd like to.

9:37I just happen to be creating a kind of PowerShell sample

9:39script file here.

9:40And then you'll be able to choose different email

9:42addresses that you have associated with your account.

9:45Apparently, I don't have my CBT Nuggets

9:47email listed right here.

9:48But you can just choose one of the email addresses

9:50that you want to be used when you are creating this commit.

9:53You can also add an extended description here

9:55to kind of describe what changes you're making.

9:58And then you can either commit directly to the main branch,

10:00or if you have a named branch or you

10:03want to commit to a new branch, then you

10:05can just choose that option right down here.

10:07And I could just call this something

10:08like powershell-scripts.

10:09And this will create a brand new branch for my project.

10:13But for now, I'm just going to go ahead and commit to main.

10:15Let's choose Commit New File.

10:17And sure enough, you can see that this file has now

10:19been added to my source code repository.

10:22I can click into it.

10:23And you can see the GitHub user interface on the web interface

10:27for GitHub is actually showing us the syntax highlighting

10:30for our script here.

10:31So because it's PowerShell and it has the ps1 extension here,

10:35GitHub knows that this is a PowerShell script file.

10:37And so they're able to do some syntax highlighting

10:40and make it look a little prettier for our editing needs.

10:45All right, so that's how we can add a new script

10:47to our repository here and how we

10:50can create a brand new repository in our GitHub

10:53organization.

10:54I hope this has been informative for you,

10:55and I'd like to thank you for viewing.

0:11Hey, guys, and welcome back.

0:12In the last video, we took a look

0:14at how to create this new script file, called myscript.ps1,

0:17in the root of our project here, and we

0:20committed that file to the main branch in our source code

0:24repository called GitHub Intro Source Control right up here.

0:28And that's part of our GitHub organization called cbttrevor

0:31right here.

0:32So now that we've added this file,

0:33what if we wanted to make some changes to that file?

0:36Well, right over here on the right-hand side

0:38of the user interface.

0:39You have a few different options.

0:40So this button right here called Raw

0:43that just allows us to see the actual raw text

0:45without any extra formatting, like syntax highlighting,

0:48being applied to it.

0:49That's a really nice view.

0:51If you just want to copy some text to your clipboard really

0:53quick, you can just go into this raw view and copy of that

0:56to your clipboard and then paste it into another application.

0:59I do that on a fairly regular basis.

1:01You also have this blame option here

1:02that's kind of cool because it'll actually show you

1:04who made changes to which specific lines in a file right

1:08here.

1:09So you can see that Trevor Sullivan right here

1:11made changes to lines 1 and 2.

1:13But if another user came along and added a third line

1:16or maybe changed something on line number 1,

1:19then that would actually show you.

1:21It would kind of blame that particular person

1:24for making a particular change to a specific file

1:27in your source repository.

1:29So that's a really useful feature as well.

1:31And then right over here, we have the option

1:32to use the GitHub desktop app, which we're not

1:34going to talk about right now.

1:35We can also delete the file from our repository.

1:37But then, right here in the middle,

1:38we've got this little pen.

1:39And if you hover over that, you'll

1:41see that you can edit that file.

1:45We're back in this Editor view, where we initially authored

1:48our file.

1:49And so this interface, once we have an existing file,

1:52it's going to allow us to do things like rename the file,

1:54for example.

1:55We could actually change the file name right up here.

1:57We could also make some changes to our script right

2:00here and just say get process for each thought process.

2:04It's kind of a dangerous thing.

2:05And we'll just kind of attempt to stop all processes

2:07on your system.

2:09But we could make that change, and we could

2:11add additional commits here.

2:12We have the same options to commit directly

2:14to the main branch, or we could commit to a new branch here.

2:17But what I wanted to show you right here

2:19is that if we wanted to actually move this file--

2:22so right now, this file is in the root

2:25of our repository right here.

2:27So we don't have any folders in our project at the moment.

2:30But if we wanted to put this file into a folder,

2:33we would actually edit the file.

2:35And then right up here in the file name,

2:37we could type a folder.

2:38Let's say we wanted to create a subfolder called scripts.

2:41So I'll just type scripts and then put a forward slash.

2:43And GitHub will automatically detect

2:46that I want to create a folder, and so then it'll

2:49allow me to change the name of this particular file

2:53and actually place it into a folder.

2:56So that's kind of cool.

2:57So you can also hit backspace.

2:58And even though it's not necessarily too obvious

3:00that you can actually do that, if you just

3:02go to the beginning of this box here,

3:04if I wanted to change the name of that folder

3:06to something like PowerShell, for example,

3:09I could put a forward slash there.

3:10So if you want to change the name of a folder

3:12or if you want to--

3:13if you're nested several folders deep in this file name,

3:16you can actually just hit backspace right there,

3:18and that'll allow you to either remove a folder from the path

3:22or correct the name of one.

3:25So let's go ahead and commit this change then.

3:27So essentially, we're just moving

3:28this file over to PowerShell.

3:30We'll come down here and just say moving to folder.

3:34And we'll say commit changes.

3:37And if we go up into the root of our repository right here,

3:40you can now see that we've got a folder here by this folder

3:44icon called PowerShell.

3:45And then if we drill into that, sure enough,

3:48you can see that we've got this myscript.ps1 file in here.

3:52All right, so that's how we can kind of

3:53manage our folders here.

3:56But what if we wanted to do some branch management as well?

3:59So let's say that we wanted to add a new feature

4:01into our project, but we wanted to put that

4:03on a totally separate branch?

4:05Well, right now, I've actually got this branch right here

4:08called my-new-feature.

4:09So let's actually click into that.

4:11And actually, there's nothing here.

4:13So why is that happening?

4:14Well, let me hit the Back button on my mouse here really quick,

4:17and I'll explain why that's happening.

4:19So if we go back to the root of our source control repository

4:22and we now try to go over into my new feature,

4:25check out what happened.

4:26Well, back when we created this branch called my new feature,

4:30remember, we didn't actually have that PowerShell script

4:32file created.

4:33So the only file that actually existed inside

4:36of the repository is this license file.

4:39So after we created this branch, we

4:41went back to the main branch.

4:43And then we added that script file into the root.

4:46And then we renamed that script file to essentially

4:49move it into a folder here.

4:51So because I am in this PowerShell folder

4:55right here at the moment, if I try to switch over

4:57to my-new-feature, well, this page

5:00doesn't exist because the PowerShell

5:03folder doesn't actually exist inside

5:06of the new feature branch.

5:08So that's why we're getting that 404 message when

5:10we're in the PowerShell folder, and we tried

5:12to navigate to a different branch that doesn't even

5:15have that folder as part of that branch.

5:17That's why we're seeing that 404 error message.

5:20So if we just go to the root of our repository

5:22and then navigate over to that branch, OK, now,

5:25we can kind of see that we have just this single file here.

5:29And we don't have that PowerShell script.

5:30Now what else is helpful here is that it tells you

5:33that this branch is two commits behind main.

5:36And so what that's telling us is that somebody

5:38else on our team--

5:39well, in this case, it was just me-- but somebody on our team

5:42has actually added code by committing to the main feature

5:47branch here.

5:47And so this branch is now in front of the my new feature

5:51branch.

5:52And we can see that.

5:53If we click on the Branches little icon right here,

5:55this will actually show us all of the branches right here.

5:59And so if we just go to all branches,

6:01it'll actually show us that the main feature branch was updated

6:06two minutes ago, and my-new-feature

6:08was updated 13 minutes ago.

6:10And it tells you which user name in GitHub

6:12has actually made those changes.

6:14So we can see that my-new-feature is definitely

6:16older in terms of time than the main feature branch here.

6:21So one of the things that we can do

6:23is actually to suck in the changes that

6:25were made to the main feature branch back

6:28into the my-new-feature branch.

6:30So what we can do is create a new pull request,

6:32and we can basically say that we want

6:34the base to be my-new-feature.

6:38And then I want to bring in the changes from the main branch

6:41here.

6:42We'll say importing main, and we'll say create pull request.

6:47And then I'll just go ahead and approve this merge request

6:51right away.

6:52So I'll just say confirm merge.

6:53And once we do that, we've now merged the main feature branch

6:58back into the my-new-feature branch.

7:00And so now, our feature branch should be up to date

7:04with the main branch.

7:06So now, let's go back to my-new-feature branch.

7:08And sure enough, you can now see that the PowerShell folder does

7:13exist inside of the my-new-feature branch

7:15because we effectively basically took all the changes in main,

7:18and we imported those over into our feature branch right here.

7:22So now, they're kind of in sync with each other.

7:25And you can actually see that this branch

7:27is one commit ahead of main only because we applied

7:31this merge request as a pull request in GitHub

7:34from the main branch.

7:36So later on, we'll go ahead and actually merge this feature

7:38branch back into main.

7:40But first, let's go ahead and make a change

7:42to this particular branch.

7:44So we'll add another file to this branch.

7:46And let's just call this something like package.json,

7:50and we'll just create an empty JSON object here.

7:53Package.json is commonly used in JavaScript projects.

7:55So we'll just kind of pretend that we're creating

7:57a JavaScript project here.

7:58And I'll say adding package.json to root of project.

8:05And then we'll go ahead and commit it

8:07to my-new-feature branch.

8:08Now, in this case, you can actually

8:10see that this radio button here is not

8:12referring to the main feature branch

8:13because, in the GitHub user interface--

8:16I'm going to middle-click to open a new tab here--

8:18I actually already had this feature branch selected

8:21so any time that I add a new file

8:24or if I go in and try to edit a file,

8:27the commit is actually going to be

8:29applied to the feature branch that you are currently on.

8:32So you want to be paying attention

8:34to which feature branch or which branch in Git

8:37you are committing to so that you're not accidentally

8:39committing to the wrong feature branch.

8:42All right, so now, we've added this kind of new--

8:44let's just call it a feature.

8:45We've added this new file into our project,

8:47and it's now under the feature branch.

8:49So now, if we go back to our main trunk

8:51here, our main branch, you can actually

8:53see that it does not incorporate that package.json file.

8:57So you can see right here the GitHub has

9:00detected that our feature branch has

9:02had recent commits against it.

9:05And so GitHub is kind of hinting to us as developers that maybe

9:09we want to incorporate this new feature into our main branch

9:13here.

9:14So to do that, it gives us this little shortcut

9:16to basically do a comparison and a pull request,

9:18kind of like what we did before.

9:19But in this case, instead of importing main into our feature

9:23branch, we actually want to take what's in our feature branch

9:25right here and import that back into main.

9:28And see this little arrow right here.

9:29It's kind of pointing at whatever branch

9:31you're looking at on the right-hand side

9:33is going to be sucked in to the branch on the left-hand side.

9:38So I'm going to rename this pull request

9:40and say importing my-new-feature or importing

9:43new feature into main branch.

9:46And I could leave a little message for my team

9:48here kind of indicating what changes were made.

9:50Let's go ahead and create this pull request.

9:52And so, now, we've got a pull request,

9:53and we can go ahead and just merge it,

9:56like I did before where I merged main into the feature branch.

9:59But before we do that, let's actually take

10:01a look at some of the options that we

10:03have here in the pull request.

10:05So before we actually merge the pull request,

10:07let's say we actually want to review what changes were made.

10:10The write-up here, we've got commits.

10:12And this allows us to see a history of all the commits

10:15that were made to this particular branch.

10:19I should say, more correctly, actually,

10:21that it's all the commits that were

10:22made as part of this particular pull request.

10:25So you can see that we have a pull request that we previously

10:30had merged the main branch into our feature branch.

10:33So that was the first commit that we

10:34had into the feature branch.

10:36And then just a minute ago, we added this package.json file

10:39into our feature branch as well.

10:41So basically, any changes that were

10:42made as part of these two commits

10:44will then get merged back into the main branch.

10:48If we actually click on one of these right here-- so

10:51let's go ahead and drill into one of these.

10:53And so we can see in package.json, for example.

10:57We can actually see a list of files right here.

10:59And you can collapse them or expand them

11:00so that you can see all the different files.

11:02But what it's showing us right here

11:04is it's showing us that these two

11:05lines were added to this file called package.json.

11:09This gives us a very granular way

11:11to review exactly what changes were

11:13made to this particular file as part of this commit here.

11:16Now, if there were multiple files that

11:18were modified or added as part of this commit,

11:21we would see all of those changes listed down here.

11:24We could review those.

11:25And then we could come back to our conversation area here

11:28and then say, OK, I've reviewed this.

11:30Let's go ahead and just confirm that

11:32merge request or pull request.

11:34And then once that feature has been sucked back

11:36into the main branch, you can then

11:38clean up that branch that was specifically

11:41designated for that new feature by simply choosing

11:43Delete branch right here.

11:45So now, at this point, if we come back into our repository

11:49here and we take a look at the branches in our project,

11:51you can see that that my-new-feature request branch

11:55has now disappeared because we are

11:57completed adding that feature.

11:59We've merged the code back into the main branch here,

12:02which you can see we've got a package.json file here.

12:05And we deleted that branch from the pull request.

12:07And so now, that branch has been cleaned up

12:09keeping our Branches section nice and tidy here.

12:12You can also see right here that the branch is

12:15now down to one branch.

12:16We go over to all branches.

12:18We are now stuck with just our main branch,

12:20instead of that feature request branch that is now defunct

12:24because we're done using it.

12:26All right, so that's how we can do some merge requests

12:29between different branches.

12:30I know it's kind of an advanced topic.

12:32But it's a very common function that you'll

12:34be doing inside of GitHub.

12:36I hope this has been informative for you,

12:38and I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:11Hey, guys, and welcome back.

0:13One of the other features of Git as well as GitHub

0:16is the ability to create tags on your repository.

0:20Now, when we look at the branches section right

0:23here you can see we've only got the main branch right now.

0:26And in the last video, we actually

0:27had that second feature branch.

0:29But we've got this little tab right here next

0:32to Branches called Tags.

0:34So if we click on Tags, you can see that right now there

0:36is nothing in there.

0:38If we go to View All Tags, that actually

0:40takes us to a completely separate screen

0:42here where it says "there aren't any releases."

0:45And we've got this little tag icon

0:47indicating that we're doing something pertaining to tags

0:50on our Git repository.

0:54So Git itself without GitHub is the concept

0:58of being able to tag a commit with a particular version

1:03number.

1:03And this is really useful if you're

1:04creating different releases, maybe you've

1:06got like a 0.1 release, a 0.2 release, 0.3, et cetera,

1:10et cetera, and eventually you work your way

1:12up to like a 1.0 release.

1:13And so you can actually use these tags

1:15to refer to specific historical commits in your history

1:20if you're in your commit history here.

1:22So if you click on Commits, you can see

1:23all these historical commits.

1:25And we can use a tag to point to a particular commit

1:28and give it a label.

1:29You can think of a tag like a label almost

1:32and it allows you to kind of zoom

1:34to a particular point in time.

1:36And you can see the source code for your software

1:39based on the version tag that you associate with it.

1:42Now, a tag doesn't have to be a version number,

1:44you can use whatever you want to for a tag.

1:47You could give it like a name.

1:49If you're naming your different software releases,

1:51then you could call it some funny name

1:53like a platypus or something.

1:55And you don't necessarily have to use version numbers

1:58specifically, but you do just want

2:00to give it some kind of identifier that

2:02allows your team to recognize that release

2:05of a particular piece of software

2:06is like a production release or a dev release

2:10or something like that.

2:11So on the GitHub user interface, so now

2:14if we shift away from talking about Git tags specifically

2:17over to the GitHub user interface,

2:19on the right hand side, you'll see this releases section

2:21in each repository.

2:23So every single repository as releases.

2:26And you don't have to use this feature necessarily

2:28if you don't want to, but it does

2:30allow you to pinpoint points in time where

2:34you are releasing a specific version of your software

2:38package.

2:38And it allows you to include some binaries as well as inline

2:42documentation as well.

2:43And you can associate these releases

2:45with tags in your Git repository.

2:48So when we're looking at tags right up here

2:51in the top-left corner in the branches dropdown right

2:54here you're also going to want to be looking at this releases

2:57section right down here because this

2:59is where you are going to see any released

3:01tags in your repository.

3:04All right, so let's go ahead and say

3:06that we wanted to take our current repository here

3:08and create a new release from it and therefore tag

3:12our repository.

3:13So what we could do is either just come over here

3:15to Tags and say View All Tags.

3:17That's going to take us over to the releases section.

3:19And we can click on Create new release because at the moment,

3:23we don't have any tags in our repository.

3:26That takes us over to the releases tab here.

3:29And if we click on Choose a Tag right here,

3:32you can see that we don't have any tags listed.

3:34So we could choose Create New Tag,

3:37but if you don't type anything in this little text field here,

3:39then it doesn't actually create a tag.

3:41So we can type something here.

3:43So let's say this is version 0.1 of our software.

3:46And you can see that text changes

3:47right here where it's going to create a new tag when we

3:51publish this software release.

3:53So it hasn't actually created the tag yet,

3:55even though it looks like it kind of committed that change

3:56there it doesn't.

3:57It hasn't actually committed that tag to our repository

4:01yet until we actually scroll down and hit Publish Release.

4:04But before we do that, let's talk through some

4:06of the other options here.

4:08So right here we can pick the target for this particular tag.

4:12So we could use the head of the main branch,

4:15so where the main branch currently is at--

4:17I'm going to middle click this here again to open up a new tab

4:20so we don't lose our spot.

4:22But we could basically take this code right here--

4:24the latest commit where the head is on our commit history--

4:28and basically say I want this commit right here

4:34to be the pointer for my tag or I

4:36should say, the entity that's being

4:38pointed to by the tag 0.1.

4:41And so that has a commit ID right over here.

4:44Here's the full commit ID right here.

4:46And so our tag would essentially be

4:48pointing to this particular commit

4:50because that is where the head of the main branch

4:53is currently at.

4:54Now, if you don't want to necessarily use the latest

4:57commit or the head of the main branch as your tagging target,

5:02then you can click on recent commits over here

5:05and GitHub will show you a list of the recent commits

5:08that we were just looking at.

5:09So these commits right here you can see we've got EC042.

5:13Though if we go back and actually look

5:15at our repository-- click on Commits right here--

5:18you can actually see that this commit

5:20history right here along with all these

5:21commit messages corresponds directly

5:24to what we're seeing in this recent commits right here.

5:27So we can also search for these commits.

5:29And then we can just choose one of those commits

5:32as being our target.

5:33So I can choose a specific commit in history

5:36and it doesn't necessarily have to be the latest

5:38commit in the main branch.

5:41So once we've chosen a commit that we want to point to--

5:45I'm just going to choose the latest one here--

5:47you can give the release a title.

5:49And you could say this is a production release 0.1.

5:54And then down here, you have the full markdown capabilities

5:58where you can format the release.

5:59So if you want to use headings or you can use the hash

6:02signs to do an H3 heading or a H2 heading.

6:06We'll say "production release 0.1" and "congrats team

6:13on 0.1 release."

6:15Awesome.

6:16And then you can just preview that right over here.

6:18So you can see this as a heading or H2 heading

6:20and then this is just some random text right down here.

6:22Of course, you can add in other advanced features using

6:24markdown capabilities like links or checkboxes or bullet point

6:28lists and things like that.

6:29But basically we'll just use this as a release right

6:32here or release text.

6:34And then right down here, you can

6:36see that we can actually drag and drop binary files

6:39and attach them to the release.

6:41So if your software deployment process involves

6:44compiling some binaries and you want

6:46to distribute those binaries to your end users,

6:50you can actually just drop those right here

6:52and indicate that those are associated

6:54with a particular software release at this commit here.

6:58Though, you also have this checkbox right down here called

7:01"this is a pre-release."

7:02And this is basically just an indicator,

7:04it's kind of just like a flag to the GitHub platform

7:07that this is a pre-release so it's not ready for production

7:09release yet.

7:10And so this is especially good if you're

7:13publishing open source publicly accessible software

7:16projects just to kind of indicate

7:18to users who may not be intimately

7:20familiar with your software package

7:22that this is not really ready for full production

7:24and that only more advanced users should really

7:27be using that pre-release.

7:29So at this point, if I click on Publish Release,

7:32you can see we've now got this new release.

7:34We've got our release title right up here.

7:36We have this little tag here that, based on that checkbox

7:38that we just checked indicating that this

7:40is a pre-release version, a preview version that's

7:43not ready for production deployment.

7:45It shows us the commit.

7:46And we can actually click on that

7:47commit to go directly to that latest

7:49commit to see what changes were made

7:51for this particular release.

7:53We have our release notes right down here.

7:55This is a really good spot for you

7:56to be very thorough with your release notes

7:59to indicate what new features have been added

8:01to your software or what bugs have

8:03been fixed in your software.

8:05Generally, this is a really good spot to indicate to your users

8:08what those things are specifically.

8:11And then you can see, even though we didn't personally

8:13attach any assets or binaries to our release,

8:17we didn't drag and drop anything into that drop

8:19point on the form, however GitHub has automatically

8:22taken a snapshot of our source code

8:25as both zip formats as well as tar.gz formats.

8:28And it's attached to our release that we can just

8:32download that source code locally onto our local system

8:35and extract that.

8:36And then we can see an exact snapshot of our code

8:39at that point in time.

8:40In case there's any bugs or unexpected behaviors

8:44that we need to debug, we can take a look at that source code

8:47without having to worry about cloning it

8:49from this commit here.

8:50And then right down here we've got a little smiley face emoji.

8:53And if you click on that, you can basically just

8:55react to the release.

8:56You can get people excited about it and say, oh yeah,

8:59this is our first release.

9:00And people can react and click on the different emojis

9:02just to indicate their level of excitement about it.

9:05Now, once we've got this release,

9:07if we go back to the main user interface here

9:10for our repository and click on the branches dropdown

9:14here and then go to tags, we'll check it out,

9:17before we didn't have any tags but because we

9:19went through that release process

9:20it actually created a Git tag for us.

9:23And we can now click on that Git tag

9:26and it'll take us over to our repository

9:29at that particular image, that snapshot.

9:32And you can see right here we've actually got that EC042A9

9:36commit ID-- that commit hash rather--

9:39that indicates to us that is what this tag is pointing to.

9:43So GitHub itself uses this concept of releases

9:48in order to create these tags on your Git repository

9:52itself so that you can release software

9:54based on specific commits and keep track of your tags

9:58through this tagging section right here.

10:00I hope this has been informative for you.

10:01And I'd like to thank you for viewing.

0:11Hey guys, and welcome back.

0:12In the last video, we took a look at releases and tagging

0:16specific commits so that you can link

0:18different versions of your software, different releases

0:21with a particular commit and then release that as a release

0:25over on the GitHub UI here in your repository.

0:28Now, one of the other cool features about GitHub

0:31is the ability to link pull requests and issues together so

0:35that you can streamline your process of resolving

0:39bugs and adding features and things like that.

0:41So bear with me here for a second

0:43as we just go through a mock scenario.

0:45So let's say that there is an issue with our project.

0:47Let's say there's something like a missing file, for example,

0:50or something.

0:51And somebody, some third party user out there,

0:53comes along and opens an issue.

0:55So they go to the issue tracker, they create an issue,

0:58and they say, hey, script2.ps1 is missing.

1:03All right, so we'll submit that issue.

1:05And so now we have our first issue inside of our code

1:08repository here.

1:09So now let's switch back.

1:11So put on a different hat here and say, OK,

1:13I as a software developer, I'm going

1:16to go ahead and take ownership of this issue and fix it.

1:19So of course, one of the first things I'd probably do

1:21is just assign myself as the owner of that particular issue.

1:25And so GitHub will then just update and basically say

1:28that I've assigned myself.

1:29And you can see that right here, pcgeek86 self-assigned.

1:34But now we actually need to implement the fix

1:36for this particular issue.

1:38So the issue ID here is number three.

1:41So just keep that in mind as we're going along right here.

1:44So what we're going to do is come over here into code

1:47and we are going to fix this by let's say,

1:50adding a script called scripts2.ps1.

1:53OK, so we're just going to quickly add a new file here,

1:55and create new file scripts2.ps1 and just

1:58put in some random code, do something a high 100 times.

2:05All right, and so we're going to add this new script

2:07file but in our commit message here,

2:10we are going to add something special.

2:12And I am going to say adding script2

2:16and I'll say fixes number three.

2:20So if I do fixes hashtag three, that's

2:23referring to issue number three in the issue tracker

2:27for this particular repository.

2:29So now I can go ahead and open up a new feature branch here.

2:33So let's call this fix-issue-3, for example.

2:38And we'll say propose new file.

2:41All right, so now we've got to this new branch

2:43that we've created.

2:44And if I just middle-click here and go over to the UI,

2:47you can see that we've got this new branch fix-issue-3.

2:50And that's what we're on right here

2:52for this pull request screen.

2:54So what I want to do is essentially open up a pull

2:56request and say, hey, I need somebody

2:57to peer review this fix.

2:59And I'm going to take this fix-issue-3 branch

3:01and I want to merge it back into main.

3:03So I'll go ahead and say create pull request.

3:07All right, so if we go over to Issues right here,

3:10you can see that this issue is still open.

3:12Nothing has changed in that regard.

3:14Nobody's come in here and commented on it

3:16or closed it or anything like that

3:19or changed the status of it.

3:20The only thing that we did is we opened a new issue,

3:22and we self-assigned ourselves as the developer

3:24who's going to fix this issue.

3:26So if we drill into this issue here,

3:28you can now see that this new entry

3:30has been added to the issue log because we

3:33opened a pull request that references

3:36this particular issue.

3:37So by adding that hashtag 3 into our commit message,

3:40we've now bound it to this particular issue.

3:44And it's now tracked the fact that we've

3:47opened up a new pull request against this particular issue.

3:50So the pull request is still open.

3:52It's still pending.

3:53We haven't actually merged that fixed branch

3:56back into the main branch yet.

3:59But once we do that, look what happens.

4:01I'm going to go back over to my pull requests here,

4:03the pull request itself has an ID of 4.

4:06Let's open up this pull request.

4:07And so I'm going to come in here and basically just kind of peer

4:10review this and say, all right, looks good.

4:12Here's the commit.

4:13Let's take a look at the commit really quick.

4:15All right, it adds script2.ps1.

4:17So that file now exists.

4:19All right, everything looks good.

4:20So I'm going to say merge the pull request.

4:22And we'll do a confirm merge and check it out.

4:26So we've merged just like we did in an earlier video.

4:29And we can clean up that bug fix branch now

4:31that we are done fixing the bug and we no longer need it.

4:34But check out what's happened here.

4:35So if we come back over to Issues, all of a sudden,

4:38that issue disappears.

4:40Now we have zero open issues, and we have one closed issue.

4:44So this is just kind of a workflow enhancement

4:46that GitHub provides in addition to the issue

4:49tracker and the pull request management capabilities.

4:52It's basically said, all right, this issue was automatically

4:56closed because it was referenced in a pull request that has now

5:01been merged into the main feature branch.

5:04So now we can assume that that issue has been safely fixed

5:07and GitHub has automatically closed that

5:09for us saving an extra step in the issue tracking process.

5:13I hope this has been informative for you,

5:15and I'd like to thank you for viewing.