Open Source Comes to Campus/Curriculum/Git/Students

Visiting the project on the web
Since this project is a website, we've specially configured the repository so that whenever there is a push to it, it is made visible on the web.

If your group's repository is called e.g. waffle-castle.github.io, then you can see that the shared version is visible on the web at http://waffle-castle.github.io/. (This is just an example. Your group's repository page should be at schoolname-#.github.io (for example, princeton-1.github.io or princeton-2.github.io.)

But note that any changes in your fork won't show up there until the maintainer of the project merges those changes in.

To fork a project on Github

 * Start out logged in to Github


 * Visit the project you want to fork


 * Click the "Fork" button in the top-right


 * Wait for the animation to conclude


 * Notice that your browser is now visiting a copy of the project in your personal space, rather than the old, group-owned one. You should also see a "forked from..." remark in the top-left.

Now, clone to it to your computer

 * On the right side, look for the clone URL


 * Copy that to the clipboard


 * Open a terminal and type:  (including the spaces, but not including the quotation marks)


 * Use your terminal to "paste" the URL in. (Make sure it starts with ; if not, you'll need to use an ssh key and most students probably won't a key already set up)


 * Press enter to do the " " operation.


 * Once you've done that, " " into the directory.

Make sure you have the project properly set up

 * Open index.html in your favorite text editor -- it should look like a regular HTML page


 * Open index.html in your favorite web browser -- it should render basically the same as http://purdue.openhatch.org/


 * Make a test change in index.html, save, and reload in the browser. Make sure what you see in the the browser reflects that change.


 * Undo that change, with your editor, save, and then reload in the browser. Make sure what you see in the browser reflects that change.

Find a task
Now, find a bug on the project's issue tracker that you will work on, and claim it by leaving a comment on the issue saying so.

(Before you do that, make sure to refresh the page and check that no one else has claimed it while you were reading and deciding.)

Resolve the task
How you do this depends on the issue you've chosen. If you run into a problem you can't seem to solve, try asking the student next to you or one of the mentors.

Make sure to open up index.html and check that your solution works.

Commit and push
Once you're finished making changes, you can use the following command to get a list of files you've changed:

git status

You can commit your changes by typing "git add" followed by the files you've changed, for instance:

git add index.html

Once you've added the changes, you can "commit" them with a message specifying what you've changed.

git commit -m "Explanation of my changes"

Now, publish those changes on Github by typing:

git push

You will be prompted for your username and password. (If you find constantly entering your username and password annoying, there's an alternate method we can show you called SSH.)

(Alternatively, you may be prompted to set your name and email address. This means you missed a step in setting up git.  No worries, you can set them now.)

You can now visit Github and make sure your personal fork contains those changes.

Create pull request
Visit your personal fork and click the "Pull requests" button on the right. This will offer you the chance to make a new pull request by clicking on "New pull request". Explain what you did, and make sure to include a comment stating which issues it addresses, so that it automatically closes the issue. (You can see here for details on how to do that.)

Now, get feedback from the project's maintainer (the mentor leading your group) and eagerly await your pull request getting merged!

Once merged, visit your changes on the web
When your changes are merged into the main project repository, our specially configured repository will update the group website with the merged files.

This is a special trick that we do during the Website editing with git exercise, using Github Pages. It demonstrates that when the merge happens, it can programmatically cause a different event; this is often called hooks.

Advanced/Optional Commands
(This section is in progress.)

Setting multiple remotes
The copy of the repository you have on your computer is called your "local" copy. The copy on Github is a "remote". You can see what remotes are associated with your local repository by typing the command:

git remote -v

You should see something like this: origin https://github.com/$yourusername/$your-repository-name (fetch) origin https://github.com/$yourusername/$your-repository-name (push)

Origin is the default name for your remote repository. The urls you see should correspond to the urls used in the "git clone" command above. Right now your only remote is your personal copy of the repository. That's fine for pushing changes, since you need to go through the personal copy to submit pull requests. But what if you want to get an up to date version of the main repository? To do this, you'll need to add the main repository as a remote.

To do this, type:

git remote add $name $url

Replace $name with whatever you want to label the remote, and $url with the github url for the main repository. When you do the "git remote -v" command, you should see that you now have two sets of fetch/push listings. To get an updated version of the main repository, you can type:

git fetch $name git merge $name/master

To update your remote personal repository, you can type:

git push origin master

If you try to update the main repository directly, by typing:

git push $name master

You should get an error, as you don't have push access to the main repository.

That's it! You can add as many remotes as you'd like, although for the most part people stick to one or two.

Resolving Merge Conflicts
Your instructor should have showed you what she sees when you submit a pull request. Probably you saw a message from Github saying that the pull request could be "merged automatically". That means that you managed to avoid changing a part of the project that someone else also changed. Yay! That's how we designed this activity. But what happens if you do change the same part of a project as someone else? It generates what we call a "merge conflict".

(A brief thought experiment to explain merge conflicts: let's say there's a repository with a single file that says, Hello [celestial object]! If you change that to Hello world! and submit a pull request, you're creating a diff which says: change "[celestial object]" to "world".  If someone else copied the repository at the same time as you and changed the same line, they might create a diff which says change "[celestial object]" to "galaxy".  If you make your changes to the repository first, it now says Hello world!, so when the other person says change "[celestial object]" to "galaxy" the repository does not see [celestial object], and flags that there's a conflict.)

To induce a merge conflict in this activity, go to the main github repository and find a change that has been made since the last time you copied the repository ("git clone" gets a copy, as does "git fetch" and "git pull"). Make a change, locally, to the same line. Add and commit those changes.

There's two ways that this merge conflict can be solved. You could push your changes to your remote copy, then submit a pull request to your instructor. When viewing the pull request, they would be warned that changes could not be merged automatically:



And would follow the instructions github helpfully provides to merge the changes:



This involves some concepts like branching, which we haven't gotten to yet.

Alternatively, you could fix the merge conflict yourself. To do this, you'd need to get an up-to-date copy of the remote repository. To do this, type:

git fetch [url of main project]

(If you do not have the main project as one of your remotes, see the above section on multiple remotes.)

This gets a copy of that repository. Now you need to merge that with your local changes.

git merge

This should result in a conflict. There are a number of tools you can use to help visualize merge conflicts. For simple conflicts, though, I like to use a basic editor, such as nano, vim, emacs, or whatever you're most comfortable with. In basic text view, a merge conflict looks like this:



To resolve the conflict, scroll through the document until you find sections with these markings. The "========" line separates the two options that are in conflict. Choose which one you want to keep by deleting the other. Then delete all of the markings. Do this for each conflict and then save and exit the file.

Congrats! You've resolved the conflict! You can commit your changes by: