113

GitHub: Getting Started

View non-AMP version at androidpolice.com

Course Overview

Course Overview

Hi everyone. My name is Gill Cleeren, and welcome to my course, GitHub: Getting Started. I'm the CTO of Xpirit Belgium and work on mobile and web projects. GitHub is the world's favorite social coding platform, and it is used by millions of developers around the globe every single day. A lot of developers use GitHub in combination with Git as their source management system, which is, of course, its main goal. But apart from source control, GitHub is so much more and can help you as a developer with the management of your entire project. This course will teach you how to work with Git and GitHub in an efficient way. You'll learn how to work with GitHub repositories, branches, forks, and pull requests, but GitHub offers much more, including project management, wikis to create documentation, and even static page hosting. Some of the major topics that we will cover include learn the basics of Git and its most commonly used commands using the command line interface, get a deep understanding of GitHub repositories, how you can create branches and forks, understand the GitHub flow using pull requests and perform code reviews, see how you can use GitHub within your organization for project management and creating wikis. By the end of this course, you'll have a good understanding of how you can use GitHub for your personal and professional project and how you can get the most use out of the platform. No prior knowledge is expected for this course. I hope that you will join me on this journey to learn how to use GitHub efficiently with the GitHub: Getting Started course, here at Pluralsight.

An Overview of Git and GitHub

Module Introduction

Hello, and welcome to this Pluralsight course, GitHub: Getting Started. GitHub is an amazing tool that powers millions of developers every day to get their work done, share code, and collaborate on projects. I'm Gill Cleeren, and I will be your instructor for this course. In this course, we'll explore the many facets of Git and GitHub. As this is a getting started course, it's aimed at teaching you how to use GitHub efficiently for yourself as an individual developer, for a group or team, or even within your organization. You'll get to understand why so many companies today are switching to GitHub for all their development tasks. By the end of this course, you'll be the next one that is converted to GitHub. Of course, GitHub is all about using Git. That's a given. If you aren't familiar with Git yet, no worries, as in this module I've included just enough information about Git itself to be able to follow along with everything I'm doing in the rest of this course. So, time to get started. Let's see what this first module will contain. We will start with a short overview of the course in terms of what to expect. After that, we'll dive into the core of this model. We'll start by looking at Git and GitHub and the relation between the two. Before we can get our hands dirty with Git and GitHub though, we'll need to perform some installations. In the getting your machine ready topic, I'll show you what you need to have installed to follow along. For those unfamiliar with Git, in the next and final part of this module, I will give you an overview of the base concept of Git. Understanding how Git works is very crucial to become successful with using GitHub, and you'll see soon that, of course, GitHub fully relies on the concepts of Git. We'll learn about the basic commands to use with Git here as well. I hope that all of this already sounds very interesting to you. Let's do this.

What's in This Course for You?

With every Pluralsight course I create, I think it is vital to set the expectations right from the very beginning, so I want to do it here as well. Let's see what is in this course for you and what you will have learned by the end of the course. Git is very popular today. A lot of developers are moving towards Git for their source control needs and even much more than just source control. For a lot of developers, including myself, coming from other tools, the move to GitHub isn't always that easy. You'll need to start thinking differently if you have been using, for example, Team Foundation Server in the past as your source control. That's why understanding the concepts of Git is a key learning aspect that you'll get from this course. Of course, this is not a course on Git. It's, in fact, a course on GetHub. So indeed, starting with the next module, I will start with a hands‑on coverage of GitHub. And like I already mentioned, while doing so, you will grasp the concept of Git even further. Remember, there's no GitHub without Git. By the end of the course, you'll not only have a broad overview of what GitHub offers, you'll have hands‑on experience with using GitHub. Many developers think that GitHub is just source control. It's basically Git, but then online. Well, while source control is, of course, a vital part of it, GitHub offers much more. You'll see project management with GitHub, pull requests, one of the most important parts of the GitHub workflow, issue management, wiki pages, code snippets, and so much more.

Git and GitHub

Now that we have set the expectations right, let's look at what Git and GitHub are and what is their relation. The Git is, in essence, a source control system, a very popular one, as already mentioned, and a very widely adopted one as well. It allows many users to work on small and large software projects in a simplified yet powerful way. Git is a distributed source management system. Source control systems, such as Team Foundation Version Control, are centralized version control systems. In a nutshell, being a distributed system basically means that instead of having a single place for all the sources, every developer also has a full history of all changes. Git was created by Linus Torvalds and is itself, of course, also open source and completely free to use. Using Git as your source management system has quite a few advantages. For starters, it's fast, really fast, and scalable. Performance tests have shown that compared to other source management systems, it's a lot faster. Since it's distributed, you'll often work with the local history, and that is also a lot faster than when working with a remote server. Since Git is a distributed source management system, you can work disconnected. Distributed means, in essence, that every developer has a full local copy of the complete repository. All your work is done in the local repository, and only when you are satisfied with the work you have done, you can synchronize with a remote server. Centralized source management systems can also cause havoc when someone breaks the production branch. With distributed source management systems, everyone can continue working on the local branch. Git is very powerful yet very easy to use. In the beginning, when coming from other source control systems, often developers need to make a paradigm shift. Once you have taken that step, though, and learned the basic commands, you will become a Git master in no time. Using branches is another benefit of Git. In fact, the entire typical workflow in Git is typically based around branching. Development typically is done on a feature branch, and only when the level of quality is what it should be will we be merging back into the master branch. This way, the master branch always contains quality code. Very closely related to this is the concept of pull requests. It's not really a Git feature, but I'm adding it here anyway. Pull requests are typically added on top of the core feature set by sites such as GitHub. It enables collaborating on code. Using a pull request, a developer can ask a review and a merge back into another branch of the changes that he or she has performed. This intrinsically brings discussions and reviews with it, thus improving the quality of the code. Now it's not all perfect in the land of Git. There are certainly some challenges to take when working with Git. For starters, yes, it's different, although that can be a good thing. If you have been working with traditional source management systems for many years, you'll need to make a mind switch. Git has multiple local levels and a remote typically, whereas in traditional, centralized version control systems, we only have a local working copy, and changes are pushed to the remote. And that's basically it. Developers starting with Git also complain sometimes about the learning curve they have to go up when learning to work with Git. As said, some things are different, and sometimes things we know have a different meaning. For example, checking out has a different meaning in Git than it does in other source control systems. Adding to the learning curve is sometimes the available tooling. Git is most powerful when used on the command line. And that isn't always easy for developers coming from other systems where a powerful GUI could help. Note that for Git, several GUI clients also exist, but Git really shines with command line. In this course, we will be using the command line as well. Finally, what area where Git also suffers a bit is large binary files. But then again, other source control systems also have issues with this very often. Now that we know what Git is all about, I want to make sure that you see GitHub in combination with Git. As mentioned, we'll start the exploration of GitHib in the next module. But I only wanted to make things as clear as possible here. GitHub is a Git hosting site. It provides a hosting service for Git repositories, and it's used by many developers for personal projects, as well as numerous companies around the globe for small and large software projects. GitHub runs on top of Git, so it will add many more things. Of course, source management is one of the key concepts here, but Git offers a broad variety of extra services including issues management, working with teams, adding a wiki, and so much more. Some source‑based actions can also be done directly in the GitHub interface, such as creating a pull request or performing a merge. Some others still require the use of local tools. GitHub offers a free tier, as well as paid options. It's possible to create both public and private repositories with the free plan, and that's what we will be using in this course. GitHub is the key learning of this course, so as said, we'll start with the exploration of GitHub with the next module. For the remainder of this module, we'll further explore Git itself so you will be comfortable using GitHub later on.

Getting Your Machine Ready

Now before we start exploring and using it, let's make sure your machine has everything installed for use with Git. Again, although we will be using GitHub, not everything is possible in the interface from GitHub, so we'll need to install some local tools as well. Git is available for everyone. It's widely supported on all operating systems, so no matter if you're using Windows, macOS, or Linux, Git is available for your machine. Since we'll be using the command line for our interactions with GitHub in this course, you'll be able to follow along with everything I'm doing here, no matter what operating system you are using. That's yet another advantage. In terms of what you need and need to install in order to follow along with this course, we can be pretty brief. You'll need to have Git installed locally on your system. Head over to the link shown here on the page, and there you will find the download for your operating system. Next, you'll need an editor since we will be making changes to some files. I'll be using Windows in my demos and as editor, I'll be using Visual Studio Code. Any editor will basically do. Just use your favorite here, and you'll be good to go. Once we start in the next module with GitHub itself, quite logically, you'll need a GitHub account. We'll talk more about that in the next module, so no need to worry about that just yet.

Demo: Setting up Your Environment

In the first demo of this course, let me show you in a bit more detail which steps you need to follow to set up your environment. To get started using Git, head over to the link you see on the screen to download Git for your operating system. I've already done that, and I've installed the version for Windows. For everything that we're doing code‑related in this course, I'm going to be using Visual Studio Code. You can use just any editor, but I'm going to use Visual Studio Code. It's available, again, for every operating system. Head over to code.visualstudio.com and download for your operating system. As mentioned, we are going to use git from the command line. When you have installed Git, it will come with Git Bash. That's the one I'm using in this course. The first thing that we'll do is configure Git locally. Everything that we do related to Git starts by typing git command, so we'll do that first. I want to configure Git, so the command that we'll use is git config. We want to do a global configuration, since setting the username and the email for myself is a global setting, we'll use the global parameter. Note that it's prefixed with two dashes. Then I specify that my username will be Gill Cleeren, and it's pretty obvious that this will be your own name on your machine. Hit Enter, and now Git is configured with Gill Cleeren as the username. I'll repeat pretty much the same command, but now I'll do user email. So using this command, I'm now, again, on a global level, configuring the email that we'll use to work with Git. Now, where is this all stored? Well, these are global settings, and we can actually see the global configuration made on my machine. By typing this command, git config ‑‑edit ‑‑global, we'll actually see the global configuration, including the settings that I've just made. Hit Enter and the default editor will open and show the global configuration file. My default editor is set to Code, which is the reason that it opens Code. And over here, you can see my username and email. Now I've mentioned Git opened Code. Why is it doing that? Well on your machine, if not configured, it won't do that automatically. You will actually have to set some settings first before it will do that. You can, of course, use your own editor, but I'll show you how you can specify your own default editor. If using Windows, the first thing that you need to do is make sure that your editor, in our case Visual Studio code, is set in the path. So go to the System Properties, under Advanced go to Environment Variables. In there, you'll actually see Path. And over here you can see the line that includes Visual Studio Code in the path. With that set, I can now just type here code and it'll automatically open Visual Studio Code. Now I have the global configuration open again, which, as you can see over here, is living under my user directory in a .gitconfig file. Over here, you can see that the editor is Code. Adding Code as a path variable doesn't make it the default editor for Git. You actually have to type another command that will set Code as the default editor for Git. It's, again, a config command that we'll set as the global core editor, Visual Studio Code. And because I've set that as the path variable, it knows what that code in this case means. Also specified ‑‑wait, which will actually make sure that Git Bash will wait for the code editor to be closed down. And I also want it to open a new window all the time. This is actually a useful setting that when you have Code open for something else will actually open a completely new window. Now, by setting this command and then asking Git to show us the global config again, you will see over here that Visual Studio Code has now been set as the default editor for Git in your gitconfig file. And note, by the way, here at the top, the gitconfig file, so the global gitconfig file, is in this directory, in the user directory. And that's where it stores all your settings.

Foundations of Git

