Falling In Love With Git

Sat, Oct 7, 2017 • GDI MPLS • Tamara Temple

welcome!

Girl Develop It is here to provide affordable and accessible programs to learn software through mentorship and hands-on instruction.
Some Rules:
We are here for you!
Every question is important
Help each other
Have fun

introductions

Name
History with GDI
Your goals for learning Git

class goals:

What is version control and
why should we even care?
Get you and your computer set up.
Basics of git -- the essential commands
"Gitting" social with GitHub

what is version control?

Version control allows you and your team to do two powerful things:

COLLABORATE

Create anything with other people - from academic papers to a collection of graphic design work to entire websites and applications.

TRACK & REVERT CHANGES

Gives you the ability to go "back in time" - see who wrote what, when, and maybe even help track down some bugs.

Not Convinced Yet?


Employers want this.
  • Required skill
  • Standard expection
  • Portfolio of work

Version Control Types

Centralized
Distributed

Centralized Version Control Systems

  • Central source
  • Collaborators "check out" files
  • Work is done locally
  • Others cannot work on same files
  • Collaborators "check in" files

examples: CVS, Subversion, Perforce

Distributed Version Control Systems

  • Local source, shared Depot
  • Collaborators clone (fork, mirror) the complete repository
  • Work done locally
  • Collaborators can work in same files
  • Collaborators push changes
  • Tools for merging changes

examples: Git, Mercurial (Hg)

Version Control Vocabulary

git
A program for tacking changes in files.
repository
Contains all of the project files and stores a revision history. Think of them as project folders.
clone
A copy of a repository that lives on your computer. This copy will keep track of your changes and allow you to "push" those to the remote repository.
commit
A change to a file or set of files. Think of this as "saving" a file. Usually has a message that goes along with it.
revision
A particular commit level in a repository, referred to by it's hash.
local
Your local clone or copy of the repository
remote
A remote repository that is shared by other project team members
stage
To stage a commit means to update the local index for your local clone to tell git what will be placed into the next commit
index
The local index keeps track of all the files that are under version control and what state they are in
branch
A separate line of revisions in a single repository. As single repository might have many branches.
master
The master branch of a repository is the default, and is generally treated as the "Source of Truth" for the repository.
fetch
Get the latest changes from a remote repository without merging them in.
pull
Fetch then merge the changes from a remote repository.
push
Send your local changes up to the remote repository.
pull request
Create a request for an upstream repository to accept your changes.

Intro to Git


Fast & Easy Setup
Get a whole team and project up and running quickly.
Distributed
Collaborators mirror (or clone) a complete repository, so everyone has a local copy of the history.
Hashed Commits
Commits have unique IDs to keep track of
when changes were made and by who.

Install & Setup Git


Download latest version of Git
git-scm.com/downloads
Get started with the command line.
On a Mac:

Open "Terminal"

Type "git" and hit enter.

On Windows:

Open "Git Bash"

Type "git" and hit enter.

A short intro to the command line
Command
  • 10's of 1000's of commands
  • First thing on the line
  • Often an abbreviation
Options
  • Tells command what to do with operands
  • Short options: single letter, preceeded with dash: 
    	  -A -l
  • Short options can be combined: 
    	  -Al
  • Long options: full words, preceeded with two dashes: 
    	  --all --oneline --verbose
Options
Of course, there are exceptions.
  • Not all commands have long options
  • Not all commands have short options
  • Some commands use a single dash for long options
Man pages
or "man-splainin'"
To get help on a command, type: 
	man command
to get a description of the command
including options and operands.
SSH KEYS
A way to identify and trust your computer
without having to type in a password.
Check for SSH keys on your computer:
SSH information is stored in the .ssh directory in your HOME directory.
pontiki2:~ student$ ls -Al ~/.ssh
This directory might not even exist just yet:
ls: /Users/student/.ssh: No such file or directory
Or it may already have something in it:
pontiki2:~ student$ ls -Al ~/.ssh
total 8
-rw-r--r--  1 student  staff  171 Sep 24 12:33 known_hosts
Generate a new SSH key:
pontiki2:~ student$  ssh-keygen -t rsa -C "your_email@example.com"
# Creates a new ssh key, using the provided email as a label
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/you/.ssh/id_rsa): [Press enter]
Passphrase:
Provides an extra layer of security to your SSH key but can be empty.
Enter passphrase (empty for no passphrase): [Type a passphrase or press Enter]
Enter same passphrase again: [Type passphrase again or press Enter]
Leaving the passphrase empty is very common for privately owned computers. If you are working on a public or shared computer, you want to add extra security, however.
So far so good?
Your identification has been saved in /Users/you/.ssh/id_rsa.
    Your public key has been saved in /Users/you/.ssh/id_rsa.pub.
    The key fingerprint is:
    01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db your_email@example.com
