GitHub
Daina Bouquin
daina.bouquin@cfa.harvard.edu
library.cfa.harvard.edu
software-carpentry.org
https://dbouquin.github.io/2016-10-12-cfa-git/
http://pad.software-carpentry.org/2016-10-12-cfa-git
https://guides.github.com/activities/citable-code/
Take a moment to read this through!
Getting started with Git Locally
git config
Setting/Unsetting a proxy (if you need to)
Creating a "Repo"
Repository = directory of files where git stores versions
The .git directory is where your "commits" are stored
files in the directory that Git isn’t keeping track of
Then we check the status again
We need to tell git to track the file (staging)
Git now knows that it’s supposed to keep track of mars.txt, but it hasn’t recorded these changes as a commit yet.
We need to write a "commit message"
and commit the changes
laugh - http://whatthecommit.com/
xkcd
" ... "
Commit messages are important!
lists all commits made to a repository in reverse chronological order.
It is good practice to review changes before saving them.
This shows us the differences between the current state of the file and the most recently saved version:
-
How can I identify old versions of files?
-
How do I review my changes?
-
How can I recover old versions of files?
Refer to the most recent commit of the working directory by using the identifier HEAD.
“head minus one”
“head minus two”
Can also look back using the ID
We only need to type the first few characters though
All right! So we can save changes to files and see what we’ve changed—now how can we restore older versions of things? Let’s suppose we accidentally overwrite a file:
In this case, we’re telling Git that we want to recover the version of the file recorded in HEAD, which is the last saved commit.
If we want to go back even further, we can use a commit identifier instead:
Don’t Lose Your HEAD
If you forget mars.txt in that command, Git will tell you:
“You are in ‘detached HEAD’ state.”
In this state, you shouldn’t make any changes. You can fix this by reattaching your head using git checkout master
What will the cat display at the end of these commands?
Ignore stuff
make a directory full of files we don't want to track
Tracking these files would be a waste of disk space and be distracting
So create a git ignore file
We should track our .gitignore file so everyone else can ignore the same files
Remotes
Putting our work on GitHub
Create New
We need to connect these two repos
Copy the link to the new empty GitHub repo
For this workshop we're just using the HTTPS protocol
[link to repo]
"origin" is the name of the remote
Make sure they match
In this section we learned about creating a remote repository on GitHub, but when you initialized your GitHub repo, you didn’t add a README.md or a license file.
If you had, what do you think would have happened when you tried to link your local and remote repositories?
Adding Collaborators - then can make changes too
Add someone to your repo as a collaborator for this exercise
Clone
Conflicts
Stay in pairs for this exercise
- Currently, the repos are the same for both partners
-
Add different lines to both partner's copies of mars.txt
-
Partner 1 pushes to GitHub first
-
Then partner 2 tries (GitHub will say no!)
Conflict!
What we have to do is pull the changes from GitHub, merge them into the copy we’re currently working in, and then push that up to GitHub.
This is where the conflict is!
Shows us the conflict
Our change—the one in HEAD—is preceded by <<<<<<<. Git has then inserted ======= as a separator between the conflicting changes and marked the end of the content downloaded from GitHub with >>>>>>>.
It is now up to us to edit this file to remove the markers and reconcile the changes.
We can do anything we want: keep the change made in the local repository, keep the change made in the remote repository, write something new to replace both, or get rid of the change entirely.
Make the changes you want, then....
git add mars.txt
git status
git commit -m "Merging changes from GitHub"
git push origin master
Forks
Different from a clone - clones are just copies on your local machine
A fork is the start of your own branch on someone else's project
pull requests
https://github.com/dbouquin/practice_fork
Click "Fork" to create your own remote copy of my repo
-
clone your "Fork" to your local computer
-
git clone [fork link]
-
-
Add the "upstream" link
-
git remote add upstream [link to original]
-
- Push commits to your Fork
- Pull from the upstream repo
- Click "Pull Request" to submit changes to the original repo
Read up on Licenses!
http://swcarpentry.github.io/git-novice/11-licensing/
GitHub
By Daina Bouquin
GitHub
Presentation used during a workshop at the Harvard-Smithsonian Center for Astrophysics. Oct. 12, 2016
