Hey @AAAYAAALAAA , so you technically have two slides, the Introduction or cover slide and the slide you created. The `_posts` folder in your repository populates all of the slides in your slide show. If you created additional slide files (using the correct front matter) you would add more slides to your slide deck.
Thanks for checking out and finishing the course!
... View more
It looks like you were able to get past this issue. Congratulations on completing the course (here: https://github.com/artbueno/github-slideshow). If I'm looking at the wrong repository let me know and I am happy to help.
... View more
@lalaithan and @mkowales
The text should be added to the blog post, not the config.yml file. Your blog post file should have the following contents inside of it:
title: "Welcome to my blog"
... View more
GitHub is home to over 24 million users and 67 million repositories, which means there are a lot of projects to find. Mastering the different ways to comb through users, repositories, issues, pull requests, commits, and code will help you find projects that need your unique set of skills or answers to the problems you are encountering.
Before diving into the specific things you can search on GitHub it is important to create a foundation of basic search skills so as more advanced functionality is introduced you are ready to handle it :muscle:.
Please keep in mind while reading this article, the numbers used are liable to change as repositories, issues, and code change over the course of time. Regardless of how much GitHub grows, these search tips will help you find exactly what you are looking for.
GitHub Search 101: Seeing the Forest for the Trees
As mentioned before, GitHub is jam-packed with repositories. Thankfully the search features on GitHub are ready to give you an assist.
At the top of your dashboard, there is a search field, just to the right of the Octocat in the top-left corner. This search field covers all of the GitHub. For instance, if you were looking for the GitHub Services Training team's `training-kit` repo, but didn't know the name you might search for training. Impressively, 120,000+ repositories are listed with `training` but the `training-kit` repo isn't listed on the first page.
Using the options in the Sort dropdown, we can get the `github/training-kit` repository to display on the first page using the `Most Forks` option. However, we can maximize our chance at finding the repository we want by using GitHub's powerful search syntax. For example, adding user:github to our search skyrockets the `github/training-kit` repository from one of 120,000+, to the number one result out of 16. By limiting the repositories to a single user, we reduced our results by a lot!
Finding a specific repository is pretty awesome, however, sometimes you might need to find something inside a project. The search capabilities of GitHub have you covered and enable you to find all kinds of neat little goodies, like repository topics, code, commits, users, and even issues and pull requests.
For instance, if you wanted to find examples of `travis.yml` files across GitHub, you could search for `travis.yml` in the search bar found on the GitHub homepage. Searching for `travis.yml` brings up some files that reference the `travis.yml` file, but aren't actually the file you were looking for. Adding the `filename:` qualifier enables you to find files with a specific name.
Search qualifiers like `filename:` and `user:` enable you to narrow your search results to what you are really looking for. For instance, if you wanted to find `travis.yml` files that use a specific `env` setting, you could search for something like this:
env: NODE_VERSION=6.9.4 DISPLAY=:99.0 CC=clang CXX=clang++ npm_config_clang=1 filename:travis.yml
Search Who Needs Assistance
By using search terms and qualifiers you can dramatically reduce your search results and find exactly what you need, even across over 67 million repositories. As a final example of using qualifiers to find a specific set of information, we can try to find all of the issues that @lee-dohm has commented on that have the word bug in them.
If we started by looking up bug we get a lot of results. We are looking for issues though, so we can either use the type qualifier or select Issues from the search results page. There are over 4.5 million issues with the word bug found on GitHub. We are looking for bugs that @lee-dohm has commented on, so we need to add another qualifier to narrow our results. By adding commenter:lee-dohm to our search string, we reduce our results to 859 results! We can take it one step further and find all of the issues that @lee-dohm has participated in that are still open by adding this qualifier to our string:
With the addition of the `state` qualifier, those 859 results have dropped down to 80, it would appear @lee-dohm gets work done.
If you have a particular strength, whether it is coding, providing documentation, or providing QA for a project, you can search for projects with open issues or pull requests to lend a hand. Instead of using the last search we used to find open issues that lee-dohm has commented on, you could look for something like this:
Inspired by the blog post by Kent C. Dodds, some repositories use a `label` named "first-timers-only" to identify issues or pull requests to help newcomers become engaged with Open Source projects.
At times, GitHub might feel like it has an a lot of information to try and sift through, but with the use of the search bar and search qualifiers, you make the giant world of software development a little bit smaller.
About searching on GitHub
Searching issues and pull requests
... View more
Creating a username
To begin using GitHub, you should create an account so you can participate in open source projects, work with friends on a school project, or just explore a new tool that you overheard some people talking about at work. Creating an account requires three things:
A unique username, or handle
An email address
Your name is important. It differentiates you from millions of other people. So too, is your GitHub handle. That might sound a little heavy, but, think about this: Your GitHub handle can be used to view your contributions to public projects hosted on GitHub. Your interactions with other people on GitHub are introduced with your avatar and handle. Selecting a handle that identifies you for the amazing person you are but can potentially survive the test of time can be hard. Thankfully, that is what I'm here for!
When selecting your handle, it is very important to be true to yourself and who you are as an individual. Keep in mind, you might be listing your handle on your resume in the future and recruiters might be contacting you because of the work you do on GitHub. Having a handle that doesn't raise questions about your personality or how you mesh with different members of a team is a great way to gauge if you are selecting a great handle.
Another way to view your handle is that you are going to be growing with it, creating a handle like "NoobCoderForever" might be funny as you are just starting out, but as you gain experience you might look back and wish you hadn't picked that handle. Perhaps you really like a band right now, and want to create a handle that reflects your love for their music. While you might honestly love Cardi B right now, you might not in 2 years ... or 3 months.
I would recommend avoiding trending topics for a user handle. Sometimes a trend will last, but, "FidgetMaster" or "SurpremeSpinner", might not make sense in the future. Think about things that make you unique, maybe a hobby you really enjoy, or something that so far has weathered the test of time and try and go with that.
At the end of the day, your GitHub handle will become your calling card when interacting with repositories. Other contributors will have to reference your name when asking you a question, assigning you a task, or commenting on the contribution you made. So, think about what you want your calling card to be, not necessarily for the next 15 weeks but for the next 15 years.
Creating a repository
Public or private repositories?
After entering a repository name and providing the optional description, you are presented with two repository publication methods: Public and Private. Public repositories, are just that, public. They are open and can be viewed by other contributors on GitHub. This allows other individuals interested in your project to hopefully find your project and either use it or hopefully, contribute to the future development of it. Private repositories on the other hand are hidden from the general public of GitHub and future contributors will need to be invited to the repository before they can see it, let alone contribute to it.
While you might be inclined to create a private repository, unless you are working on a project that you don't want individuals to help contribute on (like software you aren't ready to open source), it doesn't hurt to create a public repository. You can always change the privacy settings of your repository later (either making a private repository public, or vice versa).
For the example of creating a repository for your JS Tetris emulation, creating the repository as Public makes sense. It enables other GitHub users (and people not on GitHub for that matter), to find your project and potentially use it. So, even if this Tetris game is just an opportunity to follow a tutorial on the internet, others might find your project and comment on your code through comments on Pull Requests or creating Issues to identify what you could change or improve to make your emulation better.
Initialize with a README.md?
Before you click the Create repository button there is one last option I want to discuss: Initialize this repository with a README. To sum up why this option is important quickly, having a commit (or snapshot of the state of your project at a given time) created when you first create your repository enables you to begin working on the repository immediately. This is a great option if you are starting from scratch or don't already have a Git project that you want to import.
If you are planning on importing a Git project that is already on your computer, you shouldn't select the checkbox, because you will encounter a conflicting history issue when trying to send your local Git project to your shiny new GitHub repository.
The README file is a super special file on GitHub repositories, so, I definitely recommend creating one, even if it is after you create your repository and import your existing Git project. The README file is displayed on the Code tab of your repository automatically and kind of acts like a billboard of important information related to your project. Potential contributors to projects typically review a project's README file to get an understanding of what the project is, who to contact, and most importantly, how to contribute.
This "billboard" is your opportunity to provide visitors with helpful information about your project. If you have installation instructions, including them on the README is definitely recommended. As a markdown file, the README supports displaying images, inline links, and most importantly, GIFs and emoji. Other information that is helpful to include in your project's README file includes points of contact (or who should a user at-mention) in an Issue or Pull Request if they encounter an issue or have a suggestion. If you have a planning document for the fixes and enhancements you are planning on implementing in your project, including a link to that in the README is also a great way to provide information to a potential contributor.
The README file can also include "badges" from integrations like CircleCI, TravisCI, Appveyor, Slack, and many more. Displaying those integrations lets potential contributors know what integrations your project uses and if the current build is passing or has any issues.
Like most aspects of your project, the README file isn't written in stone, so it can grow and change as your project starts as a JS Tetris emulation and evolves into a multiplayer VR Tetris game where people play as the blocks!
Welcome to GitHub!
In closing, welcome to GitHub. Whether you came here from a resolution you made, or just wanted to stop lurking and create an account, welcome! I'm sure your new handle is as awesome as you are and your first repository is looking ready to grow with you commit after commit. May your 2018 be full of passing pull requests!
... View more
@harshitaarora so, if you cloned the repository locally, you are probably in the default folder of your Terminal application. Using the example provided in the instructions of the GitHub help documentation, If you type cd Spoon-Knife You will "change directories to the location of the fork you cloned". Basically, when you clone a repository, you don't automatically open it. You need to open the repository by using `cd` followed by the repository name to open it after you clone it to your local machine. Apologies on any delay in answering this question.
... View more
As a newcomer to Open Source projects or GitHub repositories, the term fork might seem very foreign to you. Last time you checked, you were trying to contribute to a project, not pick an eating utensil.
When you fork a repository, GitHub presents the animation of a copy machine copying a book, and with good reason.
When you fork a repository on GitHub, for example github/training-kit, an exact replica of the repository is created on your individual user account. So, if you were to fork github/training-kit, you would then have a repository on your account called username/training-kit.
Before we begin exploring our new repository, lets identify some terms that will make understanding forks a little bit easier. Our origin remote is going to be the new repository we just created on our account. So, for example https://github.com/octocat/training-kit.git would be an example of our origin. That same repository could create an upstream remote to https://github.com/github/training-kit.git. As you might have guessed, an upstream remote refers to the original repository from which you forked.
As we explore our repository, some really cool stuff happens. Aside from all of the content, the entire commit history of the project comes over when we fork the github/training-kit repository. Additionally the number of branches, releases, and contributors, are all duplicates of the upstream repository.
When you fork a repository with an open source license, you can begin making changes to the repository as if it was your own - because it is! Forking a repository opens the door to a whole new world of development. By forking an open source project, you can make changes to it without affecting the original repository, thereby safely creating a new version of the project on your own account. Additionally, you can help grow and evolve an existing project by proposing your changes be merged to the upstream repository via a pull request.
Up and Atom
The open source text editor Atom is assisted by a community that loves to contribute changes. The Atom repository has over 2,600 merged pull requests and some of them were provided from forks of the Atom repository. For example, pull request #15380 was created by a member of the open source community on their own fork of the repository. Something amazing about this pull request is that it isn't direct changes to the code base of the Atom editor, but to the README.md file that informs every visitor to the repository about a multitude of things. Thanks to their detailed contributing guide, everyone from first time contributors to open source veterans know exactly how they should contribute bug fixes, new features, or fixes to misspelled words in the README file. 👍
Community Piloted Robots
The FIRST organization utilizes the idea of forking heavily. Every team that competes in a FIRST event utilizes base code that exists within one of FIRST's repositories. Teams can modify the repository to give themselves an edge against the competition but can still receive updates to the core functionality from the FIRST organization.
This successful use of forking was accomplished with some foresight by the FIRST organizers. They created repositories that handled the different source code for the various robots that students were constructing, programming, and piloting in their competitions with a small caveat. Included in each repository is a folder that teams were instructed to make their changes in so that when new functionality was pushed out by FIRST, the customizations teams had made to their robots would not be overwritten when they updated their fork from the upstream remote.
Now that you have the foundations of forking down, give it a try! Find a repository that you're interested in and create your own fork (there is a detailed guide in our Help Docs on how to do it here).
You can find more information on forks and how to collaborate with them in our Help Docs:
Working with forks
Listing the forks of a repository
Searching in forks
Other fork-related Help documentation
And, of course, if you have other questions or want to chat about this article further, feel free to leave a comment below.
Pull request: An opportunity to compare the changes you made on a branch to a deployed branch, typically the master branch.
Remote: A remote is the address or location of a repository outside of your local copy.
Origin remote: Typically, the remote assigned to the address where your copy of the repository is hosted, like on your GitHub account.
Upstream remote: Typically, the remote assigned to the repository that you originally forked from.
NOTE: Remote names actually don't matter, but it helps to using naming conventions that the community recognizes. If you would like to identify the remote(s) in your project, type git remote -v in your command line application while in a git repository to list all of the remotes in your project
... View more