With everything installed, we can now take a look at the base concepts of Git. If you are already familiar with how Git works and want to focus purely on GitHub, feel free to skip this section and start with the next module. As mentioned already, one of the main differences when comparing Git to other source control systems is the fact that Git is a distributed source management system. But what is that exactly? Before we take a look at that, let's take a look at how a centralized source management system works. In a centralized source code management system, we have a central copy of the source on the server. Developers working on their machines will make changes to the code, and that will be committed to this central store. Once that is done, other developers can pull down this change, and their files will be updated as well. In a centralized system, we work with change sets. A change set is a number of changes that is to be treated as a whole. In a distributed system, things works slightly different. In such a system, a developer will clone the entire repository and therefore get the entire history on their machine. This way of working therefore doesn't require a central store, although typically there will be one. In our case, that central store will be GitHub. Because each developer has a full copy of the entire repository, including history, we could work offline in this scenario. We can create local branches, and only when we are ready to share the work with others, we can send it back to the central repository, from where it can be distributed again. The process of sending information back to the depository is pushing, and once the new code is available, other developers can pull those changes back to their own machines. Of course pushing and pulling does require to be connected. Most other operations can be done in a disconnected way. Next to being distributed, another very important concept in Git are the three states that files can be in. These three states are committed, modified, and staged. These three states are basically a promotion‑based system. When content matures, it can move up a level. In the committed state, the data is basically stored in the local database. The modified state means that the file has been changed, but it hasn't been committed to the database yet. Finally, staged means that the modified file is marked to be part of the next commit snapshot. Keep in mind though that all these changes are still local. Since files can be in three states, there will also be three areas in which files can live and we will soon add a fourth one as well. The first is the working directory, and that's where content will be created, edited, and deleted. Typically, at least for existing for files, these files will be extracted from the local Git database. The staging directory can be seen as the area where changes from the local directory will be staged before they are committed. Basically, when files are in the staging area, they are waiting to be committed, typically. They will be probably part of the next commit. Once we perform a commit, all changes will be stored in the local Git directory, which is entirely managed by Git itself. It's also created when we clone source from another computer or from GitHub. Although in a distributed source management system it is not required to have a remote, many environments will typically have a central place. That's typically the master. When we have made the local commits to the local repository, we can send this off to the central location. In our case, that will be GitHub. Indeed, GitHub will be the fourth area where a file can be stored. Although we are adding a remote, we will still have all the benefits we had before of a distributed source management system. As mentioned already briefly, we can work with Git and GitHub in several ways. The first and probably the most commonly used approach is using the command line. Using the command line really gives developers access to all commands available in Git. In this course, although we are focusing on using GitHub as part of the workflow, we will need to use a local tool in several locations. That will be the command line, as most developers prefer this approach, even though there is a learning curve involved. Next to the command line, we can use a GUI. Although they are also very powerful, typically they only support part of the available commands. Typical clients that you'll see being used often are GitHub Desktop and SourceTree. In this course, we'll do all the demos using the command line. Let's look at the commonly used commands now. All the directions with Git start with the dollar sign and then git. Just entering the git command really won't do anything, since we'll need to pass more options to Git before it knows what you want to do. Using the git config command allows us to get and set configuration options, both globally as well as for the current repository we're working with. Most of the time we'll be working with repositories. We'll explore in a lot of detail what repositories are. For now, see them as a folder for your project. If we want to create an empty repository, we can use the git init command. The net result of executing this command will be that the .git directory will be created in a specified directory with a number of subdirectories, all internal to Git. The git clone command will do exactly what the name says. It will clone a repository into a local directory on the machine and will also create a remote tracking branch and check out an initial branch. If the concept of branches isn't fully clear right now, don't fear, as we will be exploring that in much more detail later in the course. Another important concept and commonly used command for Git is using git add. Using the add command, we can add a file or multiple files into the staging area. It basically makes Git include these files to the index, making them ready for a commit later on. Options are available on the add command to include only the selected files as well, so that not all files within the directory will get staged. Finally, another vital command is the commit command. Git commit will, as the name implies, commit the changes to the local repository. A new commit is created, and typically a commit message is sent along.

Demo: Getting Started with Git

Now that you already have an idea about the basic Git commands, let's go to another demo, and we will use these commands to do some basic interactions with Git locally. First, we'll create a local repository, and then we'll add and edit some files, and we'll then create a local commit. In this demo. I'm going to show you a couple of basic Git commands, and I'm going to show you a little bit of the flow to work with Git. So I'm going to work in a directory that I still need to create on my D drive. So I'm going to create a new directory with the mkd command, and as the path, I'm going to specify d:\code\pluralsight. And I still need to switch to that directory. That is normal command line stuff. So I'll do a cd to change directory. Notice that bash now knows that we're working in the code\pluralsight directory. Now at this point, this is just a plain directory. It's not a Git folder just yet. So what I'll do is I'll type git init. This will actually initialize Git right in this directory. As you see, Git says that it has created an empty Git repo under my directory called .git. That is my Git database directory. That's where Git keeps all its stuff to keep track of all the things that it needs to do to allow us to work with it. Now, also notice that at this point, we are automatically in the master branch. By default, a new branch, the master branch, was created. Don't worry if the whole concept around branches is a bit unclear. We'll come to that later in this course. Now are there any files already at this point in the directory? It would amaze me a little bit because we haven't done anything yet. Let's take a look. I'll type ls ‑la. And it does seem that there are some files in there. Well, indeed, Git has created that empty Git directory called .git. And remember that Git directory is the place where Git will keep track of everything that it needs to do. Now let's now discover some basic commands to work with Git. A very basic command is the git status command. As the name gives away, this will give us the status about the current repository. At this point, git status will say that we are on the master branch. We already knew that. We haven't made any commits, and there is really nothing to commit, which I can't actually really do. We haven't done anything just yet. Now Git does mention here it has nothing to commit, but you can create some new files. Let's do exactly that. So what I'll do is I'll use Visual Studio Code to create a new file. I hope you will remember from the last demo that you can just type code here, and then I'll type in the file name that I want to edit. I'll call it a readme.md file. MD is markdown format, frequently used in GitHub, and we'll see later in this course. Hit Enter and that will open Visual Studio Code. We don't need to do any editing just yet. Just make sure that you save the file, and you see that Code has saved that file. I can now close Code again. And if I now do another git status, Git is saying that we have one untracked file, the readme file. We have, indeed, added that file, but at this point, it's not being tracked by Git. Only when we add it, it will be tracked by Git. So let's do that next. And for that, we'll used the git add command. For now, I will specify that I want to add that readme file. So I specify my file here. Another git status is now saying that the file is effectively being tracked by Git. The next thing that we'll now do is create a commit. We'll want to store that file in the current state in the Git database. And for that, we'll create a commit. I think you may have guessed that the command is actually called commit. I am going to add a message, a commit message, that is, and let's add here some basic comment between codes. At this point, a new commit with this ID and that commit message here has been created. The commit is basically just one file that we have created, our readme.md file. If we do another git status, Git again says that there is really nothing happening. We are on the master branch, and it can't commit anything. The working directory is clean. We haven't edited or added new files. In a real‑life scenario, I'll typically work with more than one file. So let me create a couple of files, and then I'll show you how you can add all these files in one go. So I've now created three new files using Code. If I want to add all these files in one go, I can say git add. But now I can simply add a dot, and this will then add all the new files that we have created but not added to GitHub. So when we do this command, Git will start tracking this three files. If we want to see what we have been doing in our repository, we can use the git log command. At this point, we have just one commit. That's the one we created earlier. In the git log at this point, you don't see that you have just added these new files because the log will actually show us the history of all commits, and we haven't committed our three new files just yet, so I'll do that next. Let's create another commit. And in this case, I'm going to use the add and the commit in one go. So what I'm going to do is I'm going to use to git commit command again. I'm going to pass in ‑am as the parameter here. This will add newly added or edited files, and it is in one go going to also create a commit with a new message that we pass it. There we go. As you see, a new commit has not been created in which I have inserted three new files. If we do another git log, and I should type git log correctly, and now we see that we have two commits, the latest one being at the top. That's the new files added commit. So by now you should already have an idea of how to work with Git. Again, this is not a course on using Git. We have a lot of other great content on Git on Pluralsight. But this should get you on your way to start using Git in combination with GitHub, which is what we will be doing for the remainder of this course.

Getting Started with GitHub

Module Introduction

Hi there, and welcome to this module in the GitHub: Getting Started course, here on Pluralsight. I'm still Gill, and I will guide you through this module as well. This is a GitHub course, but so far we haven't been doing an awful lot with GitHub just yet. Well, that is about to change with this module. In this module, I'm going to get you started with GitHub. Let's see what we will be covering in this module. We'll start the module with a part I've named Understanding GitHub. As the name implies, I'm going to give you an overview of GitHub, its features, and what you can and cannot do with it. Then we'll take a look at the start of it all, creating a GitHub account. In this module too, we'll look at the different ways you can have your local machine connecting with GitHub, including how it can use SSH to do so. In the final part of this module, we'll spend some time understanding how we can search the vast amount of data that lives on GitHub. Since there's really so much to be found here, GitHub offers some tools that we can use to find what we're after, and we'll learn about that here as well.

Understanding GitHub

I will start at the very beginning. That's always a good plan. In the first part of this module, I'll make sure that you understand in full what GitHub is all about and you'll understand why it is so popular today. As already briefly discussed, GitHub is a web‑based hosting service for Git. It's mostly used by software developers to put their code in. GitHub, therefore, extends basically, on what we can do with Git. GitHub offers the features offered by Git, such as a distributed version control system and source code management. Did I also say that it's popular? Official numbers from August 2019 say that over 40 million developers are using GitHub today and there are more than 100 million total repositories. Let that sink in. That is a lot of code. Next to source management, it offers a lot of extra features that it will discover in this course making it the go‑to place not only for storing code, but also to manage your entire project. GitHub is praised because of its features around the social aspect of coding. While you'll use it often to store your code, it's really built around collaborating on projects. Everyone can get involved very easily and can participate in existing project quickly. We'll see this, for example, when we explore pull requests later in this course, which is one of the fundamental building blocks of GitHub flow, which you'll learn about later as well. And since 2018, GitHub is owned by Microsoft. So what do we get when we use GitHub then? Well, as mentioned, the cornerstone is code. All of the code lives in the repositories. Repositories are a very important concept in GitHub. Another core aspect of GitHub is pull requests. Using pull requests, part of the so‑called GitHub flow, developers can request that their changes are pulled into another branch, typically, this is then combined to the code review, which can be conducted directly from the GitHub's interface. This is very relevant for the social aspect of GitHub as well. Why just anyone can propose changes to existing projects. As said, we'll explore every aspect of pull requests to our discourse in much detail, as it is also a very important concept that get help pats on top of Git. GitHub is much more than code, it's a fully‑fledged project management tool. We can work with issues to register work that needs to be done, such as a bug that need to be fixed. It also contains a project board to manage the work. And GitHub also comes with CI/CD features so it continues build and continues deploying features in a form of GitHub actions. We won't be covering this in this course, though. There are many other features that we will be discovering together in the upcoming modules. As I already briefly mentioned in the previous module, GitHub offers several plans for us to choose from. Of course, there will be changes over time, so I haven't included any pricing information here. You can find that on github.com/pricing. Most importantly, GitHub offers a free account type that offers you a lot out of the box, including an unlimited amount of public and private repositories, a large number of minutes for GitHub actions, issue management, and much more. We'll be using the free account in this course. The pro version, also still aimed at the individual developer, brings more build minutes and an unlimited amount of collaborators on the repository. Next to these, we'll also have options for teams named the team and enterprise accounts. Again, take a look at the link you see here on the slide to learn more.

Demo: A Tour of GitHub

Now that you already understand what GitHub is and its main features, I'm going to take you on a guided tour around GitHub. Of course, all features we touch on here will be explained in much more detail later in the course. So let's take a look at what GitHub has to offer from a bird's‑eye perspective, let's say. When you are logged in to GitHub, and I'll show you how to work with an account in the next demo, you actually arrive, when you browse to github.com, on this very page here. This is like your personal home page, let's say. It contains some recent things that you have been doing, other activity that has happened on your account, like people starting to follow you. You'll also see a list of recent repositories that you've worked with and a list of teams that you may be part of. When you actually click on your profile picture here at the top, you can go to your profile page. Now your profile page is really your personal landing page. It is the page that you put on your LinkedIn and in your email footer. It contains your profile picture and profile information, and of course, it also contains information about your repositories. Because everything in GitHub evolves around repositories, and this page is the living proof of that. You can pin a couple of repositories that you know are popular, and this page also shows the contributions that you've made in the past. Let's click here on Repositories. Here you see a list of my projects, my repositories I have on GitHub. Let's take a look at one of these repositories. I'll open the BethanyPieShopHR repository, which is a repository for another Pluralsight course. The repository page shows everything about that specific repository. The most important aspect is of course, all the code. You can browse the code that lives inside this repository. On the repository landing page, you can also see the history, through the commits of that repository, the branches, and so on. You can also see things like issues, pull requests, but we'll come to those later on. Under settings, again, a lot of settings are available for that specific repository. Now this is not really a popular repository, so it's not really easy to show you everything that you can do. Let's go to another, more popular repository, to say the least. Here we are at the aspnetcore repository. As you can see, there are quite a few commits, a few branches, but again, you can browse all the code that lives inside of this repository. There are a lot of people working and contributing to this project, as you can see from the number of issues, so problems or suggestions that have been made for this repositories. And you can also see that a lot of work is being done in the form of pull requests. We'll talk about pull requests a later on, as they are a very important aspect in the way that you work with GitHub. GitHub also has a number of other interesting things, such as the Explore page. On this page, GitHub will show you a number of repositories it thinks you might be interested in, and it seems to be doing quite a good job. You can also browse GitHub based on topics. Topics are tags, really, and you can actually browse repositories based on the topics they have been labeled with. For example, if I click on the JavaScript topic, I will see interesting repositories labeled with the topic JavaScript.

Demo: Setting up Your GitHub Account

With the guided tour finished, it's time to start working with GitHub yourself. Of course, the first step is setting up that account. In the next demo, we'll do exactly that. We'll also take a look at the options we have to configure our profile. Now to get started with GitHub, I think it's pretty obvious you need to create an account. If you don't have one, head over to github.com and sign up. You have to choose a username and your email and create a password. We showed the profile page in the previous demo. It's the page where you can show all your contributions you've made. On this page, you also can edit your profile. You can see my profile picture and my basic profile information here as well that I can edit directly here. If I want, I can also go to the profile settings. When you click on a thumbnail here and you click on Settings, you can edit many more of the settings, including, again, the picture, the public email, my name, my bio, and so on. We also have a lot of account information that we can manage through these settings pages. I can change my username, and this is not something that I would suggest you do because it will also change the link to your profile page. You can also export information, and from this page, you can also delete your account. Under Security you can change your password and enable or disable two‑factor authentication. You can also view a history of logons or sessions that you've made on GitHub. The Security log is an interesting page that shows all the things you've done in different repositories. For example, here you see that four days ago, I've done quite a few changes, and it also shows the IP address that I've been making these changes from. Now my account is actually a Pro account as you can see here. And you could also see that here on the profile page. Now that you have your account ready, it's time to start using it, and we'll do that in the next demo.