You'll probably see a little graphic image as well.
    The key's randomart image is:
      +---[RSA 2048]----+
      |           .BoE  |
      |           B O.o |
      |      o . = B *.o|
      |     o + = X O =+|
      |      . S X B o +|
      |         B . = . |
      |          + + .  |
      |           o .   |
      |            .    |
      +----[SHA256]-----+
Add your SSH key to your GitHub account:
First, copy the contents
of your key to your clipboard:
On OSX/Linux:
$ pbcopy < ~/.ssh/id_rsa.pub
On Windows:
$ clip < ~/.ssh/id_rsa.pub
Log into your Github account in your browser.
Click on the User menu in the upper right corner: Github User menu
Click on the "Setting" item in the dropdown menu: Github click on settings menu item
Click on the "SSH and GPG keys" item on the left side: Github click on SSH and GPG keys menu item
Look to see if you already have added this ssh key. If this section is empty, you haven't added the key yet. Github look for existing keys
If you haven't added the key (or if you want to make sure it's added), click the "New SSH Key" button Github New SSH Key
Fill in the Title, and then paste in the key you copied to the clipboard way back in step 1. Then click the "Add SSH Key" button to submit the form. Github enter the key title, paste in the key, and submit the new key
Enter your Github password when Github asks
to confirm the new key addition.
Your GitHub account now knows about your SSH key!
This will make it so you can push to and pull from remote Github repositories.
ALMOST THERE...

Configuring Git

Back on your terminal:
Sets the default name for Git to use when you commit changes.
$ git config --global user.name "your name"
Sets the default email for Git to use when you commit changes.
$ git config --global user.email "your_email@example.com"
Make sure everything looks right!
$ git config --list
user.name=your name
user.email=your_email@example.com

Let's take a break

Create your first repository

Go to your home directory:
pontiki2:~ student$ cd ~/
Create a working directory:
pontiki2:~ student$ mkdir my_first_repo
pontiki2:~ student$ cd my_first_repo
Initialize with Git:
pontiki2:my_first_repo student$ git init
Initialized empty Git repository in /Users/student/my_first_repo/.git/
pontiki2:my_first_repo student$ git status
On branch master

Initial commit

nothing to commit (create/copy files and use "git add" to track)
Create a new hello_world.txt file in your
new my_first_repo directory.
pontiki2:my_first_repo student$ echo 'Hello, world!' > hello_world.txt
Check the repo status:
pontiki2:my_first_repo student$ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	hello_world.txt

nothing added to commit but untracked files present (use "git add" to track)
Tell Git to track this new file:
pontiki2:my_first_repo student$ git add --verbose hello_world.txt
add 'hello_world.txt'
Check the repo status:
pontiki2:my_first_repo student$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

	new file:   hello_world.txt

Victory?

What Changed?
The color of the file in the status.

Time to make some changes.


Open the hello_world.txt file and add some text.
pontiki2:my_first_repo student$ date >> hello_world.txt
pontiki2:my_first_repo student$ cat hello_world.txt
Hello, world!
Sat Sep 24 14:53:04 PDT 2016
Check the repo status:
pontiki2:my_first_repo student$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

	new file:   hello_world.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   hello_world.txt
Stage the change:
pontiki2:my_first_repo student$ git add --verbose hello_world.txt
add 'hello_world.txt'
pontiki2:my_first_repo student$ git status
On branch master
Initial commit

Changes to be committed:
(use "git rm --cached <file>..." to unstage)

      new file:   hello_world.txt
Commit the change:
pontiki2:my_first_repo student$ git commit -m 'Initial commit.

Added `hello_world.txt` to my repo.'
[master (root-commit) e921ba9] Initial commit.
 1 file changed, 2 insertions(+)
 create mode 100644 hello_world.txt
