We will be using this Github Repository for homework submissions. You should have already set this up in the morning!
To submit exercises for Day 1, add and commit your changes via the command line, push to your remote repository by typing in git push origin master in the command line, and then create a pull request on Github.
To create a pull request, navigate to your forked repo on Github, click the green button on the left, and follow instructions. By creating a pull request, you are letting the owner of the iExperience repository know that you want to merge your changes into the main repository.
To prepare for tomorrow's class, please read Chapters 2-7 of Learn to Program. Make sure that you save this to your local folder! This part is really important and will be really helpful to you tomorrow ;).
During this course, we'll use Git and GitHub extensively to save and share our work. But what exactly do they do, and what's the difference between the two?
The first thing we need to remember is that Git and GitHub are not the same thing. Git is a version control system that locally tracks your changes. Git does this by taking "snapshots" of your code (which Git calls commits) and then storing these commits in Git repositories (or repos). GitHub is a website that allows you to save your repos online and share them with other people.
If you aren't 100% clear on what this means, don't worry! Over time you will develop familiarity with both Git and GitHub and you'll soon be using both like pros.
Let's start by walking through the steps of creating and linking a repo to GitHub, paying special attention to which product (Git or GitHub) each command is targeting.
git init: The first thing we do after creating a project file is to initialize (init) a local Git repository in that folder. This creates a hidden .git folder that locally, i.e. on your computer, tracks changes made to the project.
git init has nothing to do with GitHub.git add .: Next we add the changes we have made to the staging area (the period in this command is shorthand for all, i.e. add all changed files). You can add files individually by name as well, e.g. git add file1. Remember to add a file before running this command if the folder you've just created is empty. At this point you may be wondering whether your changes have been saved. They have not! The staging area is like a loading dock where you can decide which changes you want to ship (commit). We still need to ship them.git commit -m "Your message": After choosing which files we want to commit using git add, we run the git commit command to save our changes to our local repo. Once we start having more commits, or our project has collaborators who also submit commits, we may want more information on the changes in each commit. Git allows us to do this by attaching a message with each commit. If we just run git commit, Git will open up a space where we can type our message. By adding the -m to our command, we can immediately add our message inside quotation marks. Commit messages are so important that Git actaully enforces their use, i.e. you cannot submit a commit without a message! Our changes have now been saved in our local Git repository. Let's move on to GitHub...git remote add origin https://github.com/username/reponame.git: Up until now, all our Git commands have solely been targeting Git on our computer. We now want to link our local repo with a remote repo on GitHub. First, create a repo on your GitHub account. The git remote add origin command links our local repo with a remote repo on Github. Our first steAfter creating a repo on your GitHub account you can navigate to the repo page to see a list of instructions for linking the two repos. GitHub provides the URL you need to use in your command at the top of this page.git push origin master: We're nearly there! The last thing we need to do is push our locally stored commits to GitHub with the git push command. The origin part of our command refers to the original remote repository. We will use this repository almost exclusively for this course. The master part of the command refers to the branch we are currently working on. Again, you will predominantly be using the master branch in this course. Check out GitHub's documentation if you want to learn more about using branches.Congratulations! You've succesfully created and linked a GitHub repo!
So, you've linked your repos and successfully pushed your content. But now you make some changes and want to push these to GitHub. Which of the above commands do you need to run? To figure this out, all we need to do is take a closer look at what the commands are doing.
git init initializes a repository in your project folder. We only ever need to intitialize a repo once, so we don't need to run this.git add .? This command adds changes to the staging area, so yes, we need to run this command.git commit commits these changes to our local repo, so we also need to run this.git remote add origin. This command links our local and remote repo. Once we've linked our repos, we don't need to do it again. So we don't need to run this command.git push. This command pushes your stored local changes to your remote repo. We need to run this command every time as well.Git and GitHub are immensely powerful tools. The more time you spend learning about them and how they work, the more you will be able to get out of both products. Below are some extra commands that may come in handy:
git status: If you're ever unsure about what's going on with Git, simply type git status to see the current status of your Git repository (or even if the current folder has a Git repo associated with it).git diff: Shows unstaged changes made since your last commit.git rm file1: Even though you can delete a file from a Git repo outside of the console, i.e. using Finder, it's better practice to delete the file using Git. If you don't do this, you'll find that git add . will not add the deletion to your staging area. You will have to run ...git add -u: Adds deleted files to your staging area.git log: Show recent commits, most recent on top.git clone https://github.com/username/reponame.git: In order to have a copy of some repo on github on your local machine, you use the git clone command. You can make changes to this local copy, and can follow the usual git commands to push your changes to repository on github. Let's say you changed a html file. In your terminal, you will cd into this newly cloned repo, type git add . , next git commit -m "message" , and then git push origin master. The changes on your local machine will then be updated to the cloned github repo.GitHub pages is a great service offered by GitHub. It allows you to host public webpages through GitHub for free! Creating a GitHub page is easy. Start by creating a new repository named username.github.io on your GitHub account, where username is your username on GitHub. Remember that the first part of the repository has to match your username EXACTLY (it is case sensitive). After you've created your repo, simply follow the normal steps for linking your local and remote repo, and that's it! You get one GitHub Pages site per GitHub account and unlimited project sites.
If you've ever tried deleting a repo on GitHub, you'll notice that it's far from simple. This is done purposefully. GitHub's philosophy encourages changes but not deletions, and deleting an entire repository should only ever be viewed as a last resort. Also remember that many Git files remain hidden from you. When you delete repositories, you are also deleting information in these ninja .git files that may have unintended conseqeunces down the road.
Uh oh! Two people changed the same code.
<<<<<<<< HEAD
# this is my latest change
hobbit = Ringbearer.new(50, "Bilbo")
========
# this is the conflicted (existing) change
hobbit = Ringbearer.new(35, "Frodo")
>>>>>>>> Updated ringbearer to reflect modern history
Fixing merge conflicts is called resolving.
What does it mean if my changes were 'rejected'?
$ git push
To https://github.com/iExperience/iExperience.github.io.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to 'https://github.com/iExperience/iExperience.github.io.git'
Updates were rejected because the remote contains work
that you do not have locally. This is usually caused by another
repository pushing to the same ref. You may want to first integrate
the remote changes (e.g., 'git pull ...') before pushing again.
Someone else has made changes to the remote repository that you don't have yet.
$ git pull