Using SSH

Before we start connecting our machine with GitHub, it's important to ensure that things are happening in a secure way. Let's now look at using SSH, which we will be using starting from the next module. Connecting with GitHub is possible in two ways. We can use HTTPS, and while there is definitely nothing wrong with this approach and it's definitely secure, it might not always be the best approach. Depending on your operating system that you're using, it maybe so that you are prompted several times for your username and password when you are, for example, pushing changes to GitHub. Over time, that will become annoying. In comes SSH, short for Secure Shell. SSH is a protocol that allows for secure communication. Using SSH, we will create an SSH key, which can be linked to your GitHub account. When you then connect from your local machine with GitHub, you won't be prompted every time to enter your credentials. If needed, you can also combine this with a single sign‑on approach if it's been set up for your GitHub access. And don't fear. Using SSH is just as secure as HTTPS. So although you're taking a bit of a short cut, you are not compromising on security.

Demo: Working with SSH

In the next demo, we're going to create SSH keys, and we're going to use these then to connect with GitHub. Throughout the rest of this course, this will be the way we will communicate with GitHub. And to connect with GitHub, we can use HTTPS, but I'm going to use SSH for the remainder of this course. So the next thing that we'll do is creating that SSH key. We'll then add that on GitHub. And so then when we connect with GitHub, it will notice that we are passing in our key, our SSH key, and it will know that we are effectively who we are we're saying we are. It's like a token that will be used to validate the connection. So let's first see if we already have a key available. If you've just installed Git, you probably don't have one. But let's verify just to be sure. I'm currently in the root directory, so that means in the user directory. I can type the following command to check if we already have an SSH key in the typical directory where the are stored. So I'll use the ls command to check for the presence of the .ssh directory. And as we can see, that directory cannot be found. I don't have a key just yet. Now while still in Bash, we can execute the ssh‑keygen command to create a new SSH key. Execute this command, passing in a couple of parameters, accept the defaults to save the file in the proposed directory. You can add a passphrase. You can leave it empty. It basically adds some extra security, but we'll leave it empty for now. And there you go. Now your SSH key has been created as you can see here. And the next thing we need to do is we'll need to add our SSH key to the ssh‑agent. Let's see if it's already running, and indeed the agent is running. We've executed this command to verify that. So as mentioned, we can now add the SSH key using ssh‑add. And we specify the directory where our was created. There we go. Our SSH key is now added to the ssh‑agent. And the next thing we need to do is letting GitHub know about our key. Go to the directory where the key was generated. That's, in my case, under the user directory, the .ssh directory. There's two files in there, one has the extension .pub, which Windows mistakenly thinks is a Microsoft publisher document. Open this with Notepad and then copy the contents of the file. And with the file copied, go back to GitHub, and under your Settings, branch to SSH and GPG keys. In there, you can now add your SSH key, the public point that is. We can give it a title, for example Home Computer, so that you can easily distinguish where this key is used. This allows you also to track back later from where a change was made. Then, paste in the key that you've just copied. Click on Add SSH key, confirm with your password, and now that key is known in GitHub. Now the final thing is checking if the communication is possible between my local machine and GitHub. So I'll go back to Bash and will now type ssh ‑t git@github.com. We'll see a warning here, but you can ignore that warning. Type yes, that you want to continue connecting. And there you go. GitHub now recognizes us as Gill Cleeren, and we have authenticated successfully. From now on, all communication with GitHub will use our SSH key.

Searching GitHub

GitHub is vast and it grows each minute of the day. Such a massive amount of code is also a treasure in terms of knowledge. There is so much to look at really, but how are you going to find in there what you're looking for? In the final section of this module, we're going to do some searching through GitHub using the tools it brings. To make searching the vast amount of data a bit more feasible, GitHub comes with some interesting search tools. Of course, we can launch a search that basically searches throughout everything on GitHub. That will effectively launch a search that's going to search through all the types of information, including source code, issues, wikis, and much more. Since the amount of results can be well, a bit overwhelming and may not even be what you're after, you can also define a scope for your search. If you want to search for something within a repository, simply navigating to that repository limits the search scope to that single repository. Next to that, you can also scope your search so that GitHub will only search in code, wikis, issues, and so on. To give you a visual guidance in creating the correct search query, GitHub comes with an advanced search page. On this page, you will get a long list of options to finetune your search including things such as the created date, indicated how many stars a repo has, in other words, how popular it is, and much more. And filling in some of the fields, as we'll see in the upcoming demo, GitHub will create a search created for you with a specialized search syntax. You can use the same syntax as well when creating a search. Let's take a look at some samples that show you how to search syntax words. Imagine you're searching for dotnet related projects. Of course, there are quite a few of these, so you may want to search only for the popular ones. On GitHub, repositories can receive a star, so when you're being favorited by the user. So we can search for popular dotnet repositories by searching for dotnet and adding that we want the repo where the search result belongs to to have at least 1,000 stars. Alternatively, we can indicate that the repository should have between 10 and 50 stars. Another search query is this one. The word, dotnet, should be in there, but the words, hello world, should not. So basically, we're saying, don't give me those intro demos.

Demo: Searching GitHub

In the last demo of this module, we're going to experiment with searching on GitHub. To do this, we'll use both the advanced search page and the syntax, and we'll explore the search results retrieved by GitHub. From basically anywhere in GitHub, you can search its vast amount of information. Here at the top is the search box that gives you access to all search‑related stuff. And to start a simple search, I can search, for example, for ASP.NET Core. I'm going to, in this case, search all GitHub. Given the amount of information it has searched, that is really quick. You can see here, on the left, where it has searched, and based on what we select, we will see the search results pane on the right update. It found about 9,000 repositories that are related to ASP.NET Core, the actual real ASP.NET Core directory, but also many more, as you can see here. Now we asked it to search everywhere, and it has actually done that. You can also click here on Code, and then you'll find more than 5 million files that contain ASP.NET Core somewhere in them. Again, you see the results over here. And as with all good searches, you can sort in the way you want. Next to repositories and code, it can also search in commits, in issues, in topics, and even in users. Now in this case, I've done a very broad search. Let's actually dive into one repository. And I will select the aspnetcore repository. Now let us, in this repository, navigate to a certain file. Now this is the aspnetcore repository, so that has the MVC framework. And let's in here select under Razor, for example, the Razor page. Now I can actually go back to the root of the repository and search here, and notice now that GitHub suggests that I search in this repository or I can again search all of GitHub. If you search in this repository, we'll see the same results page, but it will now show a scoped search as you can also see at the top in the query. It has actually searched in this repository. We can from here also again search all of GitHub, of course. Now from here, we cannot just search for code. We can actually also search for users. So let me search for myself, which sounds a bit philosophical, but anyway. So I can search all of GitHub for Gill Cleeren, and it will find repositories where my name is in. It will find code, and it will also find users. And there's actually two users, my regular account and another one that I've used for a demo on Pluralsight. Now all of this is just again very straightforward searching. If you want, you can actually use the advanced search, and that gives you the ability to search more fine grained. We can go to the advanced search page from this link. It brings along the query that I've just created, which was just my name. But now I can actually search more specific. So let's again search for aspnetcore. I can, for example, say that I want the repository to have at least 10 stars. I also want it to have between 10 and 1000 forks. And as you can see, I have the ability to add many more search criteria in the advanced search page. Now what GitHub has done based on what I've given it is it has created this search query for me. So, as you see, I'm going to search for aspnetcore for a repository that has at least 10 stars and has between 10 and 1000 forks. And let's add, for example, that you also want to search for C# only. As you can see, it just added another parameter to my search query. Let's launch this search. And as you can see, it has now found just 293 repositories and also less instances of code. And this is how to do the search and the advanced search. You can search all that information on GitHub.

Working with Repositories

Module Introduction

Hi there, and welcome to another module in the GitHub: Getting Started course, here at Pluralsight. My name is Gill Cleeren, and I'm happy that you are joining me in this course to learn about GitHub. In the previous module, we made sure that we have a correctly configured GitHub account, so we can now get started using the most important building block, repositories. That will be the focus of this module. Let's dive in. Before we start exploring repositories, let's take a look at what you will be learning throughout this module. We'll start with a very brief part on how GitHub works with repositories. In the next part, which is mostly demo‑based, we will see the different interactions we can do with repositories, both on GitHub, as well as when connecting from a local machine. You'll see how we can change files remotely, pull changes in, push to GitHub, and much more. Next, we will look at some of the special files that we can include in the repository and which are known to GitHub. In the final part of this module, we will explore the many settings we can use on the GitHub repository, including how we can add contributors to our repository, see how many people have looked at the repository, and much more. By the end of this module, GitHub repositories won't have any secrets left for you. Let's do this.

Understanding Repositories

As mentioned, I want to kick off the module on GitHub repositories in a proper way, so we'll start with a short introduction on what they are really. Repositories are the base building block for GitHub. They can be seen as a folder for your project, and all files that are related to your project will reside in that repository. That includes also the history for your files in that repository. When you want to start using GitHub, you'll need to create a repository. It's possible to create a repository through the GitHub interface and clone that to your local machine using the command‑line interface. Alternatively, you can initiate your work locally and push that to a repository on GitHub. Repositories can be public or private. If a repo is public, it means that it's code, and basically everything surrounding the repo, is publicly available from the GitHub website. Everyone can see the repo, but not everyone can make changes to it directly. Only collaborators can do so, and we'll see that later in this module. In a private repo, only users with access due to repo can see it and interact with it. Every type of account has the ability to create public or private repos on GitHub. You already saw this slide earlier in the course, but I want to repeat it here since you now already have a better understanding of what GitHub will do for you and your projects. When working with Git locally, we had three areas, so the working directory, the staging area, and the local Git repo. The latter is basically Git's internal database that keeps track of the changes. We can work with Git this way, but in most cases, there will be a remote as well. And when using GitHub, that is the remote repository. GitHub will be the place where several users on the team will go to sync changes from the local repositories. Using this remote, it's also possible to share code with artists. Although GitHub works in a distributed way, the remote in this scenario can be compared with the central server in traditional source management systems. What you see here is the repository landing page on GitHub. It shows all files that are included in the project, and it offers many actions that we can do on the repository. We can, from GitHub's interface, create or edit existing files, see the project's READ ME, clone it to our local machine, or work with its settings.

Demo: Working with Repositories

In the first demo of this module, we are going to create a repository through GitHub's interface. Let's take a look. So we'll now get started creating our repository on GitHub. So head over to github.com and go to this landing page where you can create a new repository. And we have to come up with a name. For the purpose of this demo, we'll use the one suggested here by GitHub. I really like it, refactored‑umbrella. You also can give a description here, and you may have to choose if you want to make our repository public or private. Public means that really everyone has access to see your source code, and you can choose who can actually make commits to your code. With a private repo, as it says here, you can choose who can see and commit to this repository. In other words, that code is not readable for everyone. Let us, for now, make this a private repo. Now in this last section, we can also already let GitHub generate some special files, including a README, a gitignore file, and a license. We'll take a look at the README file later on. It's a file that contains some basic information of your repository, and it has a special meaning in GitHub. We can also add a gitignore file. A gitignore file is typically used to let Git on your local machine ignore files such as compiled versions of your code. Since we will be using Visual Studio Code, we will select here VisualStudio. Next, I can also include a license so that other people know how they can use my code. As we can see, there are quite a few licenses built in to GitHub that you can choose to include for your application. And we will take this GNU General Public License 3.0. Now we can create the repository. Now since this is a private repo, anyone trying to access it without permissions won't be able to see it. Indeed, if we browse to the repo from a private window, we can't see it. So let's now explore what information we have on this page about our repository. Our repository is effectively available via the URL that you see here, so GillCleeren/refactored‑umbrella. And GitHub also reminds us that this repo is private. If we look at the different tabs, the first tab, Code, will, of course, show us the code contents of the repository. You can also click here to change the description. So let us change that to the following. I can save that and now, of course, it appears here on the page. And we can see, of course, more information about the code. Currently, there's just one commit. If we click on that, we indeed see that the initial commit was made a couple of minutes ago. This commit, we can click on, and then we see the code that was added in this commit. In fact, what has been added is that gitignore file and that license file that I've selected. On this commit, we can also create a comment. Next you will see that there's currently one branch. We'll talk about branches later on in this course. If we click it, we see that there's indeed currently just one master branch, again created by me a couple of minutes ago. It is currently also the default branch. This is important since that would be the branch that we will be defaulting to. We will also create later on a release in this course, and that will then show here. Next we can see that this repo currently has one contributor and that, of course, will be yours truly. Finally, we also see information about the license of the repo. On the next row, we can now choose to change or add a new branch. We'll do that later on. And from here, we can also create a new pull request That too we'll do in the next module. You can also create directly in GitHub a new file. I'll do that later in this module, but this will then create a new commit since everything is going to be associated with a commit. We can also choose to upload one or more files or find a particular file. This button here allows me to clone my repo, which we'll do in the next demo. I will get access to the link that I'll need to clone the GitHub repo locally. If you want, you can also click here to open this in GitHub Desktop. I won't be using that. We have a specific course for that on Pluralsight. But GitHub Desktop is a separate standalone application that allows me to work with Git in a GUI. Clicking this link will open GitHub Desktop for you directly pointing to this repo. We can also open in Visual Studio or download the zip if you don't want to clone this repo. You can also see here some more information about this repo. The last commit was made by me, and it has this particular ID here. And of course, we also see the code that we then can click. And of course, then we see the contents of that file. Finally, GitHub is warning me that I haven't added a README, which we'll do, like I said, later on. That's a special file that GitHub knows about, and it's warning me that I really should be adding that to make my repo more accessible. Next we also have the Issues tab, which will contain information about bugs and tasks for a repo. We'll see pull requests in the next module. They will be used to merge our code together. Next, we also see here that we can look at projects, which we'll do again later in this course. We'll talk about creating a wiki for the repository, and we'll also take a more in‑depth look at insights, which give us, well, insight in our repo.

