Get a jump on the day and install git now!
Girl Develop It is here to provide affordable and accessible programs to learn software through mentorship and hands-on instruction.
Tell us about yourself.
Git isn't simple. Like most powerful tools, it's complex and takes some time to master.
Version control allows you (and your team) to do two powerful things
Create anything with other people, from academic papers to entire websites and applications.
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?
Rainbows and bunny rabbits!
1990s -- CVS (Concurrent Version Systems)
2000s -- SVN (Apache Subversion)
2005 -- Git (well, Git)
Examples: CVS, SVN
One central server, each client (person) checks out and merges changes to main server
Examples: Git, Mercurial
Each client (person) has a local repository, which they can then reconcile with the main server.
Goals of Git Design
Configure Git with your name and email
# I'm a comment! Don't enter me in command line. Do enter lines that start with a $, but don't type the $. $ git config --global user.name "Your Name Here" # Sets the name git associates with your commits $ git config --global user.email "email@example.com" # Sets the email git associates with your commits $ git config --list # Shows your configuration settings
An SSH key is like a secret handshake between your computer and Github. It allows Github's servers to verify your identity via public-key cryptography and challenge-response authentication- not via you typing in your Github password. It's super secure and not too difficult to set up.More info about SSH keys.
# change to root/home directory cd ~ #or cd Users\username # create and move to a "working directory" mkdir my-repo cd my-repo #initialize directory as a Git repository git init
Create a new hello.txt file in your my-repo directory, then check repo status
touch hello.txt git status
Tell Git to track our new file
git add hello.txt git status
File is now tracked by Git!
Open hello.txt and add some text, then check your git status
Stage and commit the change
git add hello.txt git commit -m "Added first file to repository."
How is this all different than just saving a file?
git log commit [SHA HERE] Author: Your name
Date: [DATE HERE] Added first file to repository.
Cool! We'll be using that SHA later...
Always read the output of running git commands. They may look a little intimidating, but they contain all sorts of useful information. When in doubt, run:
This is the general workflow in a Git repository
git init #just once, to initialize #do some stuff to files git status #what's up, git? git add [filename] #stage changes to a file git commit -m "" #commit a set of changes git status #what's up, git?
If you've added some new text to hello.txt, but not yet staged it, just run:
git checkout hello.txt
hello.txt is reset to its state at the last commit - your changes are gone!
If you already staged hello.txt, run:
git reset hello.txt
hello.txt is no longer staged, you can make whatever changes you like to it, and re-stage when it's ready.
If you've already staged hello.txt, but want to delete it instead, run:
git rm -f hello.txt
The file is deleted, and its deletion will be part of your commit.
If you've made some changes to hello.txt and staged it, but want the changes to disappear, run:
git reset hello.txt #unstage git checkout hello.txt #reset
hello.txt is unstaged and reset to its state at the last commit - your changes are gone!
If you've made changes and committed them, you can revert all the changes that happened in a specific commit by running:
git log #shows log of commits git revert [SHA] #undoes specified commit
This doesn't have to be your most recent commit- you can revert any commit. It will just undo the entire set of changes that were included in that commit.
You can roll back your repo's state to where it was after any previous commit by running this with the SHA of the commit you'd like to reset to:
git log #shows log of commits git reset --hard [SHA] #resets repo
This rolls back all changes since the specified commit - be careful! This isn't often used in real life.
Create a new branch called feature_1
git checkout -b feature_1
Make a change to hello.txt, then add and commit.
See all branches. Branch with * is active.
Switch to the master branch.
git checkout master
You'll notice the changes from feature_1 branch aren't there.
Switch to master and merge in the feature_1 branch
git checkout master git merge feature_1
Now if you check out hello.txt, you'll see the changes you made in the feature_1 branch.
*rebase is another option, but will not be covered in this workshop
Change first line in hello.txt in master branch, then add and commit it.
Then switch to the feature_1 branch and change first line in hello.txt, and add and commit it.
Merge the master branch into feature_1 branch
# on feature_1 branch git merge master
You will be notified of a conflict. Go to the file, fix the problem and delete the helpful comments Git added. Then commit your edits.
Note: somtimes, conflicts cause the files to automatically open in the Vim text editor. It looks just like a terminal window and has no obvious way to exit. Don't panic. Just type :q[enter] to exit it.
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.
Copy SSH link from Github repo
# from inside your local git repo git remote add origin [pasted link from Github] git pull origin master #pull first, when creating connection git push origin master #push your local work to the repo
As you make changes locally, push to Github.
Make a change to your README file, then add and commit it. Then, push!
git push origin master
Go check out your Github repo online to see your changes.
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
#pull current state from Github git pull origin master # fix any conflicts (see merge conflicts above) and commit # then, push local changes to GitHub git push origin master
Go to https://github.com/cherimarie/GitResources and hit the fork button.
Go to your GitResources repo on Github, find this link and copy it.
Navigate to the location you want new directory to be in- NOT INSIDE ANOTHER GIT REPO! Then, clone to get a local repository of your fork.
git clone https://github.com/username/FORKED-REPO-NAME.git cd FORKED-REPO-NAME
The 'git clone' command does a lot!
Add a remote connection to the original repository, so you can stay up to date with their changes:
git remote add upstream https://github.com/original-username/FORKED-REPO-NAME.git # creates a remote connection, called "upstream", to the original repo on Github git fetch upstream # Pulls in changes not present in your local repository, without modifying your files
git add . git commit -m "Add great new resource" git push origin master
Visit your Github repo page
Fill out the form with a polite, helpful description, and submit.
How to manage pull requests is out of the scope of this short workshop, but you can learn more from the Github Collaborating Tutorials