Intro to Git and Github

teaching-materials.org/git

Welcome!

What we will cover in this workshop

• What is version control and why should we care?
• Basics of Git: the essential commands
• GitHub (or, a little Git between friends)

If it seems hard, it's because it is

"The version control system that was ... designed to make you feel less intelligent" (source)

Installation and Setup

Install Git

Setup steps on GitHub

Installation and Setup

Setup name and email in gitconfig

$ git config --global user.name "Your Name Here"
# Sets the default name for Git to use when you commit
          

$ git config --global user.email "your_email@example.com"
# Sets the default email for Git to use when you commit
          

$ git config --list
          

Setup: Setting the default text editor

By default Git is set up to use Vim as the text editor.

Follow these instructions to change your default text editor to whatever you prefer.

Setup!

What is version control?

Version control is a tool that allows you to...

You already manage versions of your work!

Do you have files somewhere that look like this?

          Resume-September2016.docx
          Resume-for-Duke-job.docx
          ResumeOLD.docx
          ResumeNEW.docx
          ResumeREALLYREALLYNEW.docx
        

Types of Version Control Systems

Centralized Version Control

One central server, each client (person) checks out and merges changes to main server

Examples: CVS, Subversion (SVN), Perforce

Distributed Version Control

Each client (person) has a local repository, which they can then reconcile with the main server.

Examples: Git, Mercurial

Why Use Git?

• Fast! Access information quickly and efficiently.
• Distributed! Everyone has her own local copy.
• Scalable! Enables potentially thousands (millions!) of developers to work on single project.
• Local! You don't need a network connection to use it. You only need a remote server if you want to share your code with others (e.g., using GitHub).
• Branches! Keep your coding experiments separate from code that is already working.
• Everyone has a local copy of the shared files and the history.

Git has its own Vocabulary

• A repository is where you keep all the files you want to track.
• A branch is the name for a separate line of development, with its own history.
• A commit is an object that holds information about a particular change.
• HEAD refers to the most recent commit on the current branch.

Some Basic Git Commands

• init
• add
• commit
• status
• log
• branch
• checkout
• fetch
• merge
• pull
• push
• clone

Create a Local Repository

1. Go to your home directory

$ cd
OR
$ cd Users/username
          

2. Create a new "working directory" and cd into it

$ mkdir my-repo
$ cd my-repo
          

3. Initialize it as a local Git repository

# make sure you are in the right directory!
$ pwd
$ git init
$ git status
          

Add files

1. Create a new file in your new folder named kitten.txt

$ touch kitten.txt
          

2. Check the status of your repo with git status

$ git status
          

3. Tell Git to track our new file with git add

$ git add kitten.txt
$ git status
          

Success! The file you just added is now tracked by Git

Changes and commits

1. Open kitten.txt, add some text, and save it

$ git status
          

2. Stage the change and check the status

$ git add kitten.txt
$ git status
          

3. Commit the change with a good commit message that explains and describes what you did

$ git commit -m "First commit. Added kitten.txt to repository."
          

Whoa.

What did we just do??

• When we add a new file, we tell Git to add the file to the repository to be tracked.
• This is also called staging a file. A snapshot of our changes is now in the staging area (aka the index, aka the cache), ready to be saved.
• A commit saves the changes made to a file, not the file as a whole. The commit will have a unique ID so we can track which changes were committed when and by whom. (Good commit messages help, too.)

Look at your progress

$ git log
          

commit 6853adc0b6bc35f1a8ca0a6aa5e59c978148819b
Author: Your name <you@your-email.com>
Date:   Tues May 23 16:01:22 2017 -0700

  First commit. Added kitten.txt to repository.
            

Congratulations.
You are now using Git.

Now try...

• Make changes to kitten.txt and make some more commits.
• Add another file (or image!) to your project and commit that.
• Change more than one file at a time, and practice making commits where you stage only one file, or both files together.
• Try the git diff command when you have unstaged changed.
• Look at your history with git log as you add more commits (and try adding the --oneline option)

Don't forget to run git status regularly so that you can see what is happening at each stage!

The Magical Realms of Git

The Workspace

Working Tree

What you see in your editor and where you make your changes

The Staging Area

Index / Cache

A snapshot of your working tree at a particular point in development

lets you gather changes for the next commit

Your Local Repo