Connecting with GitHub Locally

A lot of actions can be done through the GitHub interface directly. However, since GitHub is the remote when working with Git, you will have to perform a lot of interactions with GitHub locally. Let's take a look at how we can do this using what we have learned in the previous module. Let's look at how we can do this. When working with a remote using GitHub, developers will typically use the following flow. Assume to start that you want to start working with a repository which already exists on GitHub. So basically the remote or "standard repository" is already there. To be fully clear, in the full workflow GitHub will be the remote repository or, for short, the remote. It's in fact, nothing more than the central place where the code is stored for everyone to access it. Often we talk also about the upstream repository, which is another name for the remote repository. The first thing that we'll do is a Git clone. This will create a local copy on your machine of the remote repository for you to work with. A clone command will initially also create remote tracking branches for all branches in the cloned repo, and it will check out the default active branch of the remote. Now, we haven't talked about branches just yet, so no worries if you're not completely following the branches aspect here. That will come later. For now. Just remember that the clone will perform a full copy of the remote repo into the local repo, and we can then start working in our own working directory. You're see in the demo that GitHub also has in its interface and easy way to start the clone process. We can now edit files and add new files. The latter we can add to Git so they will be tracked using the git add command. Once we are pleased with the work, we can perform a commit so that our changes are stored in the local repository. Just to be clear, so far we have done just one interaction with GitHub. We have performed the initial clone, which gave us the local copy. All other work so far was local. But now we've made changes to the code and we want to share these with artists. So we'll now need to push these changes back up to GitHub, so the remote. And for this we'll use, well, the push command. Now, of course, when working with multiple people on a project, chances are that artists have made changes while you were working on that feature as well. In that case, your push command may actually result in a conflict, and it's your responsibility to fix these issues. Therefore, it's recommended in most cases that before you perform the push, you'll basically check if other changes have been made. If so, you want to bring in those changes to your local machine and fix things first. We basically have two options here. We can perform a get fetch, that will bring down the changes made in the upstream repository, which you do not have locally just yet. However, it will stop there. No merge will be done just yet. Only when you perform a git merge will your changes be merged. In this case, some things might be performed automatically, while others may require a manual intervention from you. Alternatively, you can also perform a pull. A pull can be seen as a bit of a shortcut where the fetch, as well as the merge which changes in your local repository, will be done in one go. We can basically say that the git pull is the sum of a git fetch and a get merge. After a successful merge, we can then still perform the push back to GitHub, so artists can now see the changes we have made locally.

Demo: Cloning from and Pushing to GitHub

Now that we have talked about the flow of how we can work with GitHub as a remote, it's time to look at a demo where we'll see this in action. We'll start from an already existing repository which you will clone to the local machine. We'll then make some changes to it, and then we want to publish those changes back to GitHub. We'll be using the commands we talked about in the previous slide. So now we are going to start interacting with our GitHub repo from the command line. The first thing that I'll do is I'll go to GitHub and I'll indicate that I want to clone my repo, so again, click here on this Clone or download button, and in here, we see the URL that we use to clone our repo. Click on this Copy button to copy it in the clipboard. We are using the SSH key that we configured earlier. Alternatively, you can also use HTTPS. Now it's time to go back to the Git command line and we'll clone our repo from here. Notice that I'm now in the code/projects folder. This is a different folder than the one we used earlier since we already created a git repo in there. So cloning, we can do it using the git clone command, and then we'll paste in what we copied from GitHub. So we'll want to clone the refactored‑umbrella repository, and there we go, our repo has now been cloned locally. If in this directory we now do an ls, which will list out our content of the directory, we now see that the refactored‑umbrella directory has been created. If you now go into that directory and we do an ls ‑ la, we see the files that were created. Notice also that git now notices that this is indeed a git repository, and we are currently on the master branch. The .git directory contains the git database, that is the internal database for git. The git ignore file, as well as the license file that we let GitHub create were also cloned at this point. If we do again git status, we see that we are indeed on the master branch, and now it is saying that our master branch is up to date with origin/master. Origin is the name to indicate the remote, so GitHub. And indeed, a tracking branch has been set up so our local master branch is in sync with on GitHub, the master branch. There is nothing to commit currently. The working tree is clean, but we'll change that. We are going to add some files here. Now let's go to the directory in Explorer. Here we are now in our refactored‑umbrella folder. I'm going to paste in some files that we'll be working with in this course. You can download them from the downloads of this course as well. The files that I have now added make up a very basic website. If we click on index.html, we'll indeed see a very basic static website with some images and some lorem ipsum text. The site also contains a favorite icon, the Images folder, and some assets, including some CSS and some JavaScript and a custom font. If we now go back to the command line and we do another git status, all of a sudden, our git notices that a lot of files have been added, which are currently not tracked yet, so we'll need to make them track by git and we'll need to add them to a commit, and we already know how we can do that. We can do that in one go by just executing the git add command, and now I specify as parameter, dot, this will then add all the files which are currently not tracked in the working directory. If we now do our git status, you will see that all the files that I've just added are now being tracked by Git and are waiting to be committed. They are, however, not part of a commit yet, so I'll do that next. I'll now execute the git commit command. As before, we'll also pass in a message. At this point, my files are part of a commit locally, but GitHub is not aware of that commit just yet. So at this point, it's still not possible to work with multiple people on my website, so I'll need to push that up to GitHub. For that, we'll use the git push command. What I'm going to do is I'm going to push my local commit up to GitHub, and I'm going to do that by specifying that I want to push to the origin, so GitHub, the remote, and what I'm going to push is the master branch. This seems to have worked. The command line, indeed, specifies that it has pushed to my refactored‑umbrella repository, and it has pushed the master branch locally to the remote master branch so it did a tracking master branch. Let's go back to GitHub. If we now do a refresh here, you will indeed see that a new commit was done, the website files added by Gill Cleeren just a minute ago. You also see the files that I've now pushed up to GitHub. We've now successfully finished our first commit where we've pushed change that we've done locally to GitHub.

Demo: Working with Multiple People on a Repository

Of course, working with a repository is rarely a one‑man show. Typically, we are working with several people on the same code. That means that code will have changed on GitHub, and we need to get these changes in. In this demo, we are going to see how we can do that using fetch and pull. Of course, working with GitHub means that we'll probably be working with multiple people on a repository. And therefore, changes can have happened that we don't have locally just yet. That is what I'm going to simulate in this demo. I'm going to do that by making a small change directly on GitHub, then committing that change, and then we're going to pull that change to the local machine. And while doing that, I'm going to show you that indeed to do the GitHub interface, we can edit files directly or, alternatively, also create new ones. But we'll stick to editing for now. So click here on index.html, and I'm going to edit that file. As we can see here, it has this little pencil here that I can click to edit this file directly in the GitHub editor, and I can even preview the changes here. Now what the change is doesn't really matter. I'm going to make the header a bit more enthusiastic here, so I'll add a couple of exclamation marks. Now every change that I make will be part of a commit. So indeed, even this small change is going to be a new commit on my repository, in fact on the master branch. So here you see at the bottom that I can now add a commit message. Here I can add a longer description, and I can now commit this directly to the master or create a new branch and then make a pull request. We'll look at that in the next module. So now I'll directly commit this to the master branch. And if we go back to the whole page of the code, then indeed we see that our page header commit has been added. Now while we're at it, I'm also going to create a new file here on GitHub by clicking this Create new file here. And that'll be the instructions.txt. In here, I'll paste some text. And I'll do the same thing. I'll create another new commit. And again we'll commit this directly to the master branch. And our new file is now added to the repo. Our local repo is, of course, at this point completely unaware of the changes that I've made on GitHub. We'll need to bring these changes in so that it will be up to date. Now I have a couple of options here as you saw on the slides. We can either use a fetch or the pull command. The fetch will already get in the changes, but it won't be merging them just yet with our repo. That is what happens, however, with a pull. If we do a pull command, then the changes will be merged automatically into the local version. And the merge can go either way. It might happen automatically if there are no conflicting changes. Alternatively, if there's a conflict, we'll need to deal with that first. So let's go back to the command line, and let us do it git status first. The message says that we are up to date with origin/master. However, we made made some changes to origin/master that it's not aware of. I'm going to, at this point, do git fetch so that it will peek at the changes made in the origin, so on GitHub. Now at this point, it peeked at the remote repository and downloaded the changes into the Git database. But they haven't been merged yet into our working directory. If we do a git status again, Git now says that our master branch locally is behind by two commits, and it has also detected that are no conflicts. It can be a fast forward, meaning that these changes can be merged in without having to do a manual merge, so let's do that. And it says that we can use to git pull for that, so I think we'll do that. Git now says what changes have been made. Index has been updated, and the instructions.txt file has been added. At this point, my local repo is again up to date with my remote repo. If we take a look at the index.html, we indeed see that these exclamation marks that we've added remotely are now available locally as well. Now things won't go always as smoothly as this small demo here. For example, we may have made local changes and changes have been done remote in the same time. Let me simulate that next. So let's go back to the index.html, and I'll make another change to it, but now locally. Let's now make the title even more enthusiastic by changing it into Welcome our awesome site! Save this. Now we have a local pending change. The index.html hasn't yet been changed. So I'll now a stage my local change, so I'll do git add, and I'll do a dot to indicate that everything needs to be part of the next commit. And then I'll do another commit by using git commit. And I'll then use the ‑am, passing in a message, change to title. Now we won't be pushing this just yet. I'm going to go back to GitHub and make a change there as well. So let's go here to the instructions and edit that file here on GitHub. There we go. I'll create another commit message, and I'll commit the change. So at this point, we are in a situation that we have remote changes that we don't have locally, and we have local changes that are not known remote. Our two repos are basically out of sync. So now I want to go back to the command line, and we want to push this change up to GitHub. So we'll use again a git push origin master. So we want again to push the changes made on our local master branch to the origin tracking master branch. And now we get an exception. GitHub has rejected our push. It basically says here that the remote contains work that we don't have locally caused by another repo that has pushed changes as well. We have to first do a local merge to integrate these remote changes before we can push again. And we can do again a fetch and then a merge manually. But since we know that we won't have any conflicts, I can simply do a git pull. Automatically, Visual Studio Code is going to open. Now why is this happening? Well, a new merge commit has been created caused by the merge of the remote master branch and our local master branch. We can actually add a new merge message here. I'll save this for now, and we'll close code, and there we go. The changes that I had made locally are now combined with the changes made on GitHub, and that has resulted in a new merge commit being created. If it would have had conflicts, we would have had to merge these first before we can actually commit again. Now our local branch is still ahead of the remote. So we still need to push our local changes, including the merge commit, to GitHub. So I'll do another git push. And this time, the changes have been accepted. And if we now go back to GitHub, do a refresh, we'll see that the merge commit is now the last commit that was made. This should already give you an idea of how you're going to interact with local Git and GitHub remote where changes are made by other contributors to your project.

Adding Special Files

GitHub has a number of known or special files it works within our repository. These files are used to allow you as the repository owner to communicate expectations for your project and also manage how users will contribute to the project. In this part, let's take a look at some of these already. The best known file that we can or, should I say, must add to the repository is to README file. In the README file, you typically put information about the project, such as what it does, how users can help with the project, who owns it, who contributes to it, and so on. It's a file known to GitHub when you put it in the correct location. This includes the root of the repository, the .github folder, or docs folder. What I mean my known file is that when it's available, GitHub will perform a certain action with it. And for the README file, that means that this file will be automatically shown on the landing page of the repository. And when you make changes to it, those will be reflected right there on the landing page. The README file it's typically written in markdown format, also known as md format. On the screenshot here, you can see the result of adding a README file. GitHub noticed the file, and it renders it automatically on the landing page of the repository. Not only the README find is a file known to GitHub. Others exists as well. The LICENSE file, named license or license.md, contains your open source license, allowing aspiring contributors to know what is the applied license for the project. Next, we have the CONTRIBUTING or the CONTRIBUTORS file we just use to contain a list of people or organizations who have contributed to this project. The CHANGELOG contains a list of all major changes between different versions of the project. Another file is the SUPPORT file or support.md, which is a file that exists to inform people about possible ways to get help with the project. A very important file is the CODE_OF_CONDUCT. This file contains guidelines for people on the rules that have to obey when interacting with the project. Finally, the CODEOWNERS file is used to specify which users are responsible for the code in the repository. Note that not all these files are required for each project. In browsing through projects on GitHub, you'll notice that these README files typically have a very common formatting style. That's because they're written in markdown, a very lightweight markup language using just plaintext. It can be converted to HTML pretty easily. Here you see some examples of markdown. By adding a hash or pound sign, we are indicating that this line should be an H1 header. By adding a second hash, that line will be rendered as an H2. Adding some asterisks in front of items renders these as a list. Markdown is pretty simple, but showing you the entire syntax is not the goal of this course. You can find to complete syntax list at the following URL.

