The basic unit of GitHub is a repository. This is where you code is stored and GitHub allows you to interact with others and with the code in great ways. In this lesson we talk about Watching, Staring, and Forking a repository. We also cover GitHub issues and pull requests and various other stats about a GitHub repository.
...the basic unit of GitHub is a repository. Let's explore this repository for a minute. There are a few things that you can do up here at the top.
First, you can watch the repository. This has to do with notifications that you'll be receiving. You can configure these notifications to notify you just in the web client here with the bell, or also in email.
If you select watching on a repository, you'll receive notifications for every conversation that's had in pull request and issues. If you set to not watching, which is the default, you'll only be notified when you are participating or at mentioned. If you say ignored, then, you'll never be notified even if you're mentioned or if you're participating in a conversation.
Next is the star. If we star this repository, then, we can go to our GitHub.com/stars page. This will show that repository starred in our stars page.
This is a way to bookmark a repository, and also, show appreciation to the repository author for the work that they've done. This also impacts GitHub trends. It's another way that GitHub uses to recognize the popularity or the trendingness of a repository,
We can also fork a repository. This basically makes a copy of the repository that is associated with your user. If I click can see dots here, it's gong to make a copy of this repository that is forked from egghead IO GitHub Stack Overflow copy paste.
I have the exact same code in my repository. I can pull it down. I can push changes to it, do whatever I want with it, because it is my very own repository. We'll look at this a little bit more later.
Let's go back to the original repository. For the code area, we see all the code listed here. We can browse it. If there is a read me file in the directory that we're looking, GitHub will automatically render that file at the bottom of the code area. In this case, it's markdown. That's the .md extension. It will also render a couple other formats as well.
I recommend that you learn about Markdown. If we look at this readme.md file and look at the raw, we'll see that it's simply code that can be rendered in our GitHub repository. If you want to learn more about how GitHub parses this markdown, you can simply Google GitHub flavored markdown. it will probably be the first result. You can learn more about that here.
The next area is the issues. This is where we would collaborate with the project maintainer on features that we want to have implemented or bugs that we've found in the project.
Depending on the project, this is also a good place to ask questions. However, many projects have a chat or another mechanism for asking questions like Stack Overflow. You'll want to check the contributing guidelines first. We'll look at that a little bit later.
You can also be 99 percent sure that any project maintainer would be fine for you to file an issue that thanks them for their hard work on the project. Feel free to do that here.
The next thing as pull requests. A pull request is when you have changes in your own copy of the repository that you would like to have merged with the main repository. You would file a pull request here and iterate on your solution with the project maintainer before they actually merge your changes into the main repository.
Next is the wiki. Some projects have a wiki, some don't. But the wiki is a good place for some documentation if you don't want to put that in the read me or some contributing guidelines and other things of that nature.
Then, you have the pulse. This will give you an overview of how active the project is. Then, you have graphs. This will give you interesting information about who's contributed to the project.
If you have access to the repository, you also get to see some of the traffic that has been coming to the repository. You also get a sense of the commits, when code is being contributed.
Network is actually really useful. If a project appears to be inactive, you can look at the network and see other forks of the project to see if anyone else is maintaining the project.
Finally, you have the members of people who can contribute to the project. T
Then finally, if you own the repository, you also have settings. That will give additional settings for the project as a project maintainer.
That's an exploration of the GitHub repository...