Your copy of a project, initialized as a Git repository

(i.e., it has a .git directory)

The Remote Repo

The shared copy of the repo that lives on a remote server

Very often this is GitHub, but it doesn't have to be.

Conventionally named origin but doesn't have to be.

It's all about the history

What should I use version control for?

Anything. But not everything.

Gitignore

You decide what goes into version control.You can, and should, leave some things out.

libraries, .dotfiles, api keys...

The.gitignore file at the root of your project directory

Check out gitignore.io for some suggestions.

We all make mistakes

Don't worry. Git is your friend.

Undoing changes in your working copy

If you haven't added/committed yet

$ git checkout kitten.txt
            

Look at kitten.txt in your editor: your changes are gone (you've gone back to the previous commit state).

Un-staging a file

1. In your text editor, create a new file, and name it possum.txt
2. Switch back to your terminal.

$ git add possum.txt
$ git status
$ git reset possum.txt
$ git status
            

The file is removed from staging, but your working copy will be unchanged.

Undoing changes you've already staged

$ git add kitten.txt
$ git reset HEAD kitten.txt
$ git status # the file has been unstaged.
$ git checkout kitten.txt
# resets the working copy to its state at the last commit
            

Now look at the same file in your editor again: your changes are gone, and the file is removed from staging.

Er, what if I already committed it?

Undoing committed changes

Git lets you go back to any previous commit.

$ git add kitten.txt
$ git status
$ git commit -m "Make a change I will soon regret making"
$ git log --oneline
# you should see (at least) two commits here at this point
# copy the short form of the hash id
            

Soft reset

Undoing just the commit

$ git reset --soft 53d23c4
$ git log --oneline
          

Notice that the commit is gone from your log, but your changes are still in your editor.

Hard reset

Undoing the commit AND the changes

$ git reset --hard 53d23c4
$ git log --oneline
          

Notice that the commit is gone from your log, AND your changes are removed in your editor.

Branching

A branch is essentially another copy of your repo that will allow you to isolate changes and leave the original copy untouched. You can later choose to combine these changes in whole or part with the "master" copy, or not.

Branches are good for features!

Branching

Branching

• Develop different code on the same base
• Conduct experimental work without affecting the work on master branch
• Incorporate changes to your master branch only if and when you are ready...or discard them easily

Branches are cheap!

Branching

Create a new branch called feature

$ git checkout -b feature
          

Add new lines to kitten.txt

$ git add kitten.txt
$ git commit -m "Adding changes to feature"
$ git log --oneline
          

Branching

Branching

Switching branches

See all your local branches. Your active branch, the one you're "on," is marked with an *

$ git branch
          

Switch to master branch and look at the commit history

$ git checkout master
$ git log --oneline
          

Switch to feature branch and look at the commit history

$ git checkout feature
$ git log --oneline
          

Merging

Merge to get changes from one branch into another

Switch to master and merge changes

$ git checkout master
$ git merge feature
$ git log --oneline
          

Merging Branches

When you merge, you create a new commit on the branch you just merged into

What could possibly go wrong?

What is a merge conflict?

what a merge conflict looks like

You will see this in the affected file your text editor

Here are lines that are either unchanged from the common ancestor,
or cleanly resolved because only one side changed.
<<<<<<< yours:sample.txt
Your changes are reflected here in this section.
=======
Their changes are here in this section, in conflict with yours.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.
        

Merging

Merge conflicts

Change the first line in kitten.txt in master branch

$ git add kitten.txt
$ git commit -m "Changing kitten in master"
          

Now change the first line in kitten.txt in feature branch

$ git checkout feature
  # open kitten.txt and change the first line
$ git add kitten.txt
$ git commit -m "Changing kitten in feature"
          

Merging

Merge conflicts, cont.

Merge the changes from master into the feature branch

$ git merge master #remember, you are on the feature branch here
          

You will be notified of a conflict. Go to the file in your editor and fix the problem. Then add and commit your edits.

Merging

The merge conflict occurred because the feature branch (which is based off of master) both had divergent histories for the same file.

The big picture

Share Your Code on GitHub

Git + Friends = GitHub

GitHub has over 20 million users,
and over 57 million repositories

What is GitHub for?

• GitHub allows users to host Git repositories publicly and privately
• Open source projects host or mirror their repositories on GitHub
• Push your own code up for others to use or contribute to
• Read, copy, and learn from the code in other people's repositories
• Contribute to open source projects (like the Girl Develop It website!)

GitHub

Create your first remote repository

You will need to be logged into your GitHub account to do this.

GitHub

Create your first repository

GitHub

Set up remote repo to sync with your local repo

After you click the big green button to create your repo, follow GitHub's instructions for next steps.

$ git remote add origin https://github.com/YOUR-GITHUB-USERNAME/REPO.git
$ git push -u origin master

# that -u is an option that signals that you are setting
# a tracking reference to the remote branch as the default;
# you only need to use this flag the first time
          

Now check out your GitHub repo online!

What can I do with a GitHub Account?

FORK a repo: Find some code you want to use and grab a copy of it.

(Then you'll also need to CLONE the repo — that is, make your own local copy of it)

PUSH to a remote repo you own: post some code you want others to see.

submit a PULL REQUEST to the owner of a repo you'd like to contribute to.

Forking

This

not this

Forking

If you want to use or contribute to a repository, you can fork it.

A fork is just a copy of a repository, saved to GitHub.

Cloning

To get a local copy of the fork you just made, use the git clone command.

$ cd ../

$ git clone https://github.com/your-github-username/tiny-repo.git

$ cd tiny-repo
$ git remote -v
          

Wait...what?

Establishing a connection to an upstream repo

To sync your fork with the original repo, you need to add another remote named upstream

$ git remote -v
$ git remote add upstream https://github.com/gdisf/tiny-repo.git
$ git fetch upstream
        

Shared Repos

If team members are contributing to a single repo, each member of the team will want to make sure that she has everyone else's changes before pushing her own changes to the GitHub repo.

Pulling

$ git commit -m "My latest commit"
            

$ git pull origin master
            

$ git commit -m "Fixing merging conflicts"
            

$ git push origin master
            

Pull Requests

• After you fork and clone a repository all pushed changes will go to your fork.
• These changes will not affect the original [upstream] repository!
• If you would like your changes to be incorporated into the original repo, you can submit a pull request.
• A pull request is a GitHub feature that lets you ask the owner of the upstream repo to pull your changes in (since you don't have permission to push)

Starting a pull request

You need to do this on GitHub, not from the command line.

Previewing and sending pull request

Managing pull requests

If you are the owner of repo, you will review and decide whether to merge in the pull requests you receive.

You can learn more from the
Github Collaborating Tutorials.

Editing pull requests

To make changes to an existing pull request, commit changes to the same branch, and push them to GitHub. They'll be added to the PR automatically.

$ git pull origin my-pr-branch
$ git commit -m "Fix typos"
$ git push origin my-pr-branch
            

Making multiple pull requests

Because any new commits to a branch will be added to that branch's pull request, you need to make any new, unrelated changes to a new branch.

$ git checkout master
$ git checkout -b new-feature-branch
$ git commit -m "Add a fancy new feature"
$ git push origin new-feature-branch
            

Be sure the new branch is based off of the master branch, and not your other working branch.

Vocabulary Recap

• Git is version control software.
• Github is an online community where you can collaborate with others on projects using Git.
• A repository is a folder where you keep all the files you want to track (normally a fully encapsulated project).
• local refers to the version of the repository on your computer/local development environment
• fork is a copy of someone else's repository that you have
• cloning a repo means taking it from github and putting it onto your local
• origin refers to the version of the repository that it was cloned from (normally on github)
• upstream: if you have forked a repo, this refers to the original parent repository

Vocabulary Recap, cont

• A branch is the name for a separate line of development within a repo, with its own history.
• A commit is an object that holds information about a particular change. You make commits on branches
• HEAD refers to the most recent commit on the current branch.
• A pull request is a means to create an approval process for merging one branch into another on Github

Git Learning Resources

• Try Git from CodeSchool.com
• The Official Docs
• Git Cheatsheet: There are lots of cheatsheets out there, but this one is a visual illustration of Git structure and commands.
• Git Immersion: a great in-depth tutorial with hands-on exercises.
• Pro Git: a very thorough reference. If Git can do it, you'll find it here.
• Atlassian's Git Tutorials: from the creator of (among other things) SourceTree, a free visual Git tool for Mac & Windows.
• Git Workflows: an overview of different ways that teams can use Git.

Questions?