Demo: Adding a Readme and Codeowners File

Alright, let us return to GitHub and add a couple of special files. We'll start with the README file, and we'll add the CODEOWNERS file. So we'll start by adding that README file. GitHub has been asking me to do so since I actually created the repo. So click here on the Add a README button. This will automatically add to my repository a file called README.md. As mentioned, that is a very special file to GitHub. If available, GitHub will show contents of this file on the landing page of the repository. In this file, we can actually place some general information, but we can even put things like instructions or sample code in this file. The file is an MD file, so markdown. So we can use the markdown syntax in here to style its contents. I'm going to paste in some sample markdown code. The first line is going to be an H1. There's some text at the end of the line here that is going to be formatted as an H1. This line, because of the two hashtags in front of it, will become an H2. And finally, this one will become an H3 because of the three signs in front of it. The dashes then will create in markdown a list. If we click on Preview, we indeed see that our README file looks quite nice already. We can then create another commit. And again, we'll commit for now to the master branch. When we now go back to the landing page of our repository, we indeed see that GitHub will read out that README.md file and show its contents on the landing page of that repo. Now while the README file is probably the most commonly used special file for GibHub, there are quite a few others. Now the second one I'll show you here is the CODEOWNERS file. Let's create another file here and call that file CODEOWNERS. And the CODEOWNERS file will be used to request a review from the people mentioned in this file when someone makes a pull request that modifies their code. The CODEOWNERS file will typically be placed again in the root of the application, but can also be placed in the docs folder or in the .github directory. Now when we add this line here, so asterisk and then the name of the user, this user will be requested to do a review when someone opens a pull request. There's a lot of other possibilities here. We can also do this, for example, only for specific files types, but we'll leave it at this for now. Let's add this file to our repo again through a new commit. And now you've seen how you can add special files to your GitHub repo.

Administering Your Repository

Now that you have seen how we can work with the repository hosted on GitHub, let's explore some of the many other features which are offered on repositories by GitHub. I have already mentioned a couple of times that the repository is the foundational building block on GitHub. Everything basically revolves around repositories. You have not seen how we can work with them, but GitHub offers many extra features that allow us to work with them even better. We can assign topics to a repository. Now you can think of a topic as a tact, which is used to classify your project that can be assigned by you onto your repository. Once you have applied one or more topics, those can help your project to be more easily discovered when someone is performing a search. Also, by clicking on a topic, other repositories with similar topics will be shown. From the settings of a repository, we can also work with projects. As the name implies, we typically use a project or project board to track progress. We'll explore this later in the course. On a repository, we can also see and manage issues. Issues are a way to track all things, such as bugs, to‑dos, feature requests, and more. We'll spend a whole module later exploring issues in much more detail. Another important concept that is linked to a repository is the concept of a pull request. We've already talked briefly about these and you will be exploring them in much more detail in the next module. Using pull requests, GitHub makes it easy to collaborate on code allowing people to suggest changes and allowing repository owners to review these proposed changes. Also in repositories, GitHub offers the ability to use so‑called insights. As the name gives away, this gives you a lot of information about your project including the traffic to your repository page. Finally, using the settings of a repository, we can add several other settings about your repository, including the collaborators, the default branch, and more.

Demo: Working with the Repository Settings

Instead of talking about these repository features and its settings, let's go straight back to GitHub and take a look at these in the next demo. We'll also manage the topics for a repository so that it is now categorized. Now it's been looking at us for the entire time so far. This Manage topics button is really begging us to add some topics to our repo to categorize it. When I click on it, a text box will appear and I can start typing some topics. This repo will, for example, contain HTML. And GitHub is already suggesting us some possible topics that it knows about, so I'll take html, we'll take css, and we'll also take jquery. When we click on Done, our repo is now associated with these topics, and we can actually click on these topics to search for other repositories that are associated with HTML, and there are quite a few as you can see, including the very mighty Bootstrap, Electron, and so on. So the breaks are really a way to categorize your repo and let users find your repo more easily when they're browsing GitHub for a certain topic. Now the repo has quite a few other things that we also still need to explore in more detail, for example, the Issues tab here. Now issues is really the issue tracker of a git repo, it can be used to track bugs, feature requests, tasks, and so on. Who can add a new issue is depending on the settings of the repo. And like I said, we'll explore it in much more detail later on, but let's just for the fun of it, create a new issue here and let's specify a title, and of course, we can also add some more information here. This is, again, markdown format. And we submit the issue. Since it's an open issue, it will appear in the list of issues here on the repo level. Now we'll look at pull requests in much detail in the next module. Pull requests are a way to merge changes made on a different branch into another branch, for example, the master branch. When we click on Projects, we go to this Project Boards screen. The project boards projects in GitHub allow us to organize issues that we've just created in the other tab. We'll look at this later in this course in more detail, but let's take a look at it already quickly here. Click on Create a project and I'll give my board a name. I'll call it Sample board. I can give it a description, and I can also select a template, so a preconfigured board template. Now let's use the Basic kanban board. This will bring in a couple of columns, such as To do, In progress, and Done. Here on the right, you see the issues currently open, so my issue is currently open and I can set that now on the board under To do. When someone now has picked up this issue and they're working on it, they can bring that to the In progress lane. With this, you already have more understanding of all the features that are associated with a repository.

Bringing in More Users

You hopefully already have understood that GitHub is a social coding platform. On the repository, we can work with many to achieve a goal. In GitHub, we can distinguish two groups when working on a project. First, collaborators. Collaborators are a fixed group of people, so the core development team working on a project. They typically have more permissions on the repository. The most important one here is commit access in the main repository. In other words, you, as the project owner, will trust one or more people to be able to change the code in the main repository of the project. This is indeed a curated group of people that can be managed through the repository settings. Next, we have contributors. This can be basically everyone from outside the core team, so a team of collaborators. A contributor is someone who perhaps uses your project in his or her daily work and is proposing a change or improvement. The big difference is, of course, that contributors, so basically everyone, has low permissions. They cannot commit to your main branch. The proposed changes will come in as a pull request, which can then be reviewed.

Demo: Bringing in More Users

In the next demo, let's take a look at how we can add a collaborator to the core team of the project. Now, since I am the owner of the fantastic refactored‑umbrella repository, I can also control who has access, commit access that is, to this repository. To manage that, I can go to the Settings and then go to the Collaborators. At this point, it says there are no other collaborators. We can search for one and add them here. I have another account called gillcleerendemo that I'll bring in as a collaborator. Gillcleerendemo has currently no permissions to the refactored‑umbrella repository. Too bad, but let's change that. So I'll search here for gillcleerendemo and add him as a collaborator. GitHub now says that it's waiting for the response. Let me copy the invite link and go back to the other browser, my gillcleerendemo is logged in. Using this link, I can now accept the invitation to become an owner of the refactored‑umbrella repository. Now it is in place, this second user account now has push access to the refactored‑umbrella repository and can do exactly what we've done with my main account so far.

Demo: Repository Insights

In the final section of this module, I want to highlight another interesting feature, and it's part of the repository settings, and it is insights. As mentioned before, insights gives you inside information in your project. Using insights, you can get information about contributors to your project, basically showing you who was the most important contributor. This can perhaps help you in deciding if they can become part of the core project of a team, so becoming a collaborator. Commits, quite logically, gives us an overview of the commits made to the repo. Using traffic, we can see information as number of clones or visits to the repository. Other graphs, such as the code frequency, give us other insights into the activity of a project. In the final demo of this module, we will take a look at the inside information of a repository. Under Insights, we can see a lot of information about the activity of the repository. When we click on Insights here, we'll be taken to this Pulse page, which, as the name implies, gives you an overview, let's say a dashboard view, of the repository. Now our repository does not have that much activity just yet. You never know, it might change in the future. But anyway, we can already see here that we have one active issue. We can see the contributors. That will be very simple. That's only going to be me. We can look at the traffic. We can also see the commits that have been made. Quite a few have been made lately, as you can see here, 8 so far today. And other graphs are available here as well. Now like I said, it's not very useful to look at this in a very quiet repository like this one. If you, for example, take a look at the pulse for the dotnet/core repository, you see a lot more information. Now not every part is available if you're not the owner of the repository, or at least a collaborator. But here you see that pulse for the dotnet/core‑sdk. At a glance, you can already see that this has much more activity. You can see that are active pull requests, as well as issues. You can see the list of contributors, you can see the commits that have been made, and quite a few more have been made to this repo than to our repo. And some other graphs, again, are available here as well. So through the insights, we can get information about the status of the repository.

Collaborating Using the GitHub Flow

Module Introduction

Hi there. It's great that you are joining me for another module in that GitHub: Getting Started course here, on Pluralsight. My name is Gill Cleeren, and I'll be your instructor for this module as well. In the last module, we had a lot of fun exploring the many facets of repositories, one of if not the most important aspect of GitHub. While we have covered a lot of ground, there are still quite a few things that we haven't covered. So in this module, we'll extend the knowledge of the previous module, and we'll be learning about how we can work with branches in the repositories and use the very important concept of pull requests. Let's take a look at the agenda for this module. We'll start this module by taking a look at how Git works with branches. If you are coming from a traditional source code management system, you may be thinking of branches in a different way than Git and therefore GitHub. So it's definitely worth taking a look at how this is handled in Git. Next, I will explain you what is known as the GitHub flow, which is a typical way of working with GitHub. While we learn about this, we'll learn about pull requests and how they work with GitHub. Finally, still in this area, we'll learn about forks and what is the difference between branches and forks. Excited? Alright. This module contains some very foundational concepts that you'll use all the time when working with GitHub. So it's important that you grasp these in full. Let's do this together.

Working with Branches

As mentioned, we need to start our exploration of branches with an overview of what branches are in Git and therefore also in GitHub. The concept of branching is certainly nothing new, and it's also not something that is unique to Git. Other traditional version control systems also offer the ability to create a branch. If you aren't familiar with the concept, well, it's really nothing complex. Basically, instead of writing all the code on one line and continue to build on that, we, at some point, diverge from the main development line. See it as a train track that goes on and on and on. And at some point, a side track rises. On that side track, we can do all kinds of things with the code without impacting the main line of code, so the main track. If we like what we have done in the side track though, we can at some point, just like train tracks again, converge them. The changes we have made in this side track are then merged with what we have in the main development track. Branching is available in other source management systems as well. However, in traditional ones, it's often an expensive operation. It typically requires that we create a copy of the source code directory and work on that one. If the directory is launched, this will take time. The concept of branching in Git is different though. It's done in a completely different way, making it much more lightweight. Hence, the creation of a branch is really fast. In Git and as also in GitHub, it's really recommended that you work with several branches in your application development. Creating branches, switching between branches, and merging branches is all really fast and therefore is the recommended way of working. Initially, Git was created to support large and widespread themes, working on things, such as the Linux kernel. If everyone would be working on the same branch, that would be really hard. Even with branch support in traditional source code systems, that scenario would be hard since a lot of copying would occur to work with branches. As said, in Git, it's much faster. And it works, in fact, because of the way that Git works internally, Git doesn't work with differences. Instead, it works with snapshots, and those are basically the enabler for the lightweight branching and merging system. Let's take a look at those snapshots in a bit more detail as we haven't covered them so far in this course. So in a traditional system, we are checking in information. That information is stored as a list of file‑based changes. Basically, all information is stored as files, and the change is made to these files over time. The deltas to these files are stored, which is what a change set consists of. That's what you see here on this slide. We have a couple of files, and, over time, changes are made to these files. And these changes are stored as deltas. As said, Git, and therefore also GitHub, work in a different way. In Git, we work with a series of snapshots. When we perform a commit, a snapshot of all files is made and a reference to the way that all files look at that point is created. Of course, that should sound an alarm since now you may be thinking, well, then it will be creating a copy of each file with every commit Well, it does not do that. If a file was not changed, Git will just store a link to the previous identical file. This fundamentally different way of working is one of the main differences between Git and other source code management systems. Now that you understand the concept of a snapshot, let's try to go back to branching because that's what we were talking about. Every time we create a commit, Git will store a pointer to one of these snapshots. The commit object of which that pointer is part will also contain things such as your email and the commit message. Also, the commit will contain a pointer to the commit that came before it. It's possible that there is no earlier commit if this was the first one, of course. In Git, a branch is, in fact, nothing more than a pointer to one of these commits. We'll always have a master branch, that's a default in Git, and it gets created automatically. When we now perform commits on that branch, the master branch, so a pointer, will point to the last commit we made, and it moves forward with every commit we create. So that's why creating branches in Git in such a cheap operation. A branch is nothing more than a pointer to a commit. When using Git, branches are being used for almost all development. We typically create a new feature on a specific branch. When a bug needs to be fixed, we will typically create a new branch. If you want to experiment, same thing. We create a new branch. What now happens when we want to create a new branch? As said, a branch is nothing more than a pointer, so a new pointer is created. By default, we work on the master branch, and creating a branch doesn't change this. Git keeps track of using this using GitAhead, which is a special pointer used to keep track on which branch we currently are. Only when we now perform a so‑called checkout will will be changing to the new branch. Once we are on that new branch and we start making changes, we're building these on top of the newly created branch. The original master branch has not changed. At this point, with no changes to the master, when we are happy with the changes that you made in the new branch, we can easily merge these back into the master branch since it hasn't changed. However, if in the meantime the master branch did change, we will have to perform a merge.

