Click on text below to jump to specific point in the video


Thanks for joining. I am Matthew McCullogh and I have Brent Beer with me offering tons of advice as we go through these materials. I am going to demonstrate a lot of the things which makes Git and GitHub such a useful tool. I am a developer by trade, and have worked in Java and Objective-C and MFC and assorted things. I say from my own experience as a developer and not just a teacher that this is an amazing transformation for me.
Reaching Matt and Brent.

Matt's background

Brent's background

We are here for talking about git and GitHub today.

Roadmap for this presentation

Why Git?
Why invest time in learning a new tool?Someone has already paved the way - BitKeeper story. Git adds all of the attributes of distributed version control systems. It works in both on-machine as well as a centralized repo model.
Git is one of the version control systems that has been developed in the internet era - it works very well with high latency and constrained bandwidth networks.
Git has a very small footprint.
Git is also simple.
It means it is simple to get started.But there is a massive amount of stuff to learn.
From its Unix and Linux roots - it is also composable.
Git is built of very small programs that work very well together to give the appearance of a suite of tools. Since the little pieces are still exposed to you, you can compose these with scripts and write your own new git instructions.
Setting up Git
It is just running an installer. An even more raw way to do that is to just copy the binaries to your $PATH variable. No admin privileges required. We have a page that we maintain at GitHub that shows you how to set up Git for different platforms.
I have got it already set up on my machine.

Type git --version for showing version.

Using Git
I want to start by emphasizing that this is a command line tool. This is important as you work more towards continuous integration and continuous delivery model of shipping your software.
Create a Git repository
This is an absolute inversion of the usual way of thinking about version control. I will create the repository locally, and push it to the network later. In the centralized VCS systems, you need to fetch the repository from the network, and usually only after getting sufficient privileges.
Some instructions
git init project1Instantaneously create a local repository but with no server or any daemon running in the background.
tree .git Poke inside the .git file.
I have .git a folder, with some files in it. Those are lifecycle management and instructions that I can hook into with Ruby, Perl, Python or shell scripts. I have a series of directories info, objects and refs - those are where the actual data for the commits - the version control timestamped copies of the repository are stored. 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, just delete the .git folder.
git status
Initial commit on a default branch called master. Nothing to commit yet. Lets open up a text editor and create a file first.txt. I have added some lorem ipsum text into the file.
Do a git status again.
git tracks content - it is examining current working directory and all directories beneath it to see if any file has been modified or appears like it has never seen before.
git add first.txt
But adding this file to version control is still is different than version control today. Adding it is merely indicating that we want it to participate in the next transactional changeset. git add is a suggestion to have this participate but not yet a permanent record of that file.
git commit -m "My first commit"
It says I have made a commit to the master branch (m), it is the root commit, it has a globally unique identifier (on screen) and it is my first commit as the commit message. This file is now a permanent part of version control and git status will report I have nothing to commit and the working directory is clean. I emphasize that nothing is running in the background.
Graphical user interface
There is absolute symmetry - everything is committed to disk in the .git folder from GUIs to the command line. Everything about the git repository is stored in that single .git folder.
Pro Git book - link

For other class notes and instructions - teach.github.com

To get help help.github.com

Create a repo
Using FireFox and Chrome - two browsers. They are signed in as different accounts. This will show real world use case where I am manipulating two different repositories.
Click a create a new repository.
Call it project1. Make it a public repo. Create the repository. The instructions show how you push and preserve local work up to centralized repository.
git remote add origin https://github.com/githubstudent/project1.git

git push -u origin master
It added a remote - registering a bookmark for that long address that represents the github destination. And then it pushes - git's verb for transmitting the contents of the local repository to some other place. And that repository has been transmitted and you now see that it says a new branch has been transmitted. It preserves and maintains the work done on the local work when you pushed. When you push, it simply is synchronizing the local activities up to a central repository.
Joining and participating in a project that already exists
Read-only access to the repo is sufficient. You simply begin helping and later ask for the permission for your code to be folded in once you made a meaningful contribution.
Click fork - makes a copy to your personal namespace (my personal account).
When we make changes to the fork, you can offer it back to the project.
git clone <address>
Change directory to repo. You can do git status and get info on all history and all branches from local disk.
git branch -a
Show me all branch names
git branch <name> Creates a branch

git checkout <name>
Instruction for toggling to a branch. That switches the entire contents of my local directory to represent, to be and to have the state of the <name> branch. No difference between master and newly created branch at this point.
I am going to create a file while on the new branch.
You see the new file in Finder view.
Ask git status.
Do a git add of brand new file. Then do a git commit with a new commit message. Its not yet up on github.com. You still need to push.
git push -u origin <branchname>
I am deciding to publish, for the very first time, this new branch. This is an opt-in process. Why opt-in? The idea is to create branches for just about any small thing you want to do. Bug fix, long lived feature branch - and then contain the work.
git checkout master
Watch the new file disappear from Finder view. This helps get the mental model - when you checkout a branch, it is updating the file system to reflect the state of that branch. When you checkout a branch, all files become up to date with that exact branch that you checked out.
On GitHub you can see the new branch created.
It is 1 commit ahead of everything else done in the project. I will offer the new file to the central project maintainer. Click on the pull request button. The pull request is a fundamental unit of work on the GitHub side of things. This pull request is offering my change into the core project maintainer.
Note the phrase: Why is it a pull request and not a push request?
The permissions model is inverted. I can make whatever change I wish to the project without asking for the right to contribute. But, those changes are not folded in until the core maintainers decide to bring them in. I will add a comment describing why this code should be brought in. The commits tab shows which units of work I am offering in. On the files change, I can see the summary of the code. With the pull request I am going to send this in and queue it up for the project maintainer to potentially act on.
I am going to the list of pull requests, as a maintainer.
I am going to merge this pull request and fold it into the core of the project.
Give everyone privilege to issue pull requests.
You can reject them, you can approve them, you can also debate with the contributors. Rather than outright rejecting change, I can fire a message to author of pull request.
Close a request without accepting the changes - with comment.

Git GUIs
A lot of GUI choices are available.
GitHub social coding
Social coding
Fork and pull model

A picture to visualize the way social coding works

Web based image diff. 
A difference engine to highlight small things.
GitHub enterprise: run your own copy of GitHub inside your firewall.

Video outline created using VideoJots