Check the repo status:
pontiki2:my_first_repo student$ git status
On branch master
nothing to commit, working tree clean

Wait... so what did we just do?


When we add a new file, we tell Git to add the file to the repository to be tracked.
When we stage an existing file (also using 'add'), we tell Git to track the current state of our file.
A commit saves the changes made to a file - not the file as a whole. The commit will have a "hash" so we can track which changes were committed when and by whom.

Our Progress:

pontiki2:my_first_repo student$ git log
commit e921ba989bfcfcf9f646615663bf60b4b75c0c63
Author: Susan Student <student@example.com>
Date:   Sat Sep 24 15:12:00 2016 -0700

    Initial commit.

    Added `hello_world.txt` to repo.
Or a more condensed list
pontiki2:my_first_repo student$ git log --oneline
e921ba9 Initial commit.

Undo Changes


Nobody's perfect.
Sometimes you'll want to "undo" or "revert" some changes you've made.
Go make some changes to hello_world.txt.
Add a line of text like "testing out undoing local changes!"
pontiki2:my_first_repo student$ echo 'testing undo of local changes' >> hello_world.txt
pontiki2:my_first_repo student$ cat hello_world.txt
Hello, World!
Sat Sep 24 15:11:22 PDT 2016
testing undo of local changes
Check the repo status:
pontiki2:my_first_repo student$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   hello_world.txt

no changes added to commit (use "git add" and/or "git commit -a")
Tell Git to discard the changes made to hello_world.txt:
pontiki2:my_first_repo student$ git checkout hello_world.txt
What does hello_world.txt look like now?
Your changes should be gone, and status should be clean.
pontiki2:my_first_repo student$ cat hello_world.txt
Hello, World!
Sat Sep 24 15:11:22 PDT 2016
        
pontiki2:my_first_repo student$ git status
On branch master
nothing to commit, working tree clean
But what if you've already staged these changes?
Go make some more changes to hello_world.txt.
Add a line of text like
"testing out undoing staged changes!"
pontiki2:my_first_repo student$ echo 'undoing staged changes' >> hello_world.txt
pontiki2:my_first_repo student$  cat hello_world.txt
Hello, World!
Sat Sep 24 15:11:22 PDT 2016
undoing staged changes
Stage the change:
pontiki2:my_first_repo student$ git add -v hello_world.txt
add 'hello_world.txt'
Confirm the repo status:
pontiki2:my_first_repo student$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   hello_world.txt
Tell Git to undo the add and to discard the changes made to hello_world.txt:
pontiki2:my_first_repo student$ git reset HEAD hello_world.txt
Unstaged changes after reset:
M	hello_world.txt
pontiki2:my_first_repo student$ git checkout hello_world.txt
What does hello_world.txt look like now?
pontiki2:my_first_repo student$ cat hello_world.txt
Hello, World!
Sat Sep 24 15:11:22 PDT 2016
Your changes should be gone!
But what if you've already staged and committed these changes?
Go make some more changes to hello_world.txt.
Add a line of text like
"testing out undoing committed changes!"
pontiki2:my_first_repo student$ echo 'undoing staged and committed changes' >> hello_world.txt
pontiki2:my_first_repo student$ cat hello_world.txt
Hello, World!
Sat Sep 24 15:11:22 PDT 2016
undoing staged and committed changes
Stage & commit the change:
pontiki2:my_first_repo student$ git add -v hello_world.txt
add 'hello_world.txt'
pontiki2:my_first_repo student$ git commit -m 'commit some stuff.'
[master d123cdb] commit some stuff
 1 file changed, 1 insertion(+)
Print out the repo log:
pontiki2:my_first_repo student$ git log
commit d123cdb0ee38dd70c3455651e54689658f65a4b1
Author: Susan Student 
Date:   Sat Sep 24 15:59:22 2016 -0700

    commit some stuff

commit e921ba989bfcfcf9f646615663bf60b4b75c0c63
Author: Susan Student 
Date:   Sat Sep 24 15:12:00 2016 -0700

    Initial commit.

    Added `hello_world.txt` to repo.
You'll want to copy the first commit HASH from the log above:
d123cdb0ee38dd70c3455651e54689658f65a4b1
Tell Git to revert the commit using the hash from above:
pontiki2:my_first_repo student$ git revert --no-edit d123cdb0ee38dd70c3455651e54689658f65a4b1
What does hello_world.txt look like now?
pontiki2:my_first_repo student$ cat hello_world
Hello, World!
Sat Sep 24 15:11:22 PDT 2016
Your changes should be gone!

