Series Week 1 - GitHub: The Crucial Tool Every Developer Needs
Hi everyone! To kick off the Talk Like A Developer series, I’ll introduce a vital tool every developer at any level should use.
About this series: This series isn’t going to give you everything you need to roll up your sleeves and start coding. What it will do is give everyone, even the people who have no idea what computer science is, the ability to talk and ask questions about these topics so that if you are interested in getting into the hands-on/technical side of these topics, you’ll know where to start, what to Google, or how to ask for help.
For those who had the chance to read my post: Key Coding Terminology For Beginners, you’ll remember that similar to using Google Docs to collaboratively work on writing projects, GitHub is a great tool for collaboratively working on coding projects. You can create a folder called a “repo” (short for repository) that will contain all files for a coding project and can be accessed online by anyone you give access to.
GitHub repos are also similar to Google Drive folders in that anyone with access can make contributions, see all contributions made by others, and access anything saved on a GitHub account from any logged-in device.
Next, I’ll walk you through how to get started on GitHub. I highly recommend following along to help boost your understanding - and it’s totally free!
Getting Started on GitHub:
If you already have a GitHub account, you can skip to step 4.
Step 1: Go to https://github.com/ and click Sign Up in the top right corner.
Step 2: Follow the prompts and provide your information to create your account.
Step 3: Once it asks what features you’re interested in, scroll to the very bottom of the page and click Skip Personalization - this is just so they can offer you a paid plan, but in my entire experience using GitHub, the free version has everything I need.
The first view that will pop up is called your dashboard. I personally don’t like this view - totally up to you, but I prefer the view from my profile.
Step 4: Go to your profile by clicking on the icon in the top right corner and selecting Your Profile under the drop down.
Step 5: Click on Repositories from the bar across the top.
Step 6: Click New to create a repository.
These options may look overwhelming - don’t worry! I’ll show you the most common selections I make, and there’s no harm in choosing the wrong things - you can make needed changes later!
Step 7: Enter a repo name in the Repository Name field. There are certain naming rules you have to follow, but it will tell you what to fix if needed.
Step 8: Make the repository private - you can always give access to select people or make it public later if you feel comfortable.
Step 9: Check the box next to Add a README file - I’ll explain what this means later.
Step 10: Click Create repository - if you want to add any information to the fields I skipped, feel free to do so, but they’re not required and I don’t typically use them.
Now you’ll see the view inside your repository similar to the image above. This is exactly like if you created a folder in Google Drive and clicked on it. Right now it’s empty since you just created it, except for the README file.
The README File:
A README file acts as a “cover page” for your repo and doesn’t require any coding - think of it as a text document to introduce your repo. README files do not impact your code at all and are totally optional - they’re great for organizational purposes! What you do with it when your repo is private is totally up to you - I typically use it for reminders/tips for myself to reference during and after working on a given project. For group projects, you’ll likely use it to put your names, project information, and anything else applicable.
If you make your repo public, you’d likely use the README to tell people what your project is, how to use it, or include an ownership license you might have so people can’t copy your code. However, in my experience, I’ve never heard of any students making their repos available for public use.
The README file can be edited by clicking on “README.md” and then clicking on the pencil icon on the right side of the screen. The “#” you see just means that the line will be bolded. Typing a line without “#” at the beginning will just make the font normal. To save any changes in this file, scroll to the bottom of the screen and click Commit changes - to “commit” something in GitHub is just like clicking “save” on a Word document. To learn more about editing Markdown files (files ending in .md), check out this link.
To get back to the main view of your repo, just click on the name of your repo at the top of the screen.
You may be wondering how to add the files you’ll actually code in, which can be done directly by clicking the Add file button, but I’ve never added files this way. In a typical project, you’ll start with some sort of code skeleton folder that you either got from your professor, found online, or created yourself directly on your computer, but that’s a topic for another post.
Now that we’ve seen how to get started on GitHub, I’ll talk a bit about what makes GitHub different from collaborative tools such as Google Drive.
What makes GitHub different:
As I mentioned in my post: Key Coding Terminology For Beginners, the main difference is that, unlike Google Drive, it isn’t recommended to edit your files directly from the GitHub website. It’s bad practice because there isn’t an IDE (mentioned in this post: Key Coding Terminology For Beginners) built into GitHub, meaning that you won’t be able to run your code to see if any of your changes would cause errors. So instead, you will download a copy of your repo to your computer so you can edit them using an IDE.
Additionally, GitHub changes aren’t saved automatically and contributions by others can’t be seen in real-time. As I mentioned earlier, you will need to “commit” any changes you make to files in order for them to show up on GitHub. With that in mind, you want to make sure only one person is making changes to a given file at a time so that you can avoid a merge conflict.
What do you plan to use GitHub for? Let me know in the comments below!
Thank you so much for reading and come back next Monday for another Talk Like A Developer post! If you have any questions, feel free to comment them below or email our technology blog directly at techblog@apartfromblonde.com!
Check out this and more posts on my Medium account HERE!