Placeholder Image

Subtitles section Play video

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

[github SOCIAL CODING]

Subtitles and vocabulary

Click the word to look it up Click the word to find further inforamtion about it