Branching


Branch:
A parallel version of a repo.
The "master" branch:
This is Git's default branch for all repositories.
Same repo, different branch:
Develop different code from the same base.
The master branch is left alone:
Conduct exploratory and development work without affecting the work on "master" branch.
Combine the changes on the branch back into "master":
Merge changes to your master branch only when you are ready.
"Git Flow"
Create a new branch:
Call it "version2"
pontiki2:my_first_repo student$ git checkout -b version2
Switched to a new branch 'version2'
Go make some changes to hello_world.txt.
Add a line of text like "testing out these really cool branches!"
pontiki2:my_first_repo student$ echo 'new line for v2' >> hello_world.txt
pontiki2:my_first_repo student$ cat hello_world.txt
Hello, World!
Sat Sep 24 15:11:22 PDT 2016
new line for v2
Check the git status:
pontiki2:my_first_repo student$ git status
On branch version2
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   hello_world.txt

no changes added to commit (use "git add" and/or "git commit -a")
Notice that `status` is reporting we are on branch "version 2".
Also, "hello_world.txt" is in red because we have not staged it yet.
Stage and commit the change:
pontiki2:my_first_repo student$ git add hello_world.txt
pontiki2:my_first_repo student$ git commit -m "Adding changes to version 2."
[version2 6a69379] Adding changes to version 2.
 1 file changed, 1 insertion(+)
pontiki2:my_first_repo student$ git status
On branch version2
nothing to commit, working tree clean
Switching Branches
From time to time, you may need to
bounce back and forth
from branch to branch.
See all branches for the current repository.
The branch with the asterisk ( * ) is the active branch.
pontiki2:my_first_repo student$ git branch
  master
* version2 # <-- this is the current version
Switch back to master.
What does hello_world.txt look like?
pontiki2:my_first_repo student$ git checkout master
Switched to branch 'master'
pontiki2:my_first_repo student$ git branch
* master
  version2
pontiki2:my_first_repo student$ cat hello_world.txt
Hello, World!
Sat Sep 24 15:11:22 PDT 2016
Switch back to version2.
What does hello_world.txt look like now?
pontiki2:my_first_repo student$ git checkout version2
Switched to branch 'version2'
pontiki2:my_first_repo student$ cat hello_world.txt
Hello, World!
Sat Sep 24 15:11:22 PDT 2016
new line for v2

Pretty neat, right?


But how do you combine the branches?

Merging


Use merge to get changes from
one branch to another
Collaboration at its best!
Switch to master:
pontiki2:my_first_repo student$ git checkout master
Merge with version2:
pontiki2:my_first_repo student$ git merge version2
Updating d4c7213..6a69379
Fast-forward
 hello_world.txt | 1 +
 1 file changed, 1 insertion(+)
"rebase" is another option, but for the sake of time, it won't be covered in this workshop.
There will be conflicts.
Git is pretty smart, but sometimes it won't know exactly how to merge your branches.

For example...
(version-2-branch) history.txt:
1. GDI was founded in 2010.
2. GDI is in 45 US cities.
(version-3-branch) history.txt:
1. GDI was founded in 2008.
2. GDI is in 45 US cities.
Git will make you resolve this conflict before the merge can happen.
Make sure you're in master:
pontiki2:my_first_repo student$ git checkout master
Already on 'master'
Change the first line of hello_world.txt.
We're going to create a conflict with this line.
pontiki2:my_first_repo student$ sed -i~ 's/World/Folks/' hello_world.txt
pontiki2:my_first_repo student$ cat hello_world.txt
Hello, Folks!
Sat Sep 24 15:11:22 PDT 2016
new line for v2
Stage and commit this change:
pontiki2:my_first_repo student$ git add hello_world.txt
pontiki2:my_first_repo student$ git commit -m 'Modified hello_world.txt

* Changed "World" to "Folks"'
[master 323461d] Modified hello_world.txt
 1 file changed, 1 insertion(+), 1 deletion(-)