Demo: Creating a Branch on GitHub

Creating branches is something that we can do locally, of course, but also on GitHub. In the first demo of this module, let's start by looking at how we can create branches on GitHub itself. And we'll use this branch later on again. Now the typical GitHub flow, which we will explore more later in this module, is based on working with branches. At this point, we've been working with a branch without really knowing, and it is the master branch. And it's currently also the only branch we have in our repo. Now we're on GitHub. We can click here on this button/dropdown here. And when we click on it, you'll see indeed that we currently have one branch, the master branch, which is the default. Now through this intelligent textbox, we can search for branches, but we can also create a new one. So let's do that now. Let's make a new branch called sample‑branch. Because these branch does not exist, GitHub indicates that it can create it. So let's do that. We saw in the slides that creating branches in GitHub is a very lightweight operation. GitHub has now created that new branch. It also says that this new branch is currently still even/equal, that is, with master. We could do a pull request to bring up changes that we've made in this branch. None at this point. Back into master. We'll talk about pull requests very soon. We can also compare branches with one another. Now branches are, of course, all about making changes in files that are not going to influence files in another branch. So let us, for example, go back to the instructions while we are in the sample branch. And let's make a change in this file. Let me edit this file here and add an extra line here. When we now scroll down, GitHub suggests that we made this directly on the sample branch since that is currently the active branch. We'll commit the changes. There we go. And now when we look back at the repository, we see a couple of changes. GitHub is now suggesting that we can do a pull request. We can now bring the changes made in our sample branch back into, for example, the master branch. We'll talk about that in the next demos. It also indicates that this branch is one commit ahead of master because indeed we have done one commit on this branch that we don't have on master yet. If we look at the instructions.txt, we indeed see that that troubleshooting line that I've added is there. Changes made on this file or any other file within this branch now are currently only available within this branch. If we switch here to the master branch, you'll see that those changes are not there yet. Most of the time, of course, we will bring those changes back to the master, for example. And for that, we'll work with pull requests.

Demo: Creating a Branch Locally

The previous demo was pretty short in that we just created a branch on GitHub, and you also saw that we did some changes directly on GitHub. Although that is possible, it's definitely not the way that you'll be interacting with GitHub most of the time. You'll typically be working locally, pushing your changes, including branches up to GitHub. If you're working on your local machine, commands exist specifically to work with branches. You probably won't be amazed that this command is called git branch and then the name of the branch you want to create. If you have a local branch you want to start working with, you will need to switch to that branch. That is what the checkout command will do. You will specify which branch you want to check out. At that point, the files in your working directory are replaced with the ones in that branch. Another command that is very relevant in this context is, again, the push command. You've already seen the push command in a previous module. Well, we use it here again. When we create a new branch, of course, that branch is not pushed automatically up to GitHub. Only when we use the push command, passing in the u parameter to specify the origin and name of the branch we want to push, will it be pushed up to GitHub. Now that you know the relevant commands, let's go back to a larger demo where you'll see this flow. We'll create a local branch, and then we'll push it up to GitHub. Now while we can definitely use GitHub itself to create branches, very commonly you will create new branches from our local machine, so from our local development environment. That can be to your IDs or Visual Studio, Visual Studio Code or also, again, from the command line. And that's what I'll be showing you here in this demo. We are still in our local repository, and we're currently on the master branch. If I do a git status, we can see that the master branch is up to date with the origin/master. Let us now go ahead and create a new branch. Like I said in the slides, we have basically two options to do so. We can use the branch command to create a new branch. Using the branch command, we will just create a new branch, but typically we then also need to switch to that branch, and that we can do using the checkout command. In fact, we can use the checkout command to switch to a branch, and if that branch does not exist, it will automatically also be created for us. So that's what I'll do. It's a bit of a short cut. Let's use the checkout command, and then we'll specify that you want to switch to the branch that still needs to be created called add‑more‑instructions. Automatically, that branch was now created, and you see that that has now become the active branch. We're now working with that branch, so I can now call Visual Studio Code again and ask it to bring up the instructions.txt file. That contains our code for the instructions file. Let us add some more changes here. So I've now added some local changes here. If you're wondering why we didn't see the changes that we made on GitHub, that was on a different branch, of course. So now we're working on our new local branch. Let's save this and close Visual Studio Code. If we now look at status, we see that in this new branch, instructions.txt was modified. So we now create a new commit to commit these changes into our new local branch. So I do git commit, and we'll use the shorthand again, so ‑am, and I'll pass in the message instructions changed. That has now created, locally, a new commit on my new branch. Now GitHub is, at this point, totally unaware of the work, let alone that new branch that we have created. And we can now do another push to do two things in one go. I'll push up the new branch, as well as my commit in that new branch. I'll use the git push again, but now I also need to specify that I want to push to the origin, my new branch. So I need to pass in the name of the tracking branch for my new local branch, and that's going to be, let's use the same name, add‑more‑instructions. From the comment, we can now see that Git has pushed to the refactored‑umbrella repository, the add‑more‑instructions branch. The local one has been pushed and has now been set up as the tracking remote branch on the origin, so on GitHub. Let's go back to GitHub to see the result. We now see here that a new branch, add‑more‑instructions, was created. Here, we also see that new branch. GitHub is now suggesting, again, that we should perhaps do a compare and then do a pull request, perhaps back into the master. So our new local branch, including the changes and commits that we've made locally, has been pushed up to the remote, and that is GitHub.

Using the GitHub Flow

Now that you understand the concept of branches, let's drill further into this topic and learn about pull requests. This is a very typical flow for working with GitHub, and it's often referred to as the GitHub flow. So far, what we have seen is basically how we can work with branches on GitHub and the flow where we as developers can push that branch up to GitHub. But then what? At some point, we'll come to a point where we want to integrate the changes that we have made into another branch, perhaps the master branch. What we're then going to be doing is creating a pull request. Using a pull request, or a PR for short, we are basically telling others about the fact that we have made changes on a separate branch, and when we open the pull request, we are announcing those changes, and we're opening it up for discussion. Others, such as collaborators, can now review the changes that we have made. And it's even possible that other commits are added to the same pull request. After things are basically approved, they can then be merged into another branch of the branch that you have created. To support this, GitHub contains a number of screens that will help you greatly in the creation of a pull request. Also, GitHub contains an interface to allow, for example, the collaborator to review the pull request, annotate it, and more. Here you see the interface that you'll get to work with when you are creating a pull request. You can enter an overview of the changes, labels, milestones, and so on. We'll learn about the latter later in the course. This way of working is a typical way of interacting with GitHub. It is called the GitHub flow. Let's take a moment to look at this flow in a schema. We'll start with a branch. That's the main line of development. In our example, this is the master branch, but in many projects, this would be the development branch. We're now asked to create a new feature, fix a bug, or maybe we just want to test something out, so we'll create a new branch from that initial branch. Remember, when we create this branch, we do not have any impact on the master branch. Only when we explicitly ask to bring those changes back into the master branch will there be any impact. Okay, so now we have our branch, and we're coding in our favorite editor on the local machine, that is, of course. Since we're working with Git locally, we can now add multiple commits. All of this happens in our local feature branch. At some point, we'll want to get some feedback on the work. This can be very early, even with a limited amount of code. Maybe they want someone to do a review on our code or even the idea that we have. Or it can be at a point that we think the feature that we had to work on is ready. So we're opening a pull request. With the pull request open, others can now participate in the discussion about the proposed changes. They can suggest improvements, indicate that something is missing, and so on. You can still at this point add to the pull request and add additional commits. Hopefully, at some point, your work will be ready to make the big jump, and it can be merged back into the master branch. And then you can also delete your other branch.

Demo: Working with Pull Requests

I think it's pretty obvious we need to see all this in a demo. In the next demo, we'll make some changes, and when we are happy with the changes, we'll open a pull request. In our GitHub repo, we can now see that we have multiple branches currently active. By clicking on Branches, we see that we have a couple of branches, the add‑more‑instructions and the sample‑branch, which are created. From this page, we can directly launch a pull request to merge the changes made in a specific branch back into the master. We can always pick a pull request by going to the Pull requests page as well. And from here, I can launch a pull request. Let's do that now. I'm going to create a pull request to bring the changes made in the add‑more‑instructions branch back into the master. As you can see, GitHub has already detected that the changes can be merged even automatically, so there won't be any conflict. It has already detected that. We'll see later in this course what we need to do if there are effectively conflicts. Before we create a pull request, let's first take a look at what changes are in there. Well, it's actually a very simple pull request. There's currently only one commit that we have done, that is the instructions changed commit. We see that one file was involved, and there's also one contributor. The one file that was changed is shown here. If multiple files are involved, you'll see all the files that have been changed. We can also compare the changes by clicking here on the Split view, and we can see a line‑by‑line comparison of the changes that have been made. I think we're ready to create the pull request. Let's create it now. The pull request will require some comment because typically this will be done by a team member which wants to merge changes back into another branch. And through a comment, a team member can give more information about the changes he or she wants to merge using this pull request. In this case, instructions changed was taken from the commit that we have made. There's also more information here on the right about the reviewers and the labels. We'll come to that later on. And let's now create the pull request. Now we go to this pull request review page, which is, by the way, also accessible by clicking here on Pull requests. Because this pull request is now the active pull request, you can come back to this page by clicking on the pull request where we see all the information about that pull request. Now as the reviewer of this pull request, so basically the person that is going to check if the changes proposed in this pull request to be merged with the master, we can also look at the changes that were made as part of this pull request. One pull request can typically contain multiple commits. We just have one for the demo. But we can go here to the commits page and see all the changes that were made, all the commits, let's say, that were part of this pull request. And, again, we also see the file's path of this pull request, again, in split view, to see changes made in here. Now since we are doing a review as the reviewer of the pull request, I can start the review by, for example, adding a comment here. If I click on the plus sign, as you saw me doing, I can then start a review by tapping a comment here. By adding a comment, I can then start the review process, and this can, for example, bounce the pull request back to the committer so that he or she can make the necessary changes. We'll do that in just a second. Let's go back to the conversation view. As you saw before, GitHub has detected that there are no conflicting changes, so it can automatically merge the pull request. We'll do that here. Now I can then can confirm the merge. I could also close the pull request even without merging. Let us now accept the changes part of this pull request. GitHub says that the pull request has now successfully been merged and also been closed. Since we are not going to be working on this branch any longer, we can delete it here. Now I'll go back to the pull request. There are currently no more open pull requests at this point. If the repo is public, basically everyone can create a pull request, but only contributors of the repo can review pull requests and optionally allow them to be merged with the master branch.

Demo: Reviewing Pull Requests

Another person can review a pull request. The pull request itself can also be attributed. We can add comments and refer to specific lines of code in the change we have made. Let's see this in action in the next demo. I've gone ahead and already created a small other branch to show you something else in the second part of this demo, namely, that we can also do the review of the changes directly from GitHub. I've created the installation file added branch, and I'm going to create another pull request from that. Now go ahead and click the Compare and pull request button here, and then you'll also see the changes that I've made. Again, this won't be a conflicting change, but notice I now have two changes as part of this commit? I've created the installation.txt file and I've removed only part of the content inside of the instruction.txt. Let's assume I'm happy with this and I'm going to create a pull request. At this point, a pull request is pending. Let me switch screens here for a second. Now assume that the other users on the GillCleeren demo account is going to review this pull request. We'll click on Pull Requests, we check our account, and we see that pull request, which is now opened by my regular account, I click on it, and now as the second account, I'm going to review. I'm not going to automatically click here on Merge pull request. I'd rather make a review. So let's take a look at the comments. Now as you're going to take a look at this file here and we're going to notice, hey, this has not being done very well. The submitter of the pull request should actually clean this up entirely. So I'm going to start the review process here, and click on the plus sign here in front of the line, and add a comment. And now, by clicking Start a review button, a review process will initiate. If you're happy with the review, we can click on the Finish your review button, and instead of just submitting the pull request, I'm going to send it back to the submitter to request the changes that I've made. So I'm going to click here on Request changes and then submit my review. And this review is now going to end up in the inbox let's say of my submitter, so let's jump back to the original account. In the pull request here, we can now see that a change is requested. In here, I'm going to see the comment that the GillCleeren demo account has added, this needs to be cleaned up properly. So as the submitter of the pull request, I'm going to do this so that my changes can then be matched. We'll now do this using Visual Studio code on the local machine. So we're going to jump to the git command line again. Now the changes I have done were actually done on GitHub itself. If I do a git branch command at this point, ‑r to see all the local branches, I'm not going to see that remote branch just yet, I need to bring that in. So I'll do a git fetch. Using the git fetch, I can now see the remote new branch, that is the installation file added. A local tracking branch installation file added was created for me, so I can now simply jump to that branch using git checkout again, and then I specify the name of the branch, so installation file added. That is now the active branch. Next, I'm going to use Visual Studio Code and change the instruction.txt, and that still contains the line that we were asked to clean up in the review. So let's remove that, save the file, and close it again. I'll now create another commit using the git commit command again, and I'll use a shorthand version, ‑am passing in a commit message. The commit was added, let's now do a git push. So what I have now done is I fixed my instructions.txt file locally, and I've pushed it up back to GitHub. That is now still part of that same commit, and those also will be added automatically to the pending pull request. If we now take a look again at the pull request using our reviewer account, we indeed see that tree commits are not part of this. GitHub now says that new changes are added since I've last viewed this. This allows me now to review the changes made by the user. This now seems okay for me, so I can now approve this, submit the review. GitHub now says that all pending reviews were solved, and I can now merge the pull request like we've done before.

