November 15, 2019
  • 6:51 pm Jermaine Couisnard, Jair Bolden News Conference — 11/13/19
  • 5:51 pm Yurachek press conference on future of Razorback football
  • 5:51 pm FOMC Press Conference March 20, 2019
  • 1:50 pm Trump Impeachment hearings live: Public testimonies from Bill Taylor and George Kent
  • 12:52 pm [Boyfriend ASMR] Can’t i just video call to my beautiful? (Korean Boyfriend JINO)
Webcast •  GitHub Use Cases, Workflows & Desktop Apps • July 2014

Good morning to you all. My name’s Jordan McCullough,
and I’m part of the GitHub Training team. Today you’ve joined us
for the July 23rd free class, which is GitHub Training’s
way of sharing some really nice introduction
to both the GitHub platform, use cases, why you even
want to use, why you want to use Git
as a version-control system, and then even to make things as simple,
and easy, and approachable as possible, some desktop apps
which GitHub provides, it’s available to download as well. So we’re going to go through
all those topics in the next 45 minutes or so,
and then if there are questions, we’re also following this free class
with a GitHub Training office hour, and that’s your way of having
all these ideas or these questions crop up during the course
of this kind of introduction 45 minutes, and if there’s anything you have
that relates to the Git technology, day-to-day workflows,
or something using, that’s your way of reaching out to us, and we can give you live examples
and walkthroughs there. So, over the next 45 minutes,
we’re going to see what GitHub looks like, why we want to use it,
some of those tools, and those workflows. So I’m going to get right to it. And the first thing to know
is that my name is Jordan McCullough, and again, if you want to follow me
on Twitter or Instagram, I’m @thejordanmcc. If you follow me on Twitter,
I sometimes, when I find the chance, tweet about some useful shortcuts, or things about the Git technology
and the GitHub platform. So, if you’re interested,
that info’s out there. And, of course, if you want to get
a hold of the GitHub Training team, if there’s something
that relates to this course, or maybe even some additional education, or even more importantly, you want
to look at some of the resources that we’ve used, either in this course, or even in some of the courses
that we teach that are open enrollment, all of our documents, all of our
education materials, are open source, and available at So if you’re ever interested, or even if you want to teach
some things yourself about this platform, those are all free and available, and those are on that web site,
right there on screen. But with that, I’m going to jump
right away from slides, and I’m going to jump right into
going through what is. So I’m going to pull up a web browser, and that web browser is coming
right up on screen, like this. Now, when I log into, this is going to be the persona that I use during any kind of examples
and scenarios for class. And so I’m going to be this character
called “GitHub Teacher.” Now hopefully you already have
a GitHub account already set up, but if you don’t, I’m just going
to take one step quickly back, and show you what that process
looks like from the very beginning. If you don’t have a account, and you only intend on having
public, open source repositories, projects that anyone else
in the world wide web can access, then you can have a free account. You can set up a GitHub account. You can have free projects
hosted on our platform. And that’s all just through
this sign-up form right here. But I already have an account,
this githubteacher persona, so I’m just going to sign in real quick, and put in my githubteacher log-in, and my super-secret password here,
and hit Enter, and of course, and I just get dropped into
my dashboard of my GitHub account. Now the thing that
I’m interested in most is– I’m going to click on my user name in the upper right-hand
corner of the screen, just to get to my main page. That kind of gives me a survey of how
I’ve been interacting with my account, and the repositories of the projects
that I have hosted on the platform. Now the first thing
to keep in mind is that there’s a distinction between, the collaboration platform, and Git, the technology
that we’re using at, and also what you’ll be using
on your local machine, if you’re interacting
and versioning your documents. When we speak about
the platform, we’re talking about a place
where your code can live, that you can share with others, others so that your colleagues,
your teammates, your friends, maybe even the open-source community might be able to work on a project, help you improve your code,
or your documents that you have in your account. So for the sake of today’s example, what we’re going to do is just
build out a very basic web page, a project that’s versioned
with the Git technology, and then it is publicly shared
with the GitHub platform. So the first thing I want to do is get this one thing up on screen
that can highlight my cursor, and that’s this
little highlight right there. And let’s take our first step
into using the GitHub platform, and creating a repository or a project where our new web site
files are going to live. And the way that we do that
is we go to the upper right, and you’ll see that there’s
a little plus sign on our page. We’re going to click on that, and we’re going to click
on “New repository.” Now another thing, just as a note– The pace of today’s course
is a little bit accelerated, just because I’m demonstrating
a lot of concepts, and flows. You don’t necessarily need
to follow along, unless you’d like to. You’re welcome to if you’d like, but it might just be better
if you just observe, and see some of these actions take place. Alright. So, I click the plus sign. I’m going to click on “New repository.” I’m going to dismiss
this highlighting here. And the moment I do that,
I get redirected to a page that says, “Okay, you’re going to create
a new repository or project, you need to give it a name.” In this case, I’m going to give it
a name that’s very special to GitHub, and that name is going to be
what looks like a domain name, and that’s going to be, and I’m also going to have it be placed
under my organization account. It’s just a different way
of grouping my repositories, just so that that’s where this project
lives within my githubteacher log-in. So I’m going to have this new project,
this new repository, called And that’s just the same as if you were
naming a folder on your hard drive, there’s nothing really
all that special about it, other than it signifies
what this project is all about. Now I can also provide an additional
description, a way of saying– “Okay, so the name is,” or I should say, .io,
to be more specific. But maybe I need a little bit
better way of describing, to anyone unfamiliar with this project,
what it’s all about, so maybe I can say: The official GitHub Training school
organization web site. That helps a little bit more, in terms of what is going to be
contained in this project. Now, I’m also going to choose, because I would like you to all
be able to open up your web browser, and see what this repository
contains at any point, that it’s public, meaning that anyone that has access
to the GitHub web site, and that is anyone with internet access,
would be able to see this. I’m making the decision to publicly expose
all the code and the history and the versions
that I’m going to generate within this repository
called The other thing is, since this
is a brand-new project, I’m going to let GitHub
help me out a bit. I’m going to allow it to create,
or initialize my project, with a README, a text document that’s simply
going to have some content that I’ll author here in a few moments, that describes a little bit beyond
what that description field is; that this project is in my web site,
it’s going to be open source, I would love to have
the community contribute to making it look like
a better-looking web site, and maybe what
the contribution guidelines are. It’s just going to be a document
that kind of introduces the project and what the entire scope of it is. Now I’m going to leave this
Add .gitignore as selected to None. We don’t need to worry about that today. But the one thing is,
since this is a public repository, it might be a good idea
that I choose a license, a text file that just indicates
what type of terms and conditions other individuals
that have access to this– Can they use this project?
Can they copy the files? Will they get credit? What kind of attribution do they need
if they copy into their files, or they reference this project? And GitHub provides just
some template text files that Git automatically inserted
into your project, to your repository. So in this case, if I scroll down,
I can see all the ones that are available by default,
that we’ve established. Just one click,
(clicking sound) and you have a repository and a license
that defines the terms. But in this case, I’m just going
to make things nice and quick, and set it as an Apache v2 License. I’m going to click this big green button. This is the final step
in solidifying and confirming that, yes, we want to create a repository
on the GitHub platform, a place where our files
for our web site are going to live. And there we have it. The first thing you might notice is, “Wait a second, okay, Jordan indicated
that there’s going to be some kind of license text file, and there’s going
to be some kind of README text file, but what is this going on that it
kind of looks like a file view, but it also looks like we have some text
being rendered in a very formatted way down below the file listing.” And says,
“Alright, if you have a file in your project, we’re going
to render that for you,” because that’s kind of a nice way
of giving a summary to any individual
that comes along to this project, that they can quickly see some
formatted text that describes the project, and any objectives
in that scope, and what not. But you might say–“How did you get
the formatting slipped in there?” And the first thing, I think,
is a great introduction to using the GitHub platform,
is seeing why this text is formatted, and how we even version changes to just a plain text document,
like Now we’re still just on the web site, and I’ve decided that
I don’t need to bring this project down onto my hard drive just yet.
I just have internet access, I’ve only been logged into my GitHub
account for a few moments here, and I’ve already decided that
I need to edit one of the files within my brand new repository, that’s going to soon contain
my entire web site. So I’m going to just click on
the text file, and see that–
okay, that doesn’t look much different, other than I’m just viewing
the contents of that file. But it still looks very much formatted. But even more interestingly,
I want to edit this text file. So now that I’m viewing
the contents of this document, I will click the edit button, and say, “Well, I need to change this up a bit.” That, at least basic template text,
doesn’t do it quite for me. It’s a good start, but I think I can take it
and make it a little bit better. So, I don’t really need the title
to be just the repository name, and I don’t need this indicator, that bar is making
the formatting, that big header, and what we’re going to be using
here is some markdown, what at GitHub we call
“GitHub-flavored markdown,” a way of taking plain text documents
and formatting those just with text characters, and then
the GitHub platform will render those in a nice, friendly way
on screen, that makes it much more readable in the final form. So in this case I’m going
to say that this is the “Official GitHub
Training School web site,” like so, and maybe I’m going
to put a subheading, so I’ll put two # signs, and say that– Okay, well, maybe I should
be clear about what the repository is, so I’ll put Now, again, this is just
a text document, nothing else. And I don’t really need
that description right now, but maybe I’ll put some objectives, so I’ll put a triple #
for an H3 or a Level 3 Header, and say–
### Objectives of the project and those are:
* Demonstrate GitHub Pages which is going to be
an auto-deployed web site that we create just from our repository, as a side effect of this,
of some of the work we do. The other thing is:
* Collaboration patterns And then maybe lastly we’re going to say, * Using GitHub for Mac and Windows desktop clients So now I’ve made
some edits to this document, and I scroll a little bit further down, and I’m going to make the first commit, or the first version change
ever to this project. And so here I’m going to say,
alright, I am going to… Update the title, add objectives something that indicates
what action was taking place, what changes were actually occurring,
without being very specific, I don’t need to say what words I changed,
or what lines I changed, just a general kind of scope of why
I was making these edits, I was updating the title,
I was adding new objectives. Maybe I should say–
new objectives The moment that I click on
the Commit changes button, I am now permanently preserving
a version of this document, so that in history I could
always go back and undo, all the way back to the original
version of this document, when it just had a title. What I’ve generated is a commit in the Git version-control history, but I’ve also preserved
the changes in my document, which is now rendering very nicely
on the GitHub platform, just based on a few
extra characters I used, using the markdown syntax. If I go back to the root of my project,
and I can do that at any time by clicking the name of the repository
right there at the top of the screen, what you’ll notice is that,
alright, I still only have the
and the LICENSE text file, but now my README file
renders very nicely as that top-level summary of the project. But let’s take it a bit further,
before we do anything else, and that is– well, maybe
I don’t need to just edit files, maybe I need to also begin scaffolding, or maybe adding a skeleton structure
of some of the other files that I’ll want to work on locally,
on my hard drive, once I bring the project down there. And so I just want to get an idea
for what files are going to exist, maybe if someone else
is going to help me out they’ll see what I had in mind. If we want to build, or establish
any new files within this project it’s as easy as going
to the plus sign here, next to the repository name,
and clicking that. That’s going to author a brand-new file, and of course this is going
to be a web site project, so It would make sense that
I start with an index.html. Here I’m going to put some real HTML,
so there I’ll do my tags, and maybe I’ll skimp a little bit,
by just doing a head, and maybe next line
I’ll do a body, like so, and maybe lastly I’ll just
put one quick heading, and that will be
“the GitHub School Web Site” Now, this is a brand-new file
that I’m authoring on the GitHub platform, and if I scroll down to the bottom,
very similar to one we just edited, any document, and previously
it was the, that I now create a commit,
a marker in history when this file, for the very first time,
is being introduced. And so here I’m going to say, Add basic home page layout Sounds like it would work for me, at least I’ll know
when I introduced this file. I’ll commit that new file,
and now that new file shows up in my root of my repository. Clicking on that file,
I could dive right back in, see what the contents look like, and GitHub even detects
it’s an HTML file, and so it’s going to format
and syntax highlight those tags in the text content. I’m going to say, let’s take
this one step further. Let me edit this document, so just like we did with a README,
I’ll click the Edit button of that file. And maybe the other thing I can do is– “This is an example of the ability to deploy a web site
via a repository on” I should say “” Alright, so add another line,
and say that commit message is, “Add description about web site reasons” And I’ll commit that, like so. Now if I go back to the root of my project I can see I still only have an index,
a README and a LICENSE, but the thing that you should
make note of now is that there’s now this little blue link
up here that says “4 commits.” When we created this
repository, it said “1 commit.” Every time we make a file change,
and we commit that, we are generating
that new marker in history, that indicates that,
if something went bad, if we ever wanted to compare,
if we ever needed to step back and see why something
changed the way it did, well, first of all, we could assess
what those commits were. Oh, I added a description,
I added a basic home page layout, I updated the title,
I created the initial commit when this repository was first generated. But if we want to dive
a little deeper into that, and see at any point what was happening
with the files and the content there, all we have to do
is click the commit title, that description we wrote, and we’ll see, highlighted in green,
what was added. And if anything was removed,
it would be highlighted in red. So I’ll go back and say,
“I recall that we changed a few things on the text file, the, so let me see what that was all about, and see if there’s a little bit
different formatting highlighting,” and of course there is. All the red highlighted lines
are the content that was removed during that edit and commit process, and the green is
the content that was added. Now if you’d prefer to see this
in a much nicer formatted way, especially for things
like .md, or markdown files, then what you can do is toggle back over
to this little view button here, and display the source diff, or show
the raw content of this document. Or, if it’s something that’s prose,
or written-form type text, that GitHub can kind of parse out, then we can also show it as rendered. And if I discard that highlight
there on the screen, you’ll see that, ah,
there’s a little bit better, a little bit easier way
of assessing what was going on. The green bars indicating
what was actually added. The red bars indicating
what was entirely removed, and of course this one,
that was slightly changed, you can see that it even indicates
what changed about that line. So that’s a nice little adjustment, a nice little way of assessing things, especially when it’s prose
or documentation around your project. But, typically, projects on
are all about the code. They’re of course going to have
some supplemental documents on markdown format,
or possibly even ASCII, but really what we are interested in
is developing software and web sites and projects
that we can share with others, or collaborate with our colleagues. So the next thing I want to do
is create one more file, and that’s just going
to be called styles.css, maybe make my web site
a little bit prettier, and maybe the body, I’ll add that, and font size of 14 pixels, and then maybe the H1s will be font size, and we’ll just do 200% so they’re
a little bit bigger, like so, and maybe the font weight
is going to be normal, just so we don’t have
too much boldness going on. So there’s just some basic style sheet
that I’m going to scaffold, and I’m going to just say,
“Add initial style elements” or even better, “selectors.” Commit that. And now we’re done. So now we have five commits in history, and we have a project that’s generally
built out, and structured, but maybe we want to bring this
onto our hard drive. Maybe we don’t want to use
just the web site to edit files one-by-one. We’d much prefer
maybe being more efficient by copying this to our hard drive, opening it in our favorite
text editor, or IDE, making some changes,
creating some commits, and then resynchronizing
those with our account. So in that case that’s what brings me
to the GitHub Desktop clients. Now, the great thing is, most recently,
the Windows and the Mac platform clients have been unified,
in terms of how they look. So I’m going to toggle over
to the GitHub for Mac client for a moment here,
and that’s what’s on screen. And you’ll notice… there’s nothing! Because what we’re having this client,
this desktop app look like, is for any repositories,
any Git version-controlled projects sitting on our hard drive, and right now I don’t have any. So if I go over here
and click on the plus sign, very similar to how the web site appears, I’m going to click on the little dropdown, and you’ll notice that we have now
two options from this popup: We can create a new project. Well, we don’t need to create
a new one just yet, because we already have one
on So if we were going to start locally,
and then ultimately decide to put in,
that’s the route we’d want to take, but rather, I want to clone,
or download a repository that already exists on my GitHub account, and copy it and download it
to my hard drive. Now you’ll notice that
this already indicates here’s my githubteacher account
that I have access to. I’m going to hide that for a moment, and also have a githubschool. That’s where the repository lives
that we’ve just created. And so we’re looking at the repositories that at this very moment
live on my GitHub account. If I scroll down far enough,
then I can find, there’s my
repository, I’m going to highlight it, and decide to clone
the repository down to my local drive. So I’m going to click on that,
and now I’ll get prompted– Where do I want to put this,
on my hard drive? Well in this case, I just have
a directory called Scratch, which is where I will have this client,
this app, save all the files. Clone. What’s happening now
is all of the history, those commits that we saw,
those five commits, and those four files that we’ve generated
only on the GitHub platform, now reside on my hard drive,
and I can review that history without even needing
to touch any of the files, by simply going to the History tab. Maybe just make sure that I know
I’m looking at the exact same thing. History tab shows…alright, there’s
Add initial style selectors That looks like something I just finished, and then the one prior to that was
changing the description to the body of the HTML,
the home page, and then adding the basic structure,
and updating the text file for the README,
and then the initial commit. So newest at top, oldest at bottom. But the reason I’m most
interested in using the client isn’t just to review what’s changed
in the history here, of things past, rather to make new changes, to start editing documents,
creating changes, and then version them locally, and then deciding when those
should go on the GitHub platform. So, first thing is I need
to get access to these files, and I told you that they sit
on my hard drive somewhere, and the easiest way to do that
is to just Control click, or right click on the name of the project,
right here in the GitHub app, and I can op–I can view it on GitHub! So that’ll open a web browser–
well I don’t need that, I already have it open in a web browser. I could open it in a Finder, and if
you really wanted to dive deep, and you knew how to use the Command line, you could even open this
immediately from the Terminal, but we’re going to leave that for later. I’m going to open in Finder, or my Explorer window,
if you’re on Windows, and then of course I can identify that–
Ah! here are my project files! They’re sitting on my hard drive! And I’m going to go up one level, and I’m going to open this up,
just in a text editor so I can make things nice and efficient
in terms of editing these documents. So I’m going to open this
in an app called And this is just a text editor that
GitHub has just recently open sourced. So here’s my editor, it could be
Sublime, it could be Text++, it could be any of your
favorite IDE to edit HTML. So here I am, looking at my documents, and I’ve decided there’s going to be
a few things that I need to take care of. One is that I need
to update my styles’ CSS. I need to edit my index.html,
and maybe even I need to add an additional page or two. So I’m just going
to go ahead and do that all, and then figure out how I need
to preserve those changes in a very nice, stepwise manner, by using Git commits to preserve
the history of each of those changes. So here, my first decision is–
well, I’ll open up the index.html, and I’ve decided that I need
to add a link to the style sheet, so I’m going to say–
rel=”stylesheet” like that, and–
href=”styles.css” And I think, if I close the tag,
that will do the trick. Alright, so there’s one step, edited my index.html’s so at least it’ll
have a style sheet imported to it, and then maybe I’m going to go in
and just get a little distracted, and I start editing my style file, with no relationship to why I would
[have then] edited the index. So keep in mind the one beautiful thing
about the Git technology is that we can edit many files at once, and then later decide
what pieces, or what files we want to actually preserve in history, at which point in time. So here I’m going to say, “maybe
the font decoration is underlying,” hopefully I got that right, and, “maybe the font size is going to be only 133% of the standard.” And again, this could be any text,
this could be any code, I’m just using HTML for this example. So I’ve saved that file, and then
I’m going to be really distracted here, I may go to the README file,
I’m going to say– Ah, you know what? Really don’t need
the objectives in this case, I’m just going to clean that file up–
I might regret that, but I’m going to save the file
with those changes, and I’m going to close it,
so Undo is not something that’s going to help me preserve
or recover the deleted lines. Oh no! So I’m going to close everything, and then I’m going to go back over
to my GitHub client. The moment I toggled back to the client, the Changes tab is going to indicate that something’s very different
about the project, that I have three files that have changes that have not yet
been preserved in Commit history. They’ve been saved,
those files have been modified, but they are not yet
preserved in history, and I definitely want
to review what’s changed– Well, let’s see,
I added a style sheet’s link, I changed some stuff in the README, I edited the styles–those don’t really make sense as one unified piece of work, so the first step I’m going to say is I’m going to unselect them. I don’t want to accidentally commit, or group any of these files together. I want to individually commit, these are maybe, in this case– Index just has
Add style sheet link, so this commit will only
contain the changes to the one file, checked. And commit. Next thing is I’ve decided–
Well, I don’t really care about that for a minute. I do care about
what was changed in styles.css, so I’ll make a commit for that as well– Add second level header styling, like so. And commit that. And then last, but not least, I have a
that’s missing…uh oh, quite a few lines of content, and I actually didn’t really
mean to delete those. If I right click on the file,
I can discard the changes. I can say, “Git, I haven’t preserved this, I haven’t actually saved these
changes in history with Git,” so with relationship to the last time
I committed these files maybe I want to just
throw them away and say– “That is my last opportunity
to undo or bring back any of these lines of content
that I didn’t necessarily want to lose.” Maybe it was an accident, I deleted the lines, saved the file
and closed it, and then totally forgot. If that’s the case,
this is a nice way of saying– “Git, help me restore the file. Yes, I want to move to the trash
any of those changes.” And now Git says, “Okay,
that file’s no longer modified.” And if I show you what that document
looks like in my editor, there’s the content, restored back
to the last time I had a commit. Now, if I wanted to, I could
synchronize these changes, and those would go immediately
back up to the GitHub platform. Now, the other thing I want to show you, because this is kind of
an interesting thing of what I’ve got my environment set up, is if I go to the GitHub menu,
or go to the Preferences, you’ll also notice that I have
my email address, and my configuration set up,
so that every time I make a commit I’m identified as a particular user. Now this isn’t your
user name or your password, but it’s a way that, if you’re
making local commits, you want to make sure
that this is something distinguishable, that matches who you are
on the GitHub platform as well. So when I’m on,
if I toggle over here, you’ll notice that
I’m logged in as githubteacher, and that any time I made any commits
on this project to the web interface, maybe at this commit, you’ll notice that it says, “Oh, this guy
named githubteacher made it,” and if I even click on that
to go one level deeper, it shows my email address
and my user handle, as known as GitHub Sample Teacher. And so, commonly, what you want to do
is have the exact same thing set up for your local client,
just so it makes sense. But that’s not mandatory,
it’s just highly recommended. Now, for any Windows folks,
I want to be fair, and toggle over to the Windows platform as well,
just in case that you say, “Wait, you said it looks
exactly the same.” So let me prove the fact
that it actually is. And so, in this case,
I’m on my Windows desktop, a totally different machine than my Mac, so this project doesn’t exist
with respect to this computer. So, again, I click on the plus sign. Looks exactly the same
as it it were in Mac. I can clone. I can choose my githubschool, because
that’s where that repository lives, scroll down and see that there’s
a repository. Clone that,
decide where it needs to go. In this case it should go in a folder
called GitHubTeacher. That gets cloned, or downloaded
to their local hard drive from the GitHub repository, and again this is still just me,
on different platforms. This is still githubteacher. And I can double check,
just like I did with the Mac app, just to double check
what my actual settings are. I wonder if…I look at Options, yes,
I’m logged in as githubteacher, and GitHub Sample Teacher
is the individual, and there’s my email address as well. So everything looks right,
at least it’ll all make sense in terms of the persona,
or the person making these changes. Now, similarly, if I wanted
to make changes here, I could Control click, or right click,
on the menu for that repository, open in an Explorer window, and I could start poking around
and editing files this way as well. But something else I want to bring up
is the concept of branching, because this brings us to the one
and most important way we collaborate on the GitHub platform, and that is that #1–everything that
we make changes on, within a repository,
even our own repositories, should always be contained within
something called a branch. It’s just a way of
containerizing our commits so that we know that there’s…
Oh!… a unit of work relating to documentation changes, a unit of work relating
to style sheet changes, a unit of work maybe relating
to the home page content. So, in this case, I’m going to create one
right here on the GitHub for Windows app. This is going to sit on my hard drive until I decide to synchronize it
with, and my account. And so maybe the first one I’m going
to create is just some home page tune-up. Nice and clear that there’s
going to be some tune-up, maybe some content edits and adjustments, to the home page file. So I’m going to hit Enter, and notice
that this wording up here has changed from master, or what
we treat as our default branch, to this topic branch. Now I can go back over to my Explorer
window, and start editing some files. So in this case I’m going
to edit this with Notepad++, and I’m going to say something like– that this doesn’t need to be
a GitHub web site, like so, but it also needs to be, just adding some content of some sort. So I’ll save that document. I’ll go over to the
GitHub for Windows app, and, immediately, it also detects
that there’s been a file changed within the perspective of this system,
that the title changed. I’m going to say–
Update title, add domain name and I’m going to commit that one change. That still sits just locally,
on my hard drive, until the moment that
I click this button, Publish. That is, take any local history,
any local commits, send it up to your account,
so that everyone else can see it as well. So once that publishing is complete, and I’ll give that just a moment, double check that everything’s in synch. There it is, uploading my history
that pertains only to this context of the home-page-tune-up branch. Go back over to the web browser, go to my repositories, maybe I find my repository
hiding somewhere in here, and it’s got to be here–
Oh no, of course! It’s under my organization
of githubschool. So, I can even see…
Oh! Here’s my newsfeed, that kind of gives me a quick– Aha! That’s what’s going on right now! I had forgotten that I had
synchronized my changes for the home-page-tune-up branch. Click on that.
(clicking sound) And I get dropped into
my repository again, so the newsfeed’s just a quick way
of seeing what’s in there, and what’s happening,
not just to one repository, but any repositories
that are within your account. Now, the moment that that branch, that container that
contextualizes our commits, there’s two things that’s happened. One, home-page-tune-up branch
now lives on the GitHub platform, so other individuals could see
what kind of commits, what kind of work is going on
within the scope of that branch, not just the default branch of master. And, additionally,
the GitHub platform has said– “Well, you have history, new history,
changes that you might want to compare,” and start what’s called a pull request, a way of raising the interest level
to other people that might want to help you peer review,
or code review your work, and comment on it, and then, ultimately, merge that into something
that goes into production. So I’m going to just click that nice,
easy-to-click green button there, it says Compare & pull request, and the first thing that happens is
it says, “Okay, I’m going to be comparing your work with relationship to the master or default branch,” the place where the production code lives, or the production web site, in this case. And I can put a little bit better
description message than what came through
my commit message, and maybe this is–
Adjust index.html aka home page And I could put an additional
description here, like– Just some home page content updates.
Looking for some –and I can use emoji– :eyes: from my team on how this looks and if it’s OK to merge. I’ll create the pull request,
but before I do, I can double check myself one last time, that the only commit
I’ve created right now is one, by myself, githubteacher,
with this commit message, that unique identifier,
and this one change to the title, so far. The moment I create the pull request, that’s simply the way we can
have a conversation with each other on a public repository. So maybe I send this link over,
I grab this from the URL, the address bar, and I send this over
to one of my colleagues, or someone that’s helping me out. Maybe I send them an email
or an instant message. So this guy named githubstudent
comes along, that I work with, and I said, “You know what?
It would be great if you could just peer review some of my changes here.” And so they open up this URL
that I shared with them, they see my pull request, and they see that I have one commit
and one file changed, within this conversation, and maybe
they have an idea that– “You know, it’d look better if maybe
I didn’t put the colon in there, or maybe if I improved the title, there.” So they could comment
line-by-line on the code, within the branch of home-page-tune-up, on any of the files involved so far. So right here, I’m going to comment
as this student individual, and say– Don’t like the –and I can put in a code block colon– “:” separating the title.
How about some different formatting? And comment on that line. The moment that’s happened,
and notification has been sent to the individual that started
this conversation, that’s githubteacher, and it says, “Hey, this other guy named
student has come along, and he commented on a line of your code, and he’s suggesting
something a little bit different.” And this isn’t just
the end of the road, here, that– Uh! We just have to abandon effort because this person
suggested something different, and this pull request is already
an outstanding or open ticket. Not in the least! If we still wanted to continue
working on this locally, I could go back to my desktop. I could be working on my Windows
machine, here, and say, “Okay, I’m going to take
that advice into account,” and I’m going to change that to a hyphen, and maybe even put
some additional text, like– Git Hub Training Organization Web Site and then I put a hyphen.
So I made some changes, I’ll save that, and so then
the conversation can continue– But, wait! No one else can see this, because this is just sittting
on my hard drive right now! So to keep things,
the momentum going, I say– “Alright, I’m going to make a change, Update title formatting, adjust text… title text is going to be my commit.” I’m going to make a commit again,
to this topic branch, and I’m going to synchronize this, which is even indicated by this
little up arrow, and the 1, saying, “You have one local commit that
needs to be on the GitHub platform if you want anyone else to see it.” Click the Sync button. The moment that completes, and I’ll
let that finish here, for a second, I will see that commit show up
on the pull request, the conversation that I was already having with this other individual,
this other teammate, and here’s my new commit. And the timeline being progressive,
it grows downward as the conversation
and the timeline expands, and I can see that a new commit exists, and if I take a look
at my page here, on the files, well, that looks very much different, that looks like the new changes I made. So, again, I’m toggling
between accounts here, to demonstrate
the collaboration workflow here, in terms of conversation and code review. And so now this individual,
this githubstudent, can come along, and say something
one last time that says– This looks great! I like the “-” instead of the “:”.
Let’s –and then we can put
some new emoji, like– :ship” this right now! And comment. So there the conversation is almost done, but this githubstudent
does not have permissions to actually approve
or merge these changes in. So, as much as they can say,
“This looks great! This is fantastic!” They can even have a part
in this conversation. They can even put in animated gifs or screenshots,
if they wanted, and comment on that,
just to give everyone a total approval of this work. So now this githubteacher,
the owner of the project, that kind of curates the content,
and kind of manages the conversation, comes along and said,
“Okay, you know what? My colleagues here are saying Yes!” This needs to be merged, this needs
to be in part of the default branch, the thing that will go into production. So we’ll click Merge pull request, and say that the commit
message is going to be– Update home page title and formatting That’s a much better description. And confirm that merge. We can now delete the branch,
because we no longer need the context of this work in progress, it’s finished. We have two commits,
we had a conversation about it, and that doesn’t need
to kind of crowd our branches for any upcoming work
that might be related. We’ll get rid of this one,
move it out of the picture. So we’ll delete the branch, that doesn’t mean we lose the work, it simply means that
we’re deleting the labeler, that description of home-page-tune-up, with relationship to the commits
made in this conversation. If I go back over to
my root of my project, the, you’ll see that, alright,
this all looks the same. Wait, let me check out
this line right here. index.html’s last commit
was three minutes ago, and it updated the title formatting,
and adjusted the text. If I click on that, I can see that
that very much looks like the changes we had, over
the course of the conversation with my friend githubstudent. And, of course, here’s the finale
for how this entire process works… If I open a new tab, and I go to we’ll see that, because of
the naming of this repository, and the fact that this was
a web site centric repository, it had index.html and some style sheets, that this web site automatically
gets deployed on the GitHub servers. So it’s kind of a cool side effect. Now there’s many ways that
you can try the GitHub pages, and if you want to learn more about that,
you can go to, to discover how, in addition to projects, whatever language and software
you develop and you host on GitHub, and you keep within repositories,
that they can also possess this supplemental
GitHub Pages web site, that’s a nice way of exposing the project
in a much friendlier, much flashier way. And a few examples of that would be, for example, that has a very well curated web site, that represents what
their open source projects are, and this is all hosted
on in this case. So those are just a few of the cool things
that you can do with repositories, in addition to just keeping code, and versioning the history
of your changes. So, going back to this tab,
I have this repository that just happens to be a web site, that just happens to be autodeployed, and happens to be hosted by But what we’ve also learned is that
we have now generated history that anyone else on the world wide web, you could go to the this URL
up in the top of the screen, and you could visit this very same repo. And the last thing that you might hear, that fits perfectly with the last
four minutes here of class, is that this was a very
one-sided conversation, in terms of how
this change got integrated. Anyone could have
commented and participated in the discussion of that pull request,
and the comparison of code, but only I, the githubteacher, had permission to actually change it. Well the open-source model
of allowing others to collaborate and contribute to it is what’s called the forking pattern. So if I go back over to my web browser,
representing my githubstudent, and I take a look, that githubschool, this organization
that possesses this repository, won’t allow me to create new files,
or edit the files directly, they don’t have that level
of trust established just yet. But what you’ll notice here is,
when I hover over the plus sign, there’s a message that says–
Fork this project and create a new file If I were to even go in
and try to edit one of the files, it will also say–Well, you’ll get
an automatically created fork for you. A fork is effectively just
a photocopy of this repository that gets dropped into your own account. So if githubschool, this organization, is the only owner
of this web site repository, but it’s a public-accessible repository, then the githubstudent, that
has no permissions, typically, can create a photocopy
by clicking the Fork button, and letting that copy reside
within their account. And of course this would then
show up within their account, whether they’re logged in with
the GitHub for Windows or Mac client, or even if you’re just
using the web interface. So now we notice that we have the
githubstudent / repository, that was actually forked
from githubschool originally, the canonical repo. And so now we can make any changes. Hover over the plus sign,
well we can create a new file. Hover over one of these files,
like index, and click Edit– It will let us make that change. But it’s important to know
that we also advocate that you follow the same strategy in how the contribution
guidelines kind of work out, and that is you always keep
your commits within the context of a branch pertaining to
that scope of work. So if I decide that, at this very moment,
I’m going to add an About page, maybe about-page-skeleton
is going to be this one, and I’m going to create that branch,
and then I decide– Oh! I’m in the index.html,
that’s not the right place! Let me go back to
the root of this repository, create a new page called about.html, and I’ll keep it nice and simple
for the end of the class here, and just say–
About Us – GitHub School Scroll down–
Add basic about us page content and commit that. That commit now lives in a branch– Oops! On master, silly me! I didn’t create a branch
and switch to it correctly, let me fix that real quick,
let me click on the correct branch, and create the file in the right place. So then this would be about.html,
and the beauty of that is even though I kind of
made a mistake there, I can use Git to undo that. Now that’s beyond the scope
of today’s course, but it’s very easy to extract
or unwind any mistakes that we even introduce
by means of commits. I’m going to just say that this is
the about us page one more time, but this time I’m going to–
Add about us basic page to the right branch, this commit will only live within
the about-page-skeleton branch. Now I’m going to create a pull request, and there’s two ways I could do that. I could go to the pull request
page or, more simply, I could just click on this green button
right next to my branch, on my fork. Clicking on that will say,
“You’re about to submit to the original owners of this project,
that is githubschool, your changes within your branch
about-page-skeleton.” And you’re like, “Alright, that’s fine,
I’m going to submit these, and open a conversation up
that I’ve made changes to my copy of the repository, my fork, and that maybe the owner of the repository would be interested
in incorporating that work.” So I’m going to say–
Add about page is going to be the basic title
of that pull request, create that pull request, and you’ll notice that we’re redirected
to a page that is the githubschool, the original owner of
the project, their repository, and the conversation
has now been kicked off, in terms of what commits I’m offering that are being derived from my account, githubstudent, to githubschool’s master branch. So then, the last thing is that this teacher,
the owner of this project, comes over to the pull request,
sees that the community is willing to help them out
by means of this forking model, checks out one of the pull requests,
which happens to be this one, and they’re going to say
one thing, and that is– We’re missing all the HTML tags. Add those and then
I’ll merge and :ship: it Comment on that line. So, again, going back
to the code review process, now it doesn’t need to be HTML,
it could be Java, it could be CSS, it could be Ruby, it could even
just be Prose, to begin with. But the conversation
has now been kicked off, and since the student is the one
that opened the pull request, they’ll have been notified,
either through the web page, notifications center
of, or by email, that the teacher has said something about them needing to finish up
a little bit before they merge it in. So, lastly, I’m going
to use the web interface, say that the teacher says to the student, “Tune your file up just the slightest bit, and you’ll be fine,
and I’ll approve your changes.” So the student looks at their pull request
against the canonical repository, says, “Alright, that’s fine.” Let me edit this document,
so I’ll click this. It detects that I want to edit the copy
of the file within my fork. And so, here, I’m just going
to cut that text out real quick, put some HTML, put some head tags, I’m even going to put a body, and I’m just going
to drop in the text, and say– Add proper HTML tag structure and commit this. Now, as long as the pull request is open, any time I make a commit
against the branch that that pull request is pointing to, that pull request will immediately
reflect those changes. So we’ll see, the moment
I made that commit, an additional commit showed up, the conversation shows that
there was my original commit, the teacher’s comment on an outdated diff, in other words, the change
to the file has affected it so much that we now just need to look at the file as it currently stands,
it’s a lot different. Conversation is that I can just
put in something with, maybe, another animated gif, because I love
being able to drag those in, and say– All HTML tags added as requested. Looking forward to seeing this go live. And then Comment. And, of course, who wouldn’t want
to merge this pull request and approve those code changes,
with an animated gif like that? So now, the teacher gets
one last notification, and says, “Alright, I can’t help myself. I definitely want to
incorporate these changes, but I’ll make sure of it,
I’ll take a look, refresh the page, just to make sure
the file looks right. Yep, that’s exactly what I wanted.” Conversation is finished. I’ll give them a +1, to make sure that
they know the conversation is approved, the changes are all right,
merge that pull request, confirm it, and now if I go back
to the githubschool’s repository, the About page is now introduced, there’s 11 commits in
the history of this repository, and, if I click on that, we’ll also notice something else very beautiful
about the Git technology. Despite the fact that the teacher
had to approve the changes, and gets credit for
incorporating those changes, the GitHub student
who authored the changes and the content of the About page, or whatever was involved in their commits, also gets attribution, in terms of
what they’ve contributed to the repository. So, to double check ourselves,
I could even do something like go back over to the web browser,
to show you that that autodeployed, hit about.html, and there’s my
very, very basic About us page. So that is a very quick,
but very thorough tour of just the basic workflows,
of creating repositories, authoring content, editing content
on the web interface, bringing the repositories down
with the GitHub for Mac or GitHub for Windows desktop clients, cloning it to our hard drive,
editing content, making commits, synchronizing those commits, putting them back up
on our GitHub account, creating a fork, opening pull requests, contributing those to
a canonical repository that’s curated by a particular owner, having a conversation about those changes, and then getting those changes vetted, and, ultimately, merged into
a default branch or production branch like master, on the repository
we’ve been working with. So I hope you’ve enjoyed this. It’s been a crazy, quick tour. I love giving demonstrations like this. I’m going to drop back over
to our slide deck for one second, and if you have any questions, always email us,
or visit We have plenty of resources and links. But the other thing
I wanted to point out is, in addition to just the Training web site, which has a training kit, and resources
for learning Git and GitHub, that if you haven’t already installed it, and maybe you already have
since we’ve been using this, that is the place
to go to download the desktop client for Mac. And also have your command line all ready, because your Mac
will already have Git installed. And if you go to, you’ll also have an installer that allows you to install the client
for your Windows platform, and also enables you to use Git
on the command line. Lastly, if you have any questions, We are following this class
in just four short minutes, on the course’s page,
if I scroll down just far enough, that in addition to the free class,
which we just participated in, I’m also hosting an office hour. That’s open, I can throw you on audio,
or take your questions in written form, and we do live question and answers,
and live demonstrations. So with that,
I’m going to close this down, and if you have questions,
always follow up, but thank you so much for joining,
really appreciate it, I’m going to throw one poll on screen, if you can give me a quick click,
that would be awesome. Hope to see you in the office hour here
in three or four minutes, and if not, have a great rest of the day. Happy committing!,
and enjoy using! Thanks!

Robin Kshlerin



  1. patrickm02L Posted on July 27, 2014 at 5:45 am

    Hi, this video is the Rosetta Stone I've been searching for. I've spent months trying to figure out how to start on GitHub, to integrate the apps and how to submit pull requests. I watched it through once, and then watched it through a second time mirroring the instructions on the video. Everything makes so much sense now, and I've just submitted my first commits. Thank you so much!!!

  2. Matthew Rath Posted on September 11, 2014 at 5:15 am

    For anyone watching you could also try bitbucket if you want free "private" repo's.

  3. Yury Gitman Posted on May 14, 2015 at 4:02 pm

    Don't know why it took me so long to find this video, but it's super helpful. Thanks!

  4. Susan Winters Posted on November 28, 2015 at 8:05 pm

    Excellent training for GitHub. Wish I'd found this video a couple of years ago!

  5. Keith Watt Posted on February 5, 2016 at 1:28 am

    This was awesome, thank you!