Switch to version2:
pontiki2:my_first_repo student$ git checkout version2
Switched to branch 'version2'
Change the first line of hello_world.txt.
Make it something different than in the previous step.
pontiki2:my_first_repo student$ sed -i~ 's/World/you lot/' hello_world.txt
pontiki2:my_first_repo student$ cat hello_world.txt
Hello, you lot!
Sat Sep 24 15:11:22 PDT 2016
new line for v2
Stage and commit this change:
pontiki2:my_first_repo student$ git add hello_world.txt
pontiki2:my_first_repo student$ git commit -m 'Modify hello_world.txt

* Changing the first line of hello_world.txt in version2.'
[version2 98b3b40] Modify hello_world.txt
 1 file changed, 1 insertion(+), 1 deletion(-)
Merge from master into version2:
pontiki2:my_first_repo student$ git merge master
You should see something like:
Auto-merging hello_world.txt
CONFLICT (content): Merge conflict in hello_world.txt
Automatic merge failed; fix conflicts and then commit the result.
Resolving conflicts:
Where are the conflicts?
When you open hello_world.txt, you'll see both changes.
Git adds conflict markers to the areas it couldn't resolve. 
<<<<<<< HEAD
Hello, you lot!
=======
Hello, Folks!
>>>>>>> master
Sat Sep 24 15:11:22 PDT 2016
new line for v2
How do you fix them?
Delete Git's conflict markers and make the appropriate change.
You decided which line is correct, or you can even add a whole new line.
Make this file look exactly like you want it. 
Well, hello there!
Sat Sep 24 15:11:22 PDT 2016
new line for v2
Be on your way:
pontiki2:my_first_repo student$ git add hello_world.txt
pontiki2:my_first_repo student$ git commit -m "Fixing hello_world.txt"
[version2 5547b70] Fixing hello_world.txt

ignoring files and folders

Sometimes you will create files you don't want in your repository.
editor cruft
zip/tar files
log files
compiled files
Introducing the .gitignore file.
The .gitignore file goes into your project's root directory.
It contains patterns to match file and folder names to ignore.
In the last couple of sections, I created an extra file, which was the backup file for the sed command used to change the "hello_world.txt" file. 
pontiki2:my_first_repo student$ git status
On branch version2
Untracked files:
  (use "git add ..." to include in what will be committed)

        hello_world.txt~

nothing added to commit but untracked files present (use "git add" to track)
This is editor cruft, and we don't want such things cluttering up our repository.
You can simply delete it, but often you may not remember to do so.
If you add a pattern to the .gitignore file, you can be sure the file will not end up in your repository.
Add *~ on a line by itself in .gitignore
This means "ignore all files ending in ~"
pontiki2:my_first_repo student$ echo '*~' >> .gitignore
pontiki2:my_first_repo student$ git status
On branch version2
Untracked files:
(use "git add <file>..." to include in what will be committed)

      .gitignore

nothing added to commit but untracked files present (use "git add" to track)
The hello_world.txt~ is gone, and the new .gitignore file shows up.

Stage and commit the file. 
pontiki2:my_first_repo student$ git add .gitignore
pontiki2:my_first_repo student$ git commit -m 'Add .gitignore'
[version2 c35f894] Add .gitignore
 1 file changed, 1 insertion(+)
 create mode 100644 .gitignore
You can ignore entire directories as well 
log/
Will ignore the content of any directory named "log" anywhere in the repository.
/log/
Will ignore a "log" directory only at the project root.

Deleting Old Branches

When you've finished a branch, and merged it back into master,
you might want to delete that branch.

This is useful for long-running projects to keep from building up a lot of branches in the repo.
Make sure you are not on the branch you want to delete.
pontiki2:my_first_repo student$ git checkout master
Switched to branch 'master'
If the branch you want to delete has not been fully merged, git will tell you and stop the delete operation.
pontiki2:my_first_repo student$ git branch -d version2
error: The branch 'version2' is not fully merged.
If you are sure you want to delete it, run 'git branch -D version2'.
Let's go ahead and fully merge version2 into master.
pontiki2:my_first_repo student$ git merge version2
Updating 323461d..c35f894
Fast-forward
 .gitignore      | 1 +
 hello_world.txt | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 100644 .gitignore
Now we can delete the branch:
pontiki2:my_first_repo student$ git branch -d version2
Deleted branch version2 (was c35f894).
pontiki2:my_first_repo student$ git branch
* master

Let's get Social.

GitHub