Merging with Conflicts

Having no conflict when performing a merge can happen, but definitely won't always be the case, that's for sure. Now, do not panic, as GitHub has tools to make the merge process, basically where a manual intervention will be required, an easy one. Merge conflicts can and will happen. If you have made a change on a line of code that someone else has made a change on as well, this will cause a merge conflict. Git won't know what to do there. Similarly, if you make a change on a certain file and commit that while someone else has already in another commit deleted that file, that too will cause a merge conflict. Before we can perform the merge, all conflicts need to be resolved. Now, performing the actual merge can be done inside GitHub. GitHub comes with an interface, as you can see here, allowing us to make changes and resolve the conflict. It is definitely also possible that the change you have made locally will cause conflict with another already pushed commit. In that case, you'll have to perform the merge locally. Doing this can be done using a diff tool. Quite a few of these exist, including KDiff3, vimdiff3, P4Merge, and Beyond Compare.

Demo: Merging with Conflicts

In the next demo, we'll perform a merge where we have to resolve a conflict. We will do this using the GitHub interface as well as locally. Being able to merge without merge conflicts is the ideal case, but that definitely won't always happen. In an active project, you'll definitely encounter merge conflicts. I'm going to show you how we can solve them both directly in GitHub as well as locally. So let's start by looking at how I can do this directly on GitHub. Now I have a new branch here called index‑changes that I have branched off of master. In index‑changes, what I've done is, I've actually made a change to the index.html, and I've changed this line here, so the Header. Now after I branched off index‑changes, I also made a change on the master branch. I've changed index.html there as well. On the same line I've removed the exclamation marks we had here earlier. So in fact, when I now want to do a pull request and a merge, I will have conflicting changes because I have changes in the two branches on the same line. Let's try it. I'm going to do a pull request where I'm going to bring in the changes made in index‑changes back into master. So I click here to create a new pull request, and automatically GitHub has noticed that there will be a merge conflict. But it says here that we shouldn't be worried. And if we scroll down, we indeed see that we have changes in both branches on the same line. That won't allow us to do an automatic merge, but we'll go ahead and create a pull request. Again GitHub says this cannot be merged automatically, but GitHub says that we can use both the web editor or the command line to resolve it. Now let me first show you how I can do this directly in GitHub. I click on Resolve conflicts here, and I can now make the changes. We can now see here that GitHub has added for this conflicting file, we only have one, a couple of lines. It says here that this change is what is now on index‑changes, and this is what is on master. It's up to us now to decide which one we want. Well, I'll actually want the one in index‑changes, so I remove this path here. And don't forget to remove this as well. There we go. We're now in a good state again. I can mark this conflict as resolved, and now automatically the commit can be merged. Great, the merge conflict was resolved, and pull request can go ahead as we've done before. A new merge commit is going to be created for us. And I can now safely delete his branch. Now let us take a look at how we can solve merge conflicts using the command line. I've opened a command line here again. I'm switched back to the master branch, and Git has noticed that we have new changes on GitHub. So the first thing that I'll do is, I'll do a git pull. This will bring in all the changes that we've just made, for example, on the index.html. Now we can now continue locally working, for example again, on the index.html. Let's now with the new home page, I'm going to remove a couple of lines here. I'm also going to bring in again some exclamation marks to make a sad header again a bit more enthusiastic. I'll save that locally. There we go. Now meanwhile, someone else remotely on GitHub can have made a change to that same index file. I'll quickly do that here directly on the master branch. There we add just one exclamation mark. As long as we're going to have another conflict, I can show you how we can solve that. Let's commit that directly to the master branch. So now we have two versions of the index.html again, one on GitHub, and one locally with changes, conflicting changes, I should say, because we have edits on the same line. I want to commit my changes here and then push them back up to GitHub. So I'll do another git commit ‑am, and I'll say that this is going to be my index‑changes. We can make that local commit, and now I'm going to push that up to GitHub. Now Git is going to say, hey, that didn't work, because, again, we have changes on the remote that you didn't have locally. So we'll need to do a git pull. Now Git has brought in the changes made locally, but it also said that we have a merge conflict in index.html. The merge failed, and we need to fix the changes and then commit the result. We're now in a merging state. I need to go back to the index file, and now I've adjusted the code automatically shows me the changes made remotely on GitHub as well as locally. So this is my local change here, and this is the change that was sent to us from GitHub. I can now edit this. The adjusted code can help us a little bit, but let's do the change manually. So I will actually remove, overwrite, let's say, the incoming change, and go ahead with my change here. Save that file, close code, and I'll do now another commit. I'll set the message to resolve merge conflict. That seems to have worked. We can now go ahead and push, and if everything went okay, we can now go back here to the master branch and take a look at the index.html, and the changes that we made locally are now back in the master. So we've now solved all sorts of changes using the local command line.

Demo: Creating a PR Template

And when we have a larger project, it makes sense that collaborators follow a certain path to create a pull request. For this reason, we can create a template. We'll do that in this demo where we'll use this template to create a pull request. The pull requests we have made so far weren't the best examples in how you should actually be commenting your pull request. In fact, what is better is that we create a pull request template. If you want to make sure that contributors to our depository are always going to be submitting a pull request in a specific format, we can create a template for this. This one will ensure when a new pull request is being made in the body of the pull request. We can actually create multiple templates, but for sake of simplicity, I'll create one in this demo. Now to let GitHub know that some file is a pull request template, we have to give it a specific name. So I'll go ahead and in the master branch, create a new file, and I'll call that pull_request_template.md with underscores in there. In the contents, I then put the text, the template that is, that I want everyone to fill in when they're creating a pull request. Let's take a look at the preview. _____ that contributors add a description and also indicate the type of change. We commit this file. We now have one template, and we go ahead and create a new pull request quickly. So if I quickly created a new branch, and I can now ask to create a pull request for that. And automatically, as you see, our new template is being used, and contributors are now going to have to fill in this template to give an indication of what change they are trying to commit in the pull request.

Demo: More Options with Pull Requests

In the next demo, we'll continue to work with pull requests. I'm going to show you how we can revert a pull request, see the history, and also use the blame feature on GitHub. I want to first show you how I can revert a pull request that has already been merged. Let's go back to the pull requests for our repository here. By default the filter says that it's showing open pull requests. I can remove this filter or alternatively simply click here on Closed. That shows the pull requests that we've made so far in this module. Let's take a look at the one that I've made last here. That was the one with the template that I omitted to fill in correctly, I agree. But notice here that on that pull request, I can now click the Revert button. In fact, when I revert a pull request, it will create a new pull request to revert the changes. Indeed, we are going to again make changes. It's going to do it in the opposite way, but in fact it is just another change. So let's click Revert here, and there we go, it's going to open a new pull request, titling it automatically the revert of the pull request. It reverts that pull request id with id 5, and I create a new pull request. This can then be handled in the exact same way and is going to automatically revert the changes. It could, of course, be that this causes again conflict, and then we need to fix those either in GitHub or via Git locally. And if we go back to the code, we see that we already have 27 commits. There's a whole history that we can browse of all the changes made inside of a repository. Let's take a look at one of the commits here. Here we then see the history of the changes made in that commit. We can therefore drill down in all the changes made to a file. That is possible not only on the master branch but also on other branches that we have in our repository. Now we can also do that on a line‑per‑line basis. Let me show you. For example, we've made quite a few changes to the index.html so far. I'm now in the master, and I can click here on the line 14, the one with the header, and then these ellipses will appear. I can now take a look at the git blame feature, which gives me the full history of all the changes made to that line in a file. And we see here this little icon appearing that allows me to drill down in all the changes made so far by a particular user as part of a commit in the history of this line here. I can click on it, and then you see the previous changes made to that line, all linked to the commit that was responsible for this change. Of course, we don't have that many changes and definitely not a lot of people working on our repository, but this can be really interesting in a very active repository. Let me show you, for example, the ASP.NET Core repository, and I'll take one of the files here. And we can do the same thing. We can again click on a line here, View git blame, and then we see the full history of all the changes made to that file.

Demo: Setting the Default Branch

We can set a specific branch as our default branch on GitHub. We'll see how we can do this, as well as how we can restore an already deleted branch. The concept of a default branch is important since, well, as the name implies, it is used as the default when using GitHub. Now, so far, we have used the master, which is, by default, the default branch, but we can change that. Now the default branch is actually important since it is considered the base branch, let's say, of the repository against which all pull requests and commits are going to be made unless we specify a different one. We can, for example, create a new development branch, and we may want to make that the default. So to do that, we can go to the Settings, and we can now make this the default branch. Click here on Branches, and switch here that the development branch now becomes the default branch.

Forking a Repository

In the last section of this module, let's talk about forks. Now what are forks exactly? To put it simple, a fork is a copy of a repository. Yes, _____ in fact nothing more than a copy of an existing repository. We can make changes to that copy without impacting the original repo. Now, of course, plain GitHub is more than just a plain copy. When we create a fork, the copy basically remains linked to the original repo. So if there are updates in the original repo, we can get these changes into the fork as well. Also, the opposite is true. If we have created a fork, it's possible from this fork to create a pull request so that our changes can then optionally be merged back into the original repository. Forking is available for everyone. Once you have created the fork, that fork is now your own repository, and you can manage it entirely. So that means that on the new project, you can bring in collaborators, change the settings, and so on. Forks are typically created to test IDs. And yes, forks are definitely related to working with branches. Forks are a GitHub thing, they don't come with Git itself. That's why I talked about them here, says they really highlight the social aspect of the platform. One major difference between forks and branches is that branches all work on the same repository, whereas forks work on a different repository. In terms of being able to create a pull request to merge your changes back into the upstream repository, things are pretty similar here.

Demo: Forking a Repository

In the final demo of this module, we're going to create a fork and make changes to that repository. So let me show you how I can fork a repository. So this is the Gill Cleeren account, so the account that we've been working with so far. And this is the Gill Cleeren demo account, or a second account. I can press here to the Gill Cleeren account and look at its repositories. We also see the refactored‑umbrella repository. If I now want to make a copy of this repository in my personal account, I can do so. I can click here on the Fork button and it asked me where I should be forking this into, and it is indeed in my own account. So let's do that here. As you can see now, the Gill Cleeren demo account now also has its own copy of the refactored‑umbrella repository. GitHub does note that this was forked from the original Gill Cleeren account, so my original account. The entire history of commits, branches, and so on has been brought along. But these are now two independent repositories. However, I can merge changes from this repository back into the upstream repository. But to show you that I can do whatever I want here, let's create a small change in index.html. There we go. I'm going to commit this into the master. This is, of course, just to change now in that forked repository. The original repository has no notion about these changes. They are living separately.

Tracking Issues and Creating Releases

Module Introduction

Building software is more than writing code. Managing the project means following up on bugs, issues, and entities about the application. I'm Gill Cleeren, and I want to welcome you to the tracking issues and creating releases module in the GitHub: Getting Started course, here on Pluralsight. Let's see what we will be learning in this module, shall we? So what will we be covering in this module? Well, I have four items for you that I think are closely related to how you can use GitHub to manage a software project. We'll start with what I think is the most important one, issues. You'll see that issues are GitHub's way of managing work items. Next, related to issues, we'll also look at milestones. Then we'll look at tags, and finally, I will show you how to label a certain commit to be a release, how this all sounds interesting to you. Let's get started straight away.

Working with Issues

Issues are a fundamental block for GitHub in allowing us to manage our work through the interface. We'll start by taking a look at what types of issues GitHub defines. The word issues can trick you in thinking that they are a negative thing. Hey, there's an issue with your code. But, that's not the case. In GitHub, issues is just a name to indicate everything that is going on from, indeed, yes, bugs, so the negative one, to enhancements, to work tasks, and even ideas. All these feedback items are basically collected in one large tracker called issues, and each repository will have an issues tracker. New features that need to be created can be tracked by the creation of an issue. Issues can also be linked to a pull request. We can then, when we merge the pull request, close the corresponding issue. Closing the issue does not mean that the information is gone. All of the related information remains available in GitHub. When we use issues, we can also be notified using a notification system. Imagine that you have created an issue. When someone then creates a comment on that issue, you'll get notified. This helps in staying up to date regarding the state of the issue. Pull requests can also be associated with an issue. We can, in a pull request, mention an issue number combined with a keyword. Issues can also be used to work with milestones, which I will explain to you very soon. For now, you can see a milestone as a point you want to reach. That point is reached when you complete a number of issues and the relation of issues and milestones. Since issues are a GitHub feature, the site has all the required interface to work with. Probably the most relevant screen in this area is, of course, the issues tracker itself. This issues tracker is linked to a repository. In the main screen of the issues tracker, you can see a list of all open issues by default. Of course, we can also set it to display other lists. Let me explain to you one more thing before we go to the next demo, and it is labels. Labels can be applied on issues, but also on pull requests. They are typically used to organize and prioritize items such as issues. Again, labels are a GitHub thing, quite logically, if you think about it. They are added on issues and pull requests, and they too are specific GitHub things. By default, GitHub already comes with a set of built‑in labels, but if these do not surface for you, you can create your own set or even delete the built‑in ones. By default, eight labels are built into GitHub, and so they are available on each repository for you to use. And you see the list of the default labels. Assume, for example, that you're creating an issue that describes a bug, you can then use the bug label to categorize that issue. When you and other people working on the repository consistently apply labels, it will also make the overview of the issue list much easier to digest.

