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

  1. Currently, the repos are the same for both partners

  2. Add different lines to both partner's copies of mars.txt

  3. Partner 1 pushes to GitHub first

  4. 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/

Made with Slides.com