[github SOCIAL CODING]
[THE BASICS OF GIT AND GITHUB and "what's new" on GitHub]
Git tooling, techniques, and the GitHub platform
[github SOCIAL CODING]
Thank you very much for joining this morning! I'm Matthew Mccullough
and I have Brent Beer with me here in the background offering tons of advice,
inputs and questions as we go through these materials but I hope
that you really enjoy this power-packed 40 or 45 minutes of materials
in which I'm going to demonstrate
and showcase a lot of things that to me makes Git and GitHub
just such a useful tool.
I am a developer by trade, having worked in the Java Platform and Objective-C and C
and MFC and COM and DCOM and just all these sort of things
over the last 15 years,
and I'd say from my own experience as a developer, not just a teacher, this is
one of the most amazing transformations for me, of any materials that I have
ever, ever had the privilege to work with. And I'd like to showcase exactly what
I mean by that through lots of demonstrations
and very little philosophical talking.
Brent and I are able to be reached after this class by these addresses
that you see on your screen.
GITHUBTRAINING is our Twitter handle, you can @tweet us with something small there.
TRAINING@GITHUB.COM is our email address where you can inquire about the other
types of classes that we teach.
TRAINING.GITHUB.COM is our website where we have linked to all of the free classes
that we offer, we have some other ones forthcoming and Brent is going to teach
our next one in December.
GITHUBTRAINING is our GitHubhandle and we have some sample practice repos
and other materials sitting beneath that username @GitHub.com.
I'll keep it very brief about the two of us
because I want to get into the materials
and what you should be seeing now is a short overview of my background.
I'm passionate about Git and GitHub. I've been teaching Git for about
5 years now which is practically longer than GitHub has existed so this is
something that is extremely important to me and I'm delighted that I have the
employment opportunity to work with Git and GitHub daily
and teach it to people as an actual job.
My colleague who is in the background answering your chat questions
in the Q&A window is Brent Beer and he is a recent addition to helping out
the training team with our classes and it is absolutely a delight to have his help.
He is an expert at Git, don't let him be too modest with you.
Ask anything in the background and he will absolutely be able to answer that for you
or queue up an answer for office hours.
But our topics that we're here for today are Git and GitHub and I want to waste
no time in getting to the core of these. We're actually going to be mentioning
two discrete topics today and that is both Git, [git]
and then Git combined with GitHub,
so kind of a sandwich in the middle and then GitHub on its own as
a web service that sits atop a collaboration model
of working with software.
Now these pieces that we're talking about, this Git, GitHub sandwich and then GitHub
actually all play to developing software but the road map
that I'd like to establish for us of the material that we'll cover
in these next 40 minutes or so,
is "Why you'd even choose this tool and where it's come from?",
a little bit of the setup, to show you that it is very approachable,
it's very, very easy to get started with this,
and a little bit of a recipe on how to use this,
your first steps in getting started with the repository,
and then a first couple of steps and recipe for using GitHub.
So, let's dive right in.
Why would you even choose this, and why would you switch
to a different version control system?
It is a very valid question and in fact when I'm giving talks at conferences,
I ask people and challenge them: Don't take my word for switching
to any tool, nor anyone else's who's presenting, question it and ask
why would you waste, or spend, or invest the time in learning a new tool?
If you're already using Save CVS, Perforce, ClearCase,
or Subversion today, this is an investment
that you're going to have to toggle over to this new way of thinking.
Now, when you think about switching,
there's actually someone who's paved this road for you.
The Linux Development World was using BitKeeper,
a commercial version control system and that licence was taken back from them.
Strange enough that they were using a commercial tool,
but when that license to BitKeeper was removed,
unlike many of us who would say, "Well, what else is out there?"
"What could I use?"
"What else could I switch to?"
Instead, given that Linus Torvalds is at the helm of the Linux kernel
and its development, he instead said: "I'm going to invent my own."
That's a pretty interesting response and a pretty bold one at that.
But he succeeded.
By many people's measures and the millions of people that are using Git today.
It is the next step in terms of version control.
It adds all of the attributes of distributed version control systems,
which means that it works in both "on" machine kind of idea
as well as in the collaborative model that we've thought of,
of having a centralized repo that's accessible over the network.
It serves both modes extremely well.
Now I'll actually speak very politely of all these other version control systems
that I've used in the past.
I've generally had a pretty good experience with Perforce and Subversion,
ClearCase, CVS, PVCS; these things that I have used
in my software development career,
but I'm still very open minded to switching to something new,
if it has a lot of new benefits, features, performance, speed and matching
with the software development models of today.
Git is one of the version control systems that's been developed in the Internet Era.
And by that I mean it works extremely well with high-latency networks
and sometimes even well with ones that have very constrained bandwidth.
Which you say, "Maybe that's strange."
We're in the era of T1 lines and DSL to everybody's home but at the same time,
that's not the mode that we always work in.
Sometimes tethered over poor Wi-Fi, spotty connections, maybe even tethered
to your mobile device.
So I want a tool that's going to work efficiently even
in resource constrained environments.
By that, I mean that it has a very small footprint, both on-disk
and in-memory.
I'll show you that actually first-hand.
And I'd also state that it's simple.
People have a very argumentative state, or mode, of responding to me saying
that this is a simple tool.
But what I think they mistake, just like let's say, the world of cooking,
or any particular sport, is that it's simple to get started,
but there is a massive battery
of materials that you can learn.
In fact, five years in, this being my primary job,
there are still little things I learn about Git, each and every month.
So, we'll start with the basics and you'll believe that it is indeed simple,
but you'll also say "Oh, my goodness", there is a wealth of features
and skills and tools that can fit into this, that I can learn
over the next couple of months and years.
The last little piece actually comes from its Unix and Linux roots.
That is, that these small programs are composable. Git is actually built
of some very, very small programs that work cohesively together to create
the appearance of a suite of tools.
This means that since the little pieces are still exposed to you,
if you're a person who likes to build up new ways of using tools, new recipes,
new order and sequence of instructions, you can compose these with a Batch script,
a Bash script, a Z Shell script, a PowerShell script,
these would all be ways to write your own new Git instructions.
Now, with that little intro as to why we're using this,
I'll immediately point over to Setting Up Git,
because I would love it if the hour
after this class was you just getting this all working and running your first few
practice repositories and I'm going to give you everything you need
to make that possible.
Setting up Git is really just running an installer but even more raw than that,
you could actually just copy and paste the binaries
onto your path environment variable.
I'm serious. It doesn't necessarily need registry entries or some invasive,
putting itself into the key store, you could literally just work
in a portable mode with the binaries being on your path,
no administrative privileges required.
Now the installers make it pleasant and there's an easy enough place
to get the help to do that.
We have a page that we all at GitHub maintain that shows you how to actually
set up Git for each of those platforms and you can find that right at the top
of help.github.com.
The reason that I point out to that, is we're constantly updating it,
maintaining it for the new dot releases and the little differences that
come up for the newest versions of Windows and Mac OS and Linux.
So that's your homepage for getting the step by step and screenshot by screenshot
set of instructions for setting this tool up.
Now I've actually got this already set up on my machine,
I've used one of the installers to accomplish that, but I want to show
very, very early over in my terminal window, clearing off this terminal screen
right over here.
And typing git --version to show you that I'm at version 1.8.0.
I'll emphasize again that while part of my demonstration today is going to be
in Mac and part of my demonstration is going to be on a live running version
of Windows, this actually serves the Star, nix, Linux, Unix community
very, very well.
That's its home, that's its roots, that's where the copies of the new versions are
first published and then quickly thereafter, sometimes hours,
sometimes days after, the Mac and the Windows versions
emerge from that core Linux distribution.
So there's my test: I have Git up and running but you ask,
"What could be next after that?"
Well, we have to use it next and literally I mean that's
all there is to actually getting Git running,
running the installer, going to your command prompt
and then firing it up.
Now many of you may already be asking,
"hmm... GUIs... you know, I'm going to prefer to use this
inside Eclipse or Visual Studio or a standalone IDE and I'll show you
some of those options as we proceed through this webinar,
but I want to start by again emphasizing that this is a command line tool.
Now that is not to say at the detriment to any of the GUIs
but it is absolutely a command line tool from a scriptability standpoint
and that's important.
As you work more towards a continuous integration and continuous delivery model
of shipping your software, you will appreciate that the command line
is a first-class citizen, not some sort of after-thought that has a horrible API.
It's the core of Git and the user interface is simply
leveraged that command line interface and in general are very consistent
because the power of the tool starts from the command line itself.
Now we need to create a Git repository, to do something actually useful with this,
and this is an absolute inversion of the usual way of thinking about
version control, because if you have a small project, let's say the little ones
that I start up all the time, maybe a little series of class notes,
maybe a small book or pamphlet that I'm writing.
Maybe an article for a magazine, maybe even some documentation
for a software project, the model of yesteryear
for me was to send some sort of ticket
in a ticket tracking system and ask a privileged administrator
to create that repository, but in this case, I'm going to create
this repository locally and then find a place
to put it on the network.
Whether inside our company firewall or perhaps even on a public service
like GitHub.com, after the fact.
I can switch the direction of this creation and then later publishing
and it will preserve all of the history that I create locally when I later
push it to the network for the very first time.
Let's head back to our command prompts and here we are sitting again
after having typed git --version, and we'll clear off our screen once again.
We're going to type a few instructions here
and the first one that I want to do is
git init and I'm going to call this project1.
When I've typed git init project1, I have done something pretty impressive
which is to instantaneously create a local repository
but with no server
or any daemon running in the background,
there's nothing in the background.
It simply used the file system to create a top level directory called project1
and then a nested folder beneath it called .git.
Now I'm going to see the end to that project and I'm going to show you
that by default dot folders on star-nix systems are hidden,
they're kind of considered a control structure
but that's no reason for us to hold back on peering
inside what's in .git.
Now, you might think for an introductory class, you'd say
"Would you ever poke inside the control structures
of a version control system?"
But I encourage you to do so because they are quite user serviceable.
I'm going to pipe this through more to show you this contents here.
It's a small set, wow, I didn't even have to run off the end of my screen.
I have .git, a folder with some files in it
called head, config, description,
a series of files that are called hooks.
Those are life cycle management instructions that I can hook into
with Ruby, Pearl, Python, I can even hook into with Groovy
or Shell Scripts or Batch files and have it do special behaviors
at the time that I write commits or update my repo.
I then have a series of directories: info, objects and refs,
and those are where the actual data for the commits,
the version controlled, time-stamped copies of the repository are to be stored.
So VES is a control structure, I'll already emphasize
if you've come from CVS, or say Subversion,
that there is one and only one .git folder per repository
and it is at the top level of the project.
It does not repeat .git directories down all of your other folders and in fact,
if you ever wanted to ungit version, a certain directory or project,
just delete the .git folder.
That's it.
There's nothing more, there's no other tendrils, that's it.
So for the moment, here at our Mac OS terminal,
but these instructions being consistent
across any prompt that you type, git init has created a repository.
But clearing off my screen, I don't have any files as of yet.
In fact, typing git status
will let me see that I'm at the initial commit on a default branch
that is called master.
I have nothing to commit at this point because there's no files in here yet.
So let's remedy that.
Let's open up a text editor, let's open up our text mate editor, in my case,
or any text editor that you like against a file that I call first.txt
and I'm going to bring this onto your screen here
in just a moment, we're going to drag this on
as a visual text editor right over here, and I'm going to put in
some Lorem Impsum text into this file.
So file and save and I've written out this text and now what next?
Well, we'll ask Git what it thinks about the status
of this current directory.
first.txt is an untracked file and that's the important word
that you should be focusing on right here.
Git tracks content.
Each time that you type git status or you refresh one of the GUIs,
it is in fact examining the current working directory
and all of the directories beneath it
to see if any files have either been modified
or have appeared that ithas never seen before.
That's exactly the case for this first.txt and it means that we can now git add
this file to version control.
But adding this file to version control is still yet a surprise and a difference
from the way that you work with version control today because adding it is merely
indicating that we want it to participate in the next transactional change set.
git add is a suggestion to have this participate,
it's not yet a permanent record of that file.
We finish that off with a git status to check that it has now transitioned
to be a changes to be committed.
The file's color has even changed for consoles that support that.
I'll then take the next step of writing git commit
and I'm going to supply my commit message right here on the command line
and call it "My first commit",
a very, very simple commit message,
I would usually be a bit more verbose but sufficient nonetheless.
It says that I've made a commit to the master branch.
I'll highlight each of these elements for you.
It is the root commit, it has this globally unique identifier
and to be precise, it's the first seven characters
of that globally unique identifier and it is my first commit as the commit message
I changed one file, had nine lines of text and the U-mask, if that terminology
is familiar to you from manipulating files on a Unix files system before,
has 644 as the U-Mask. That means the user can read and write it
and the other end group can just read it, and that's the default creation of a file.
So this file is now a permanent part of version control
and git status would further report that I have nothing to commit;
the working directory is clean.
I emphasize again that nothing is running in the background, so when I type
"git status", it examines the entire file system of this project1 folder
and everything beneath it.
The same goes for when I type git add and choose a file, and the same goes
for what's in this staging area or shopping cart when I type "git commit".
It's taking the previously added items, the ones that I've already chosen
and making those a permanent and committed transaction.
That's pretty good from the command line, but you're now probably yearning to see
some sort of graphical user interface on top of this, and I can happily
do that for you.
I'm going to go over to GitHub for Mac, which is one of our GUIs,
and I'm going to add a new local repository
and point it over at my Scratch directory,
so let's go over to my Scratch folder here for just a second
and browse right into project1
and add this as a repository that it's paying attention to.
What you see now is that I have some uncommitted changes, no actually,
none whatsoever, zero files, zero additions, and zero deletions.
But could I look back at any of the history?
Why of course.
On the top left side, I see my first commit.
What I can emphasize here is that there is absolute symmetry
because everything is committed to disk in the .git folder from GUIs
to the command line.
You don't really have to press refresh or have it reload the database:
everything about the Git repository is stored in that single .git folder.
GUIs writing to the same thing, command lines writing to the same thing,
mix and match as you choose.
Open up Eclipse, go over to the command line,
command line over to GitHub for Mac or in a minute, even GitHub for Windows,
I'll show you how we blend all three.
Now we've seen a basic introduction of using Git at the command line
but you must feel that there is just an ocean more to learn
and you'd be correct,
and what I very delightfully can point you at
is that there is a free book to guide you through
probably about a couple months worth of study
if you actually wanted to put that much effort
into knowing all the intimate details of this version control system.
It's pretty fun when you can point at a high quality free book
and this one is written by my colleague Scott Chacon at GitHub.
I've got all of these reference materials linked up after the webinar
in a url that I'll put back into the chat room again.
I did so right before the webinar started and I'll do so at the closeout
of the webinar again, but git-scm.com/book
is a really well-written introduction
to this version control system.
Additionally if you get so energized about this stuff that you'd like to look
through other class notes that we've taken,
little step by step instructions, kind of a quick welcome,
some videos that we've put together on learning these same things,
that is actually all housed over at teach.github.com.
So if you are already wondering, well, this is maybe pretty good, Matthew,
but I sure wish there was something that I could view offline
or take a book in ePub or mobi form and throw it on a Kindle or an iPad
or something like that, well, we've got you covered
in all of those places and in fact, even these online videos
that you can load up and watch and get the basics
of GitHub mastered as well.
Now, we need to do something on the GitHbub side, it's about time,
but it's intentional that I left it this long
before we actually involve the network whatsoever.
You have completely been able to isolate your thinking to the local disk
and to the local machine, creating a repository,
looking at its contents and then adding some new materials to it
and looking at it with a GUI,
and perhaps adding changes from that but what about getting it
to your colleagues?
We haven't really covered that at all.
But the nice part is, it is so simple and so easy to layer this
on top of what I've already shown you.
I'm going to go over to Firefox and Chrome as two browsers
and I'll show you why I want to layer each of these two onto your screen.
Now I have Firefox in the upper left hand corner,
and in this bottom right hand corner that I just dragged onto the screen,
I have Chrome.
Why am I opening up two browsers, and why am I showing it to you in this way?
Well in the top left, I'm signed in as a GitHub trainer,
and in the bottom right, I'm signed in as a GitHub student
and what this will allow me to do is to show you a real world use case
of where I'm manipulating two different repositories.
One is kind of the boss or the owner or the manager,
the director or the senior engineer, and then in the bottom right,
acting as a student, for, how would you join us?
How would you help out with one of these projects?
How would you collaborate?
How, if you found an open-source project up on GitHub would you be able to offer
your contributions to this project?
Well that's exactly what I intend to show you
because open-source really is a collaborative effort
and it needs your help.
So what I'm going to do, is I'm going to go
through the motions of choosing a repository
that this trainer owns on the upper left, hellogitworld,
and on the bottom right, a project that you might want to join,
that you might want to collaborate and add yourself into.
And what I'm going to do prior to this, and that's what I'm ultimately getting to
in about five minutes, is to show you how to preserve that work,
to close out our thinking, to preserve the work of project1,
so two different modes that I intend to showcase:
one, preserving the project that we already worked on
and two, showing you how to collaborate on a project that already exists.
Let's set our attention to publishing this project1 first.
First and foremost, it has no knowledge of any network destination yet
so let's, as a student, go over here to our GitHub
student Chrome browser and click Create a New Repository
in this top right corner of a free account at github.com.
It says, "What would you like to call this?"
And I'm just going to say very lazily, I'm going to call it project1,
seems good to me.
The checkbox indicates that that name is available
and I'm going to make it a public repo so everybody here in class
could potentially see this.
I'm actually going to ask you to participate here
in the next couple of minutes and I'm going to create this repository
completely empty.
You'll in fact find that there's some instructions down here
but the critical one is the second set of steps
that says "How do you push?",
"How do you transmit or preserve what we've done locally
on our command line up to the centralized repository?"
Well, it says copy and paste these two instructions
and head back over to your command line and paste these two instructions
while in that git repository.
It added a remote, which can be thought of
as just registering a bookmark for that long address that represents
the GitHub destination, and then it pushes,
which is Git's verb for transmitting the contents of the local repository
to some other place over the wire.
I'm going to type in my username...
and my password...
and that repository has now been transmitted
and you in fact see that it says a new branch, master to master,
that's been transmitted, and in fact, it is so quick that if I simply refresh
the view over here, you see our first .txt
showing up in the browser.
Now what's also important to note, is that it says that it was authored
nine minutes ago, but what?, I just pushed the contents of that repo.
It preserves and maintains the time stamp and the order and the people
and usernames of the work that had been done on your local disk
when you push.
You can think of it almost as just synchronizing, it's already captured
all the data for the commits, the transactions, the changes to code,
the who did it and when, and when you push,
it simply is synchronizing those local activities
up to a central repository.
All right, we can kind of clear our heads for just a moment of preserving
our project1, let's change modes. Let's talk about working on joining
and participating in a project that already exists.
hellogitworld needs our help.
So someone emails an address to us and said, "GitHub student, could you help out
potentially with this hellogitworld project?"
And I say, well sure, of course, but I have a little bit of a problem.
You haven't given me any privileged access to work on this repo just yet.
I see that I have read-only access to this repo.
Hmm... So what do I do?
Do I ask for authorized credentials to be able to change this?
No, I don't.
In fact, on many open-source projects, it's upside down.
You simply begin helping and then later ask for the privilege
for your code to be folded in once you've completed it
or at least made a meaningful enough contribution
to start to ask for inputs or code review.
So as the student, I'm on this global repository
and I'm going to click Fork, which allows me to make a copy of it
to my personal name space.
I'm getting a full photocopy of the repository to my personal account.
Now many people of 10 years ago would call this extremely rude.
"Oh my goodness, he has now taken a personal copy and he's going to do
whatever he wants with it, which means that none of the value
that the student creates is ever going to go back to the central repository."
Well that's not true, because as soon as we start
making changes to this, I am going to offer them back to the core project.
I'm going to grab this address, copy this to my clipboard right here
and I'm going to return to the command prompt,
wearing my GitHub student hat.
I'm going to step back out of project1 because we have put that one behind us,
having preserved it to github.com and I'm going to type git clone
and supply this address.
It is going to assume by default that I want to call this on my local disk
"hellogitworld" as the folder. You can in fact see that when I list
the directory right here and as I change over to hellogitworld
like I did right like so with the CD, I can now ask questions
of this repository.
It is a full-fledged repo with all of the history
and all of the branches brought to my local disk.
I can actually show you this by doing a git branch -a,
show me all the branch names and there you see
I've brought over dosug features, and a bisect feature,
an image that I've done on the Web, subtraction features,
all this work in progress on this project has been pulled to my local machine.
Unless I emphasize it, I'm referring to local instructions.
So let's start ourselves a new branch.
Let's call this new branch a novclassfeature,
a nice little descriptive name.
And then let's proceed to checkout, that is the instruction for toggling
to a branch. Let's checkout to the novclassfeature branch.
That switches the entire contents of my local directory, to represent,
to be and to have the state of the novclassfeature branch.
But at this point, the perceptive ones amongst you have realized,
there's zero difference between the master branch
that I was on by default and this newly created branch.
There's nothing whatsoever that yet differs between these two.
Now I'm going to for just a second, take this window
and no longer make it full screen.
I'm going to slide it over here, to the left hand side of the screen
and I'm going to open up another finder window that I'm going to get ready for you
in the second pane that I'm working with right now.
I'm going to get my way over to the same Scratch directory, I'm going to browse it
with the finder view, just a second, and you're going to ask me,
"Well, why would you want to show me this?"
Well, you're going to see, as I'm drilled into this hellogitworld 1,
and as I put it onto your screen like so, that when I create a new file,
you're seeing this. Let me minimize some of these other windows
so as to reduce noise in the background so we don't have to have
these other applications at all participating in any confusion,
there we go, a nice little reduction.
So what we have is a view over to this file system right over here
and everything else kind of shrunken out of the way.
I'm going to create a file while on the novclassfeature branch.
Watch this.
I'm going to just take a text editor once again
and create abrandnewfileonthebranch.txt,
I know, I'm being a bit silly about the file name,
but that'll work and I'll put a little of html into here
just to pseudo represent that I'm writing code.
I'll save and close that txt file that I've just created there
and here you see it, in this finder view on the right hand side, zero surprises,
zero surprises whatsoever, here I have it,
on this finder view on the right hand side of my screen.
Now I'm going to pull this up a little higher so you can see
the other files that are participating and I'm going to ask it what it thinks
about first data's perspective.
I'm then going to git add this brand new file,
I've put it into version control, and you've already seen these recipes,.
These are the same instructions that I ran when I was using
the version control system in purely a local thought process.
git commit -m and I'll say "A new branch file".
I've now saved that to disk but it's not yet on the network,
it's not yet up on github.com and you may recall
that the verb I said allowed us to interact with the network was "push".
We're about to use it but I'm going to git push -u,
deciding to publish for the very first time, this new branch.
These new branches like novclassfeature are an opt-in process.
I'm going to type my credentials, githubstudent and my password,
and that branch is now published up on GitHub, but why opt in?
The idea is to create branches for just about any small thing
that you'd want to do.
Whether that'd be a bug fix, whether that'd be
a long-lived feature branch, but I hope not too long-lived
and then to contain this work, to be able to have some code review
and discussion on it.
That's what you're going to see next.
I'm going to do one more thing now, before I leave this command line
and that is to git checkout the master branch.
Now, as I do so, I would like to call your attention
to that right hand side of the screen. Please look at that finder view
and watch the file disappear.
You just saw that file, abrandnewfileonthebranch.txt
disappear from the file system and I believe this is very helpful
in getting the mental model and picture of the fact that when you checkout
a branch in git, it is updating the file system
to reflect the state of that branch.
Adding files, deleting files, reverting them to an old state of code,
but when you checkout a branch, all of the files become up to date
with that exact branch that you have just checked out
whether that means deleting, adding or modifying files.
But I can equally return and git checkout that november branch just like so
and the file appears once again.
The .git control folder contains all of the branches
and can rehydrate them at any point in time.
I'm going to bring back Google Chrome over here and I'm going to refresh
this browser page and you will see that I have a new branch
that I've created, a novclassfeaturebranch
that is one, one commit ahead of everything else
that's been done in this project.
I'm going to go look at that branch, see what's been happening on it.
The most recent change, a new branch file.
Not much of a surprise there.
I think I'll offer this amazing new feature
that I've coded back up to the central project maintainer.
I'm going to click on the pull request button.
A pull request is a fundamental unit of work
on the GitHub side of things.
When I say GitHub side of things, I don't mean that we've written
a custom version of Git, I don't mean that there's any special protocols
or any special thing other than a very, very handsome UI
on top of the fundamental features of git, branches and merging.
This pull request is offering my student change
into the core project maintainer.
You can in fact see the arrow in the middle right here,
indicating the direction of travel for this suggested change
and many of you may now, or even after class,
challenge the use of the phrase, "pull request".
Why is it a pull request and not a push request?
Because this has, once again, inverted the permissions model.
I did not have to, as a student, ask for the rights
to contribute to the project.
I could make whatever change I wished but those changes are not folded in
to the official copy of the project until one of the core maintainers
or authorized engineers decides to bring them in.
I'll make a polite request in which I describe why this should be brought in.
[typing request]
So, what I've just done is, I've written out
a quick little description,
of course it could be a bit more technical,
as to what I'm offering to the core project maintainer.
Over here, on the commits tab, I can see which units of work
I'm offering in, and on the files changed I can see a summary of the code
that I'm suggesting the project adopt.
With the pull request, I'm going to send this in and queue it up
for the core project maintainer to potentially act on.
Now remember, I had the two hats that I was wearing:
a student, and then in the top left hand corner, a trainer.
I'm going to go to the list of pull requests and I see,
right over here, a new branch file and you know what,
I've already been trumped. I've got someone who is offering
110% better sparkles.
So let me look at this pull request from one of our students in class,
let me tell you this just delights me to see this happen in class
and I'm going to look through this, I'm going to see a new branch file.
I see that there's one commit, Lipsum, absolutely, I cannot avoid taking Latin.
So I'm going to merge this pull request and fold it in to the core of the project.
What have we just done?
We have done something ridiculously transformative
to the software world.
This applies not only to open-source but to your own closed-source
commercial software.
This means that people who before were kind of on the line
of, "should we give Matthew access to this project?"
"I don't know, he's not really that familiar with it..."
Stop having that discussion.
Give the core set of engineers direct access to make changes to the code
but give everyone else this privilege to issue pull requests.
There's a governance, there's an opportunity
to review and discuss, and these changes then have a nice little gate to control them
going into the core of the project.
You can reject them, you can approve them,
you can see if they're good changes, you can even have an analog debate
with these contributors. Let's say, for example,
I want to argue with myself in my other hat,
that I'm going to go back over to this right box and say,
"Not quite what I hoped for,
but with a few more hours of polish, this could work."
That is an analog response that is so important here
because rather than outright rejecting the change,
I can fire a message back over to the author
of this pull request saying I really appreciate what you did,
there's a few little things that are keeping me from accepting
your contribution, but if you could make these changes,
I'd be happy to accept it.
And so that GitHub student could return to the command line and open up
that txt file that they were making changes to and they could insert
that additional little bit of changes that was requested
by the code reviewer, they could save those,
they could add those to disk and they could commit those,
polish, that will be good enough, and they could push those changes back up.
And having pushed those changes, what you'll see,
while I literally just hang out on this web page,
I'm not even going to press the refresh button,
is that you're going to see those code contributions come in,
in timed sequence order.
This means that what you're actually doing
is discussing in a preview-able, shared, kind of collaborative way,
code changes that are being suggested to the product, and you can have these
analog, very close but we'll see, quite, not quite, not sure, oh!
With that polish I'm ready to accept it and then I can merge those changes in.
Now I'm going to be a bit angry here for just a second and say,
"You know what, you're just not heading in the right direction,
I wish you had listened but we are not going to repaint
the UI with tags at this time."
"Sorry."
And put a little frown in there and close and comment on that.
And this is closed, we're just not going to do this.
So it works either direction, it's an analog debate
with a yes or no eventually at the end of this conversation.
That is a way to democratize software contributions.
Now you've seen an awful lot of demonstration and what's helpful
is to say that even though we only peered at one of the GUIs,
I'll poke at a few more and show you what they look like,
that there is just an ocean of choices of graphical user interfaces
for you to choose to accomplish exactly the same things
that I did from the command line.
Now why show the command line, Matthew?
Because like learning a language, you're finding out the nouns and the verbs
and the exact addresses that you're working with
and when you transition over to a GUI, I think it will be exceedingly easy
because you'll know what belies those button pushes.
What is a push doing when I click the push button?
What is a clone doing when I click the clone button?
And you know the answer to that now having seen it from the command line.
You've seen me on Mac but you haven't yet seen me on Windows and now's the time
for me to toggle over to my Windows Instance, that I have up and running.
Here I am on Windows 7,
and I can do a quick little look at what repos I have
beneath my GitHub student, or GitHub org account.
I can look at these repositories and I can choose one,
let's say for example, hellogitworld down here from one of my colleagues
that I have privileged access to, or class-demo-1,
or this git scribe project and a quick click of the clone button
brings that down to my local machine. Look at the process,
look at the progress there, it'll save it to local disk
in exactly the same format, in compatible format
as if I had cloned this from the command line.
A project directory and then a .git folder beneath it to house that data.
I can even then jump into that project, open that repo, view the history,
see what's been happening to this lately.
You can see this one is much richer than just the Matthew
and student participation.
Here's Scott and Nick Quaranto participating, some other folks
like Chris Strom also contributing to this project.
And this is the same kind of participation but in a purely GUI sense
and this is our GitHub for Windows client but you now know
what belies those button clicks and to me, that's extremely important.
Now, having seen those demonstrations
of those two GUIs, you might ask even further,
"Is there kind of a compromise, where I could use
like Notepad for some of it? A graphical editor?"
"But then continue back to the command line
for some of the other instructions?"
Why of course, there's something else that we developed at GitHub called GitPad
that provides exactly such a hybrid little bridge
between the two, and there's also
a first-class citizen, if you work in the Java Space or anything else
on which derives from Eclipse.
Eclipse the IDE has a first-class plugin
called EGit that now shipped
with this summer's Juno release, it is the default version control system
for the Eclipse space and now ships with the Java distribution,
so you bet!
Visual Studio, likewise, there is a Git Extensions that works
with Visual Studio and plugs in and offers the same kind of right click,
checkout functionality that you've been seeing me
type longhand but instead gives it to you
inside that Visual Studio 2010 or above IDE.
This model that we've been talking about for collaborating, whether through a GUI
or through a command line, and then using that webpage kind of view
into what's been happening with the repos has a formal name,
and we call that social coding.
I think that's embodied by the fact that you're getting more people
to participate and review rather than fewer,
and it operates on this fork and pull model,
something that maybe some of your friends would say, oh forking that's bad,
you're taking your own copy of the repo and doing with it as you wish.
That's probably the downside, but the good side is when you offer
those changes back in, and they become an official part of the project,
thus nullifying that complaint.
If you needed a picture to put this into a diagrammatic form,
it would look something like this, the ability to have anybody take
a read-only (hence the gray lines) copy of the repo, to pass those up to someone
who is privileged enough to do the code review, to fold it in
and to have a discussion with, perhaps, the one or several people
that are the project owners and to have the purists of those contributions
folded in to the official copy of the repository.
Nobody had to be granted privilege
of being able to clone the repo in this model.
When said about closed source, your product's businesses,
what I mean by this is that any employee who works in the software space
could make a clone of the repo and offer it then perhaps to the trusted
senior engineers or the people who are responsible
for performing deliveries of your product.
In the open-source world, I literally mean anybody, the blue icons at the bottom,
can clone it and then offer it to the core project maintainers.
I think that's fascinating to see, but you were right in questioning,
"Does it really work?"
My favorite example is the Grails project on the JVM platform,
Five times the meaningful contributions when switched over to this model,
that's a statistic that simply cannot be dodged.
It's amazing, five times the contributions when switching to this approach.
Now you think that I've shown you graphical clients, and I've shown you
some desktop clients and maybe that's about it,
you know, you've got a web-based view and some places
that you can actually commit in checking code,
but I would actually be missing out if I didn't point out
a few more incredible things.
I'm going to go over to this hellogitworld repository
and I'm going to look at one of the other branches that I already had set up ,
and one of these other branches down here is called feature image.
Now typically we think of, we've been conditioned to think
of command line, command line, command line, we need these tools
and then graphical user interfaces for doing things like diff.
But what if you needed no desktop tools to review the most recent commits,
and in fact, to see not only the differences in code, I think we have
kind of a feeling and a sense of what that looks like side by side
but in fact an ability to review the changes to graphics as well.
This is a before and after of an image I've checked in, it works with PNGs,
JPEGs, TIFFs, BMPs, GIF images and what I can do is, with zero plugins,
zero desktop tools, I can review the differences between images
that perhaps the design team members of my organization
are contributing to this project.
I can even run a difference engine to have highlighted small things
like a copyright logo or a trademark symbol that was moved
from one corner to the other and I emphasize you're doing this
with zero tools on your desktop.
This is a purely web view and I think that is transformative
because people were "Oh my goodness", kind of burdened with the
"What have I got to load to be a productive developer
on this environment?"
"I've got to load this desktop tool and that desktop tool and a diff engine,
I've got to register that, make sure it's hooked into vert-",
just view, the web view.
And get the majority of the things that you are previously doing
on a desktop set of tooling.
If you're in a place, an organization, a business or an industry
that's constrained, that is not allowed to put this kind of stuff on the web,
maybe you're both excited to contribute to open-source but then you're frustrated
because you're never going to be able to use this at your job and I will tell you
that's not the case at all, many US and foreign government agencies
that I've had the delight to be able to teach, many medical institutions
and financial institutions run their own copy of GitHub
inside their firewall with GitHub Enterprise
thus nullifying any concern of using this .com
that I've been showing today.
A whole, on premise copy of everything that I've shown you already
in today's class.
Now as a last step I'll mention that this is just an introductory piece to Git.
There is literally, I want you to feel there is literally
months worth of learning ahead and I want that to be
a source of delight, not a problem.
This is something where you can use it for work with just a day or two worth
of practice but then a week or two later you're finding some advanced moves.
A month or two later, you're finding the way to rewrite history,
to shape your commits, to squash them into better delivery units,
and so, it's kind of like peeling the onion.
You can absolutely get your job done in a day or two worth of practice on this
but there are literally months if not years of features
that you can unravel, that make you more and more productive in using it.
Thank you once again.