Launched in 2008.
Leader in social coding.
GitHub is a commercial site that allows users to host Git repositories publicly and privately.
Open source projects host or mirror their repos on GitHub.
Post your own code for others to use or contribute to.

More Version Control Vocabulary

REMOTE
This is the version of a repository that is hosted on a server, like GitHub.
FETCH
This is when you get the latest changes from an online repository without merging them in.
PULL
This step combines fetching and merging changes from a remote repository.

PUSH
Sends your committed changes to a remote repository.

Your first GitHub Repo

Click on the "New" menu in the top right:
Github New Menu
Click on "New Repository"
Github New Repository Menu Item
README

"While a README isn't a required part of a GitHub repository, it is a very good idea to have one.
READMEs are a great place to describe your project or
add some documentation such as how to install
or use your project. You might want to include contact information - if your project becomes popular
people will want to help you out."
Fill in the repo name.
A common practice is to name the repo the same as your project working directory.
It isn't a rule so much as a practice, and you can name the repo almost anything you want.
Github Filled out new repository form with my_first_repo
Click/press the "Create repositor" button
Github Newly created repository
We will use the third option: "existing repository from command line"
Github Push from existing repository from command line 
pontiki2:my_first_repo student$ git remote add origin git@github.com:tamouse/my_first_repo.git
pontiki2:my_first_repo student$ git push -u origin master
You might not see the following; after you answer "yes" you should not see it again.
The authenticity of host 'github.com (192.30.253.113)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes
You should see something similar whenever you push:
Delta compression using up to 4 threads.
Compressing objects: 100% (17/17), done.
Writing objects: 100% (26/26), 2.53 KiB | 0 bytes/s, done.
Total 26 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), done.
To git@github.com:tamouse/my_first_repo.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.
Going back over to your repository on GitHub,
refresh the page.
What do you see?

Victory!

Forking

There are millions of public repos on GitHub.
If you want to use or contribute to
a repository, you can fork it.
This will make a personal copy of another user's repository that will live on your account. While you can work with it and make changes without affecting the original repository, it is still attached, making it easy for you to contribute back to the original when you're ready.
After forking, clone your fork to your local machine:
pontiki2:~ student$ git clone git@github.com:tamouse/jekyll.git
Cloning into 'jekyll'...
Warning: Permanently added the RSA host key for IP address '192.30.253.112' to the list of known hosts.
remote: Counting objects: 30595, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 30595 (delta 0), reused 0 (delta 0), pack-reused 30593
Receiving objects: 100% (30595/30595), 9.18 MiB | 1.40 MiB/s, done.
Resolving deltas: 100% (18545/18545), done.
Checking connectivity... done.

Pull Requests

After you fork and clone a repo, all pushed changes will go to your fork.
These changes will not affect the original repo.
If you want to get your changes to be incorporated in the original repo, you
can submit a pull request.
This sends a request to the owners for the original
(also known as an "upstream")
repository, showing the changes you wish to make.
It is the start of a conversation between you and the original repo owners.
This is the process most teams use to
review code submissions from their team members before including the changes in a release.

Part II

Practical Git

Form into teams

  • Teams of 3 or 4
  • Pick a team captain
  • Pick a team name

The Project

  • Building a "brochure" site for a client.
  • Client love kittens
  • Three pages:
  • landing page
  • about page
  • list of kittens

Team Roles

team captain
  • create global repository
  • review changes / pull requests
  • merge pull requests

Team Roles

beyond the team captain, you'll need:
  • Designer / UX / Stylist
  • Content Developer
  • Resource Wranger

Work Flow

Starting Up

Team Captain

  • Create an organization
  • Invite team members

Work Flow

Starting Up

Team Members

  • Respond to invitation

Work Flow

Starting Up

Team Captain

  • Create the first project repo
  • Create team and give permissions

Work Flow

Starting Up

All team members

  • Clone repository to local machine

Work Flow

Every Project Step

Each team member:

  • Checkout Master
  • Pull from Origin
  • Create feature branch
  • Develop and test
  • Add, commit, and push completed feature branch
  • Create Pull Request

Team Captain

  • Review Pull Request
  • Merge PR
  • Delete Feature Branch

Thanks for coming!

View the slide repo on Github
for more info, links, etc.

We want your feedback:

tinyurl.com/gdiMpls

Upcoming Classes: