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
- A password
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!