Intro to GitHub

View Github Repository Open presentation in a new window

TylerFisher

See all presentation from TylerFisher

Intro to GitHub

0 0

git-intro

Introduction to Git Slides

On Github TylerFisher / git-intro

Intro to GitHub

by Tyler Fisher / @tylrfishr

This is the Octocat. It's GitHub's mascot. I don't know why it's their mascot, but I wanted to explain the stickers on my laptop. GitHub is an essential tool for programmers everywhere. GitHub is used for version control. It helps us code collaboratively and work together without losing our minds over whose version of the file is the right version of the file. I'm going to talk about how GitHub does this at a basic level and introduce a workflow for you to get started using GitHub.

GitHub stores git repositories of text files and records a history of changes to those files.

GitHub stores git repositories of text files and records a history of changes to those files. This is about as basic a sentence as I could write to explain what GitHub does. So I'm going to spend some time unpacking what this sentence means and explaining some key terms in the sentence.

GitHub stores git repositories of text files and records a history of changes to those files.

Git repositories is probably the scariest part of that sentence, so let's start there.

GitHub is built off of git, a version control system.

Without getting too technical, GitHub is built off of git, which is a version control system developed by the same guy who made Linux. Git was designed to help software developers all over the world work on open-source projects. Open-source projects such as Linux are projects where anyone can see and contribute to the code. As for what a repository is, it might be helpful to just look at one.

Tacofancy

Click on Tacofancy, show them around.

Git repositories are just folders with files in them.

Despite the scary name, a repository is not much more than a folder. For your purpose, it's good enough to just equate them. What git does is track all of the files within your folder and watch them for changes.

GitHub stores copies of git repositories on its servers and makes git look pretty.

So where does GitHub fall in all of this? GitHub stores copies of these folders, or repositories, on its own servers. It takes the information that git processes and makes it look pretty. Also, anyone else can see and copy your git repositories. We'll get into that part more later.

GitHub stores git repositories of text files and records a history of changes to those files.

The next part of this sentence we need to explain are text files. It seems like an innocuous thing, but that's actually a fairly technical term.

Binary Files vs. Text Files

There are two types of files on your computer: binary files and text files. Well, sort of. Technically, everything is a binary file. What's a binary file?
When you think of code, you probably think of a bunch of 0s and 1s like the Matrix or something. That's actually not all that inaccurate. At its core, computers really don't understand more than binary code — a bunch of 0s and 1s. But you'll never, ever have to deal with that level of computer programming. Super smart people have written high-level programming languages and compilers that make programming more human. But when it comes down to it, every single file and program on your computer is translated to a bunch of 0s and 1s.

Text files only contain the binary code for text.

What's special about text files is that they only contain the binary code for text: letters, numbers and symbols. That makes them a very particular subclass of binary files. It's tricky to know what is a text file, though. A Word document, for example, is not a text file. Word stores all of the information about what font you're using, the color, the margins, the pages and a whole bunch more. Because that all has to be stored in the same binary file, Word documents do not qualify as text files.

All the code you write will be in a text file.

But all the code you write will be in a text file. And this is the type of file that git and GitHub interpret.

GitHub stores git repositories of text files and records a history of changes to those files.

If you're wondering why it is important that git reads text files and not other types of binary files, it's for the purpose of recording a history of changes.

Git knows how to read text.

Because the binary for text files is so simple, git knows how to read text.

Git can show you what changed in a file.

This is called a diff.

That means that, between versions of a file, git can show you what changed. It displays this information in what is known as a diff.

Over time, we can see a history of everything that happened in a repository.

Over time, as changes continually get added to a repository, we can see a history of what changed and who changed it within a repository. That's incredibly powerful, and its usefulness is pretty endless. If you're working on a project with a few people, and you're confused about a particular line of code, you can see who added the line. If you remove something from the code that you realize actually needs to be added back in, it's easy to go back into the history and retrieve that part. Finally, and most importantly, with everyone on a project pushing their most recent changes to GitHub, GitHub always has the most recent, canonical copy of a file. Everybody can stay up to date on a project.

