- Intro to Git and Github
-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 -
Welcome!
-Tell us about yourself.
--
-
- Who are you? -
- What do you hope to get out of the class? -
- Who was your favorite character as a child? -
What we will cover today
--
-
- What is version control and why should we care? -
- 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 entire websites and applications.
-Track and revert changes
-Mistakes happen. Wouldn't it be nice if you could see the changes that have been made and go "back in time" to fix something that went wrong? -
Working without Version Control
-
- The Horror!
-Working with Version Control
-
- Rainbows and bunny rabbits! -
Brief history of Version Control
-1990s -- CVS (Concurrent Version Systems)
-2000s -- SVN (Apache Subversion)
-2005 -- Git (well, Git)
-Version Control Types
-Centralized Version Control
-Examples: CVS, SVN
-One central server, each client (person) checks out and merges changes to main server
-Distributed Version Control
-Examples: Git, Mercurial
-Each client (person) has a local repository, which they can then reconcile with the main server.
-Version Control Distribution
-
- Version Control Distribution Change
-
- Intro to Git
-Goals of Git Design
--
-
- Fast -- add to your team and code base quickly -
- Distributed (see slide above) -
- Each commit has a corresponding hash (track changes from everyone) -
- Everyone has a local copy of the history -
Installation and Setup
- -Install git
-
-
- Installation and Setup
-Setup ssh keys
-
- $ cd ~/.ssh
-
-$ ssh-keygen -t rsa -C "your_email@example.com"
-# Generating public/private rsa key pair.
-# Enter file in which to save the key (/Users/you/.ssh/id_rsa): [Press enter]
-
-Enter passphrase (empty for no passphrase): [Type a passphrase]
-# Enter same passphrase again: [Type passphrase again]
- Installation and Setup
-Get SSH Key
-
-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
- Installation and Setup
-Add SSH Key to Github
-
- Installation and Setup
-Setup name and email in gitconfig
-
+
+
+
+
+
+
+
+
+
+
+ 
+ Intro to Git and Github
+
+
+
+
+ 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
+
+
+
+
+
+ Welcome!
+
+ Tell us about yourself.
+
+ - Who are you?
+ - What do you hope to get out of the class?
+
+
+
+
+
+ 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…
+
+ Collaborate
+ Create anything with other people, from academic papers to entire websites and applications.
+
+
+ Track and revert changes
+ Mistakes happen. Wouldn't it be nice if you could see the changes that have been made and go "back in time" to fix something that went wrong?
+
+
+
+
+ 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
+
+
+ You invented your own version control!
+ But, we can do it so much better with Version Control tools
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+ Installation and Setup
+
+ Install git
+
+
+
+
+ Installation and Setup
+ Setup name and email in git config
+
$ 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
-
-
-
-
-
-
- Your first Local Repository
- Go to home directory
-
- cd ~/
- OR
- cd Users\username
-
- Create a "working directory"
-
- mkdir my-first-repo
- cd my-first-repo
-
- Initialize repository with Git
-
- git init
- git status
-
-
-
- Add files
- Create a new hello_world.txt file in your new folder
- Check repo status
-
- git status
-
- Tell Git to track our new file
-
- git add hello_world.txt
- git status
-
- File is now tracked by Git
-
-
- Changes and commits
- Open hello_world.txt and add some more text
-
- git status
-
- Stage and commit the change
-
- git add hello_world.txt
- git commit -m "First commit. Added hello world to repository."
-
-
-
-
-
-
- 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
- - When we stage an existing file (also with the keyword 'add'), we are telling Git to track the current state of our file
- - A commit saves 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.
-
-
-
-
- Look at our progress
-
- git log
-
-
- commit [HASH HERE]
- Author: Your name
- Date: [DATE HERE]
-
- First commit. Added hello world to repository.
-
-
-
- Look at our progress, visually
-
- gitk
-
- 
-
-
-
-
-
- Nobody's Perfect
- Undoing local changes
- If you haven't committed yet
-
- Open hello_world.txt and add some new text
-
- change hello_world.txt
- git checkout hello_world.txt
-
-
- Look at hello_world.txt. Your changes are gone.
-
-
- Nobody's Perfect
- Undoing staged changes
-
- Open hello_world.txt and add some new text
-
-git add hello_world.txt
-git reset HEAD hello_world.txt
-git checkout hello_world.txt
-
-
- Look at hello_world.txt. Your changes are gone.
-
-
- Nobody's Perfect
- Undoing staged changes
-
- Open hello_world.txt and add some new text
-
-git add hello_world.txt
-git commit -am "Changing and committing some lines"
-git log --pretty=oneline
-git revert [HASH]
-
-
- Look at hello_world.txt. Your changes are gone.
-
-
- 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
-
-
-
- Nobody's Perfect
- Delete a file
- Create new file my_other_file.txt
-
-git add my_other_file.txt
-
- Manually delete your file
-
-git rm my_other_file.txt
-
-
-
-
-
-
- Branching
-
- - 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
-
-
-
- Branching
- Create a new branch called version2
-
-git checkout -b version2
-
- Add new lines to hello_world.txt
-
-git add hello_world.txt
-git commit -m "Adding changes to version 2"
-
-
-
- Branching
- Switching branches
- See all branches. Branch with * is active
-
-git branch
-
- Switch to master and look at hello_world.txt
-
-git checkout master
-
- Switch to version2 and look at hello_world.txt
-
-git checkout version2
-
-
-
-
-
-
- Merging
- Merge to get changes from one branch into another*
- Switch to master and merge changes
-
-git checkout master
-git merge version2
-
- *rebase is another option, but will not be covered in this workshop
-
-
- Merging
- Merge conflicts
- Change first line in hello_world.txt in master branch
-
-git add hello_world.txt
-git commit -m "Changing first line in master"
-
- Change first line in hello_world.txt in version2 branch
-
-git checkout version2
-# open hello_world.txt and change first line
-git add hello_world.txt
-git commit -m "Changing first line in version2"
-
-
-
- Merging
- Merge conflicts, cont.
- Merge from master into version2
-
-git merge master
-
- You will be notified of a conflict. Go to the file and fix the problem. Then commit your edits.
-
-
-
-
-
-
- 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 repositories on GitHub
- - Post your own code for others to use or contribute to
- - Use and learn from the code in other people's repositories
-
-
-
-
-
-
- GitHub
- Create your first repository
- 
-
-
- GitHub
- Create your first repository
- 
-
-
- GitHub
- 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.
-
-
-
- GitHub
- Get Local Repository of GitHub Repo
-
-cd ../ # Back in root directory
-mkdir hello-github
-cd hello-github
-git init
-git remote add origin git@github.com:username/NAME-OF-REPO
-git pull origin master
-
-
-
- GitHub
- Push to GitHub Repo
- Edit the ReadMe file
-
-git add README
-git commit -m "Updating readme file"
-git push origin master
-
- Go look at your github repo online
-
-
- GitHub
- Pulling from remote repository
- If you are working with a team, you want to make sure that you have everyone's changes before pushing your changes to the GitHub repo
-
-# Commit local changes
-git commit -m "My latest commit"
-# Pull changes other people have made
-git pull origin master
-# Fix any conflicts (see merge conflicts above) and commit
-git commit -m "Fixing merging conflicts"
-# push local changes to GitHub
-git push origin master
-
-
-
-
-
-
- Forking
-
- - There are MILLIONS of public repositories on GitHub
- - If you want to use or contribute to a repository, you can fork it.
-
-
-
- Forking
- 
-
-
- Forking
- Cloning
- Clone to get a local repository of your fork
-
-cd ../
-
-git clone https://github.com/username/FORKED-REPO-NAME.git
-
-cd FORKED-REPO-NAME
-
-git remote add upstream https://github.com/original-username/FORKED-REPO-NAME.git
-# Assigns the original repository to a remote called "upstream"
-
-git fetch upstream
-# Pulls in changes not present in your local repository, without modifying your files
-
-
-
-
-
-
- Pull Requests
-
- - After you fork and clone a repository all pushed changes will go to your fork
- - These changes will not affect the original repository
- - If you would like to get your changes to be incorporated into the original repo, you can submit a pull request
-
-
-
- Starting a pull request
- 
-
-
- Previewing and sending pull request
- 
-
-
- Managing pull requests
- How to manage pull requests is out of the scope of this short workshop, but you can learn more from the Github Collaborating Tutorials
-
-
-
-
- Questions?
- ?
-
-
-
-
-
+ Installation and Setup
+Setup SSH keys
+SSH keys allow you to interact with your Git server without having to type your username and password all the time.
+ + +Installation and Setup
+Setup the Default Text Editor
+By default Git is set up to use Vim as the text editor.
+(esc + :q or :q! to get out of Vim)
+Follow these instructions to change your default text editor to whatever you prefer.
+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
+ 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.mdand 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
+Open README.md and make some changes to the file.
+$ 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
+Open README.md and add some new text
+$ 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.
+Open README.md and add some new text
+$ git add README.md
+$ git status
+$ git commit -m "Make a change I will soon regret making"
+$ git log --oneline
+ Okay, I see the change… now how do I remove it?
+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.
+Always pull before you push!
+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-resourcesrepository 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!
+ + +