Intro to Git and Github

Welcome!

Welcome!

What we will cover today

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

What is version control?

Version control allows you (and your team) to…

You already manage versions of your work!

Do you have files somewhere that look like this?

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

Brief history of Version Control

1990s — CVS (Concurrent Version Systems)

2000s — SVN (Apache Subversion)

2005 — Git

Chapter 1: Git is Born

The first commit, April 2005

commit e83c5163316f89bfbde7d9ab23ca2e25604af29
Author: Linus Torvalds <torvalds@ppc970.osdl.org>
Date: Thu Apr 7 15:13:13 2005 -0700
Initial revision of "git", the information manager from hell
								

Version Control Types

Centralized Version Control

Examples: CVS, SVN

Distributed Version Control

Examples: Git, Mercurial

Centralized Version Control

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

...NOT how Git works!

Distributed Version Control

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

...this is how Git does it!

Why Use Git?

• Fast! Access information quickly and efficiently.
• Distributed! Everyone has her own local copy.
• Mind-bogglingly 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.

Your First Local Repository

Go to home directory

$ cd ~/
$ pwd #make sure you're in your home directory
						

Create a "working directory"

$ mkdir my-repo
$ cd my-repo
						

Initialize repository with Git

$ git init
$ git status
						

More about README.md

Add Files

Create a README.md file in your new folder

Check repo status

$ git status
						

Tell Git to track our new file

$ git add README.md
$ git status
						

File is now tracked by Git

Changes and Commits

Open README.md and add some more text

$ git status
						

Stage and commit the change

$ git add README.md
$ git commit -m "First commit. Added README to repository."
						

A good commit message acts like a headline to a newspaper article (but not clickbait!)

What did we just do?

How is this all different than just saving a file?

• 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 (hash) so we can track which changes were committed when and by whom.

Look at Your Progress

$ git log
						

 commit [HASH HERE]
 Author: Your name <you@your-email.com>
 Date:   [DATE HERE]

      First commit. Added README to repository.
							

Let's Try It!

• Make changes to README.md 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.

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

Nobody's Perfect

Undoing local changes

If you haven't staged/committed yet

$ git checkout README.md
							

Look at README.md. Your changes are gone. You've gone back to the previous commit state.

Nobody's Perfect

Remove a file from staging

Create new file my_new_file.txt

$ git add my_new_file.txt
$ git reset my_new_file.txt
							

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

Nobody's Perfect

Undoing staged changes

$ git add README.md
$ git reset HEAD README.md
$ git status ## your changes were unstaged
$ git checkout README.md
							

Look at README.md. Your changes are gone and the file is removed from staging.

Nobody's Perfect

Undoing committed changes

Git lets you go back to any previous commit.

$ git add README.md
$ git status
$ git commit -m "Make a change I will soon regret making"
$ git log --oneline
							

Nobody's Perfect

Undoing committed changes

$ git revert 53d23c4
	# Your default editor will open here
	# you can just save it and close it as is.
$ git log --oneline
						

Notice that the original, regrettable commit is still there, but now you also have another commit that undoes the changes introduced by the original one.

To Track or not to Track?

You decide what goes into version control.

You can—and should!—leave some things out.

libraries, .dotfiles, api keys...

Git shows you an easy way to do this: .gitignore

Branching

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

Branching

Why Branch?

• Develop different code on the same base
• Conduct exploratory work without affecting the work on master branch
• Incorporate changes to your master branch only when you are ready
• Make it easier to collaborate

Branching

Create a new branch called my-feature

$ git checkout -b my-feature
						

Add new lines to README.md

$ git add README.md
$ git commit -m "Adding changes to my-feature"
						

Branching

Switching Branches

See all branches. Branch with * is active

$ git branch
						

Switch to master and look at README.md

$ git checkout master
						

Switch to my-feature and look at README.md

$ git checkout my-feature
						

Merging

Copying changes from one branch to another is called merging.

Switch to master and merge the changes from the branch my-feature

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

Merging—When Things Go Wrong

What is a merge confict?

Merging

Merge Conflicts

Change first line in README.md in master branch

$ git add README.md
$ git commit -m "Changing first line in master"
						

Change first line in README.md in my-feature branch

$ git checkout my-feature
# open README.md and change first line
$ git add README.md
$ git commit -m "Changing first line in my-feature"
						

Merging

Merge conflicts, cont.

Merge from master into my-feature

$ git merge master
						

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

Git + Friends = GitHub

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!

Git Structure & Workflow

Now, GitHub is acting as our remote repository

GitHub

Push to Repo on GitHub

Edit README.md

$ git add README.md
$ git commit -m "Updating readme file"
$ git push origin master
						

Now check out your GitHub repo online!

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 remote repository.

Pulling

Commit local changes first

$ git commit -m "My latest commit"
				

Get changes that have been pushed

$ git pull origin master
				

Git may prompt you to fix any conflicts, then commit

$ git commit -m "Fixing merging conflicts"
				

Now you are ready to push local changes to GitHub

$ git push origin master
				

Forking

There are MILLIONS of public repositories on GitHub.

There are huge open source projects (including Git!)…

…and small projects like these slides.

Collaborating

If you want to use or contribute to a repository, you have to fork the repository, then clone it to your computer.

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

Forking

After you fork the repository, it shows up in your repositories.

Let's Try It! Fork this repo.

You can only fork repos through the GitHub website.

Cloning

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

$ cd ../

$ git clone https://github.com/USERNAME/git-resources.git

$ cd git-resources
$ git remote -v
				

Girl Developer
and the Three Repositories

Connect to the Original

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/GDIBTV/git-resources.git
$ git fetch upstream
				

git fetch downloads Git references not present in your local repository, but does not modify your files (think of it like getting a table of contents rather than the contents themselves)

Pull Requests

After you fork and clone a repository all pushed changes will go to your fork (origin)

These changes do not affect the original (upstream) repository (mostly because permissions). To do that, you need to 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.

Starting a Pull Request

Pull requests can only be done through the GitHub website.

Opening Pull Requests

Managing Pull Requests

Repo owners review and decide whether to merge in the pull requests they receive.

You can learn more from the
Github Collaborating Tutorials

Let's Try It!

• Make changes to the git-resources repository and push to your remote.
• Submit a pull request to the original repository.
• Explore other repos on GitHub and get excited about the world that is now open to you!

Thank You!

Keep in touch!

rachaela@girldevelopit.com

raearnold.com