GitHub stores git repositories of text files and records a history of changes to those files.

Here's that sentence one more time. GitHub stores git repositories — folders with special powers given to them by git — of text files — those files that just have text in them and nothing more — and records a history of changes to those files.

Okay, How?

Okay, it's time to teach you the workflow we'll be using for lessons. There will be a different workflow for group projects, but we'll get there later.

We're going to use bit.ly/unclass-git

You will have a quick assignment with GitHub to do between now and Wednesday. If you followed my email and setup the GitHub application on your computer, you can try to follow along now and get it done before class is over. Either way, it shouldn't take you very long. We're going to use this repository I set up, which is at bit dot ly slash unclass dash git.

Five verbs of git

  • Fork
  • Clone/Pull
  • Commit
  • Push
  • Submit (a pull request)
There are five verbs of git that we're going to be using. There are more, but these will do for now.
Fork To copy a repository from a user's GitHub account to your own GitHub account. Fork means to copy a repository from a user's GitHub account to your own GitHub account. This is useful when you cannot or are not allowed to contribute directly to the original repository. Forking creates a copy for yourself that you can do anything to. For all of our lessons, we will start with forking the lesson repository.
Forking is really easy. You just go to the GitHub page for the repository you want to fork, and click the "Fork" button on the top right.
Clone To copy an entire repository from GitHub to your local computer Pull To copy the most recent changes to a repository from Github to your local computer The next verb is actually two verbs, but they're related. When you want to start working on a repository on your own computer, you clone it. That means you copy the entire repository from GitHub to your local computer. If you're working collaboratively on a project, and someone uploads changes to GitHub, you will pull the most recent changes from GitHub. Pulling doesn't download the entire repository; it just gets the most recent changes. For most of our lessons, you will only interact with cloning. On group projects, pulling will be vital.
Cloning is also really simple. In the GitHub app, you click on your GitHub.com account and find the repository you just forked. Then, you click "Clone to Computer." The application will ask you where you want to save the repository, so choose wherever you want it to go and let it download the repository. Then, you should see it in the Repostories section under "This Computer" in the sidebar. Click on the arrow that leads you into the repository.

Make changes

Once you have the repository on your computer, you are free to make changes to any file that you want. In this repository, there is a file called myname.txt where I have some information for you to fill out. Just edit that file with your information and save it. I'm using a text editor — we'll get to that in later classes — but you should be able to open it in TextEdit on a Mac or in Notepad on Windows and edit it just fine.
Commit To add and describe changes of files to a repository For git to recognize the changes you made, you have to make what's called a commit. A commit adds and describes changes of files to a repository.
Back in the GitHub app, in the "Changes" section of the repository in the GitHub app, GitHub should already realize that you've changed myname.txt. Just add a summary of the changes you made and click "Commit".
Push To send commits made locally to GitHub's servers While we have made a commit to our local repository, we haven't actually pushed the change to GitHub's servers. That is done in a separate process called pushing.
The GitHub app conflates pulling and pushing into one action called syncing. So we're going to press the sync button to push our changes to GitHub. Technically, the app is also seeing if GitHub has more recent changes for you to pull into your local repository as well.
Submit a pull request To ask the owner of the original repository to merge changes from your forked repository into the original repository. The final verb here requires the most explanation. Submitting a pull request is done when you've forked a repository and made changes that you want to be merged back into the original repository. This notifies the owner of the original repo and shows them the changes you've made through diffs. We're going to use this as a submission process for assignments. Your pull requests will probably not be merged, but it's a good way for us to see the work you've done.
On the GitHub page for *your forked repository*, find the Pull Request button, then click the "Create Pull Request" button on the next page. Finally, summarize the pull request you are making and send it along to the original repository owner.

Your assignment

  • Fork the repo
  • Clone from the GitHub app
  • Make changes to myname.txt
  • Commit and push your changes
  • Submit a pull request
So, your assignment is to do what I just demonstrated up here. You fork the repository I created, clone it to your computer, make the appropriate changes to myname.txt, commit and push your changes, and submit a pull request so I can see what you did.

Get these slides at tylerjfisher.com/git-intro