Demo: Working with Issues

Alright, time for a demo on working with issues. We'll take a look at the issue tracker related to the repository, and we'll create an issue. We'll also take a look at how we can link an issue with a commit, and we'll take a look at working with labels. So far, we've been working pretty much on our own in our repository. But real‑life projects are typically managed by a group of people, definitely on GitHub. It's a social coding platform. And it also means that people will report bugs and issues, and those can be followed up in the issue tracker. The Issues tab gives you access to this issues tracker. If you don't see it, by the way, go to Settings first and then under Options, you can enable or disable features. In this case, issues is enabled, which means that we do see it. Currently, we only have one issue. There is, in fact, a search option at the top, filtering the list of issues. There's a couple of built‑in filters as you can see. I can select, for example, only my issues, and it changes the search field here. I can also say that I want to, for example, see issues assigned to me, and there we go. There's currently none assigned to me. If I just remove this, then it goes back to all open issues. If I have closed issues, we can click here, and now we see all closed issues. And since my list of issues is rather limited, let's go to a real repository, for example again the aspnetcore repository. And in there, let's click on Issues. And now we see a whole list of issues. Notice that there's also labels and milestones that can be used to filter out the list. We can, of course, also filter here again on users and apply a label. We'll talk about labels soon, projects, and so on. In GitHub, everyone can basically file an issue. As you can see, I don't own, of course, the aspnetcore repository, but I am capable of creating a new issue. But let us do that in our own repository. So I'm going to create a new issue here. And so let us say that because of a new company policy, the background color of the website, of the index that is, needs to change. Well, we can then create a new issue that could be like a task, an assignment to someone. And we also need to add some more information here in the comment field. Here on the right, we can set other options for the issue. For example, I can assign this issue to someone in the collaborators team. In this case, let me set myself here. I can also use labels, I can make this part of a project, and I can also make this part of a milestone. We'll talk about these later. Let us now submit the new issue. This issue has now received ID number 7. That's basically the way to, let's say, address this issue. It's also been assigned to me right now. I can, of course, from here again edit the issue and, for example, bring in a label. And again, we'll talk about labels, but I think you can more or less figure out that they are. For example, this could be an enhancement. From here, I can also add another comment and also possibly close the issue if needed. In the list, of course, that new issue is now also being shown, and it does contain a label, and it also says that it's assigned to me in this case. Now you may be wondering, why did this get issue number 7. We didn't have any other issues, and I didn't delete any. In fact, that counter is used for other things as well. For example, pull requests follow that same counter. As we can see, the last pull request was 6. And so our new issue got ID 7. Now why am I emphasizing these numbers? Well, we can actually, everywhere within GitHub, within our repository, link to that issue using that number. For example, we could, of course, close an issue directly here. But we can also do this in another way. For example, let's create another pull request quickly. So now a new pull request has been created. And now because we're creating a pull request, it's automatically picking up the pull request template that we created earlier. But in the comment, I can now here say that this fixes issue ID 7. The background color needs to be updated. We create a pull request. And if we then click here, we automatically see again that issue that we have associated with this fix. And before I merge the pull request, let us include another comment here. I'm going to say that this closes and that's like a known keyword in GitHub. This closes issue 7. Comment on that. Let's merge the pull request. And let us now go back to our list of issues, and we automatically see that our issue was now closed because of that comment. So there are also known keywords, such as closes in GitHub, that it uses in combination with issues to automatically, for example, close an issue. And I briefly mentioned already these labels here. Let's take a look at these. By default, GitHub comes with nine labels, and these are really a GitHub thing. You will never get these labels in your local flow. Labels are used to group issues. Out of the box we get bug, enhancement, good first issue, and so on. We can also create our own label. For example, let's call it task. And we can change the color of that label and create it. This now becomes like a filter. We can go back to the list of issues and associate the issue that we have here with that new label. If we now go back to the list of issues, we see the new label being used. And when we click on it, all tasks that have the label task applied to it will be shown.

Demo: Creating an Issue Template

We've looked before at working with templates when creating a pull request. In a similar way, we can create a template for issues being submitted. Let's look at that in this demo. Now earlier in this course, we created a pull request template to make sure that contributors to our project followed a certain path, a certain template to file that pull request. Now with issues, we can do the same thing. When we go to Settings, GitHub has the ability to allow us to set up templates. You see here under Issues the button to set up templates. Now GitHub comes already with a couple of pre‑created templates. I can, for example, create a bug report. That's the default one. I can edit this myself. This is, again, markdown, and I can add it like we did before. What is in there is all the steps that are needed to file the issues, or the bug in this case, so that people working on the project can also recreate this issue. We can add another one, for example, a feature request. So now I have created two templates. This will actually create two new files in our repository. So click here on the Propose changes button. And we are going to commit this directly to the master branch. We could also do this via a pull request, but let's do it a bit quicker and push everything directly to the master branch. Here you now see that GitHub because of the fact that we have created two issue templates created a folder under the .github directory ISSUE_TEMPLATE. And in there we find two MD files, two markdown files that we have just created. And we now go to Issues, and we create a new issue. We are presented with the screen that shows us already the two built‑in templates for an issue, a bug report and a feature request. You can still open a blank issue if you want, but let's assume that someone found a bug. They can start inserting that bug report. Let's create one quickly here. And here I now have to fill in all the information about the bug. We can fill in all the other information. I'm going to skip on doing that in the interest of time. We can now submit the issue. And we now, as the owner of the repo, know that the bugs are going to be containing all the information for us to easily find what is wrong.

Demo: Working Towards a Milestone

Instead of talking about milestones, let's go straight back to GitHub and take a look at how we can create and manage a milestone. I have gone ahead and created a couple of issues. Now say that, for example, we are getting ready for the launch of our new website, but there are still a couple of things to be fixed. Well, we can actually wrap that getting ready for the launch in a milestone. So I can create one or more milestones from the Issues page. Currently, there are no milestones, but I can create a new one. Let's call this the Launch of website, and we would like to do this by the end of this month. I'll now enter the information about the milestone. At this point, there's nothing really associated with it. It's 0% complete. There's nothing related to that milestone. Let's go back to the issues, and let us now open, for example, this bug here, and I'm going to associate that with this milestone because, of course, we can't launch the website if the logo isn't scaling correctly. Let me do that for the other ones as well. Now I've now gone ahead and selected three out of the four open issues to be associated with our Launch of website milestone. And you can see that here. If I now click on this, we see that this milestone is 0% complete because we still have a three out of three issues to be fixed. I can now go ahead and, for the sake of simplicity, close this issue, although I haven't fixed it really. Let's close the issue. And now we see that 33% of this milestone is finished. Only two things to fix before we can actually launch our website. So milestones really allow us to group a couple of issues together, and when these have been reached, only then will that milestone be reached as well.

Adding Tags

Let's now take a look at how we can work with tags. Before we start a discussion about tags, I want to make sure that you remember the following, a branch points to a snapshot in the history of your project. It indeed has a reason that I'm saying that and that reason will become clear very soon. In fact, already in the next slide. In Git, we can indicate that a certain point in history is important. Many other source code management systems allow for this. Through tagging, we can indicate that a certain point has a certain value to remember. For example, this can be used to indicate that a certain commit is V1.0. In Git, we have two options to create tags. A lightweight tag is the first option, and it basically is nothing more than a pointer to a certain commit. The second type is an annotated tag. Such a tag is, as the name implies, more complete as it will contain information such as the email, date, and also perhaps a tag message. In general, these are the tags you will typically want to create. Tags can also be added later on. So that means if you already have other commits after the one you had planned on tagging. Adding a tag is done using the git tag comment, adding the dash a parameter makes this into an annotated tag where you can then add other information. Once we have our tags pushed to GitHub, we can explore these via the website. With a tag, we can download the corresponding code that is linked to that tag. And remember, it's nothing more than a commit. So via GitHub, we can download the code that is associated with that tag. Through GitHub also, we can then see a list of commits that leads to this commit, also so more information about the tag, such as the message, is available in GitHub.

Demo: Adding Tags

Now that we have an understanding of tags, let's go back to the demos. We'll start with the creation of tags locally, and we'll then push these up to GitHub. Once you have them pushed up, we'll take a look at the tag page on GitHub. Let us now take a look at how we can work with tags in Git and GitHub. I'm currently back in the command line, and let us first take a look at a command that we haven't shown yet. That is the git log command. Using the git log command, I can see a history of all the commits that have happened on my repository. If I click on Enter, it will continue scrolling as you can see here. This is quite a verbose overview. If I show the overview in a descending order, so the latest one is shown first. As you can see, the last thing that I've done is adding these issue templates, and I've done that on the master. The origin/master and the origin/HEAD point to this commit. Now I'm going to create tags. Using the git tag command, I get an overview of all tags which I currently have, and that seems to be a very small list. In fact, there are no tags at this point. So let's create a tag. I'm going to create a tag again using the git tag command, and I'm going to call this the stable tag. I also need to pass on which branch I want to create this tag. So if I now say git tag master, the stable tag is going to be associated with the latest commit on the master branch. There we go. If we now do another git tag, we can see that the stable tag is now available. Let's take another look at the overview using the git log again. To make things more easily readable, I'm going to use a couple of parameters on the log this time. I'm going to use the ‑‑oneline and also the ‑‑graph. This shows me a more compact overview of the history of my repo. Here at the top, we can see that this commit now has a tag, stable. That is the one that is associated with adding the issue templates. Now this is basically a lightweight tag. I'm now going to create an annotated tag. For that I'm going to use, again, the git tag command. Now since this is an annotated tag, I need to pass in the annotation, and that's, for example, be v0.1. I also need to pass in a message, so ‑m, and let that be v0.1 release. And I now need to associate this with a certain commit. Let's, for example, say that it will be this one that I'm going to associate with, so 336913a. Let's use another git tag here, and we now have two tags. Let's also bring in a tag for 0.2 and let that be the latest one, so the 2dedd4c. If we now call to git log ‑‑oneline again, we indeed see that the 0.1 and 0.2 annotated tags have been added. We've added these tags locally. The next step is bringing these to GitHub. So let's do a git push. And it says here everything is up to date. That's kind of weird. Let's go back to GitHub and take a look at our tags here. If we go to releases, we'll see there are no releases and apparently also no tags. The reason is that when I do a simple git push, local tags will not be pushed up to GitHub. I need to execute git push passing in that tags also need to go along. So I need to pass in ‑‑tags. Now I've pushed all tags as you can see here, but I could have optionally also only pushed one single tag. If we now go back to GitHub and we refresh the page, we now see our tags. In this list, we now see the lightweight tags and the annotated tags. Let's first take a look at this v0.2. When I click on that, it will give me the commit that it's associated with. I can click on that, and then I see the contents of that commit. I also am capable of downloading here the source code as a zip file or as a tarball. I also see the commit message. This is, of course, the same for this v0.1. I click on these ellipses, and I also see the commit message. When I click here on this lightweight tag, the message that we see is the commit message that this tag was associated with.

Publishing a Release

We've now seen tags. Let's now turn our attention to releases. Already a word of warning though, tags and releases are very closely related. Releases are based on tags, and as mentioned, both are closely related. However, with a release, we can add other information. Probably the most notable difference is that with releases, we can create release notes. Through the GitHub interface, we can create release notes in Markdown format, and on the same page we can also add binary files related to this release. Let's return once more to GitHub and explore how we can work with releases. We'll create a new release and take a look at the result. Now we just saw tags in the previous demo, but releases is very closely related to it. In fact, they are handled in the same screen. We saw tags earlier, and I click on releases, we see pretty much the same. So there are already some releases that say prepared for us, but I'll come back to that in just a minute. Now let's first create a new release, but before I do that, what is a release really? Well a release is basically a way of allowing you to use GitHub to distribute software packaged, let's say. This can be used instead of providing a downloads page. You can also link in a release to a binary file, so perhaps a compiled version, and include also things such as release notes. So we'll do that here. I'm going to click here on Draft a new release, and let's say that this is, for example, V0.3, and I'll used the Target: master. I'll name this our V0.3 Release. I can also again add some comments here and installation notes. Onto this page I can also now include the binaries I want to bring in. I have now uploaded a file. Now since this is still 0.3, it's not ready for production. I'm going to mark this checkbox here. Let's publish this release, there we go, and now we see that we have created a release which contains the sample.zip I've just uploaded, but also the associated source. This is now associated with the latest commit on our master branch. Notice also that it's marked as pre‑release. If we go back to the overview, we now see our release and its assets. By the way, note that also from the Tags page, I can click here to create a new release, which will then be based on the existing tag. I can follow the same flow here.