[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.