Shiffman - 1.1: Introduction - Git and GitHub for Poets
Shiffman - 1.2: Branches - Git and GitHub for Poets
Shiffman - 1.3: Forks and Pull Requests - Git and GitHub for Poets
The rest of this series outlines additional features of Git and GitHub that are beyond the scope of this class, though very useful!
By now, you're quite familiar with the process of updating your own repository and publishing it to the web with GitHub. Git is a software that provides us with version control, so rather than needing to create multiple versions of our creative output, we can just iteratively make commits, and Git will store those versions for us (let's take a moment and look at your assignment repo's history). Google Docs and Dropbox do this as well as GitHub, but GitHub is a web service that provides multi-user support for Git.
One of the most important features of GitHub is its support for multi-contributor repositories. We'll need to use these features in order to collaboratively work on our final projects.
For the previous assignment, one member of your group was tasked with creating a new repository for the final assignment. The repository should contain some code (presumably your proof of concept, including an index.html file), and all group members should be added as collaborators. Under the Settings tab, the repo owner should create the GitHub page for your final project.
When you accept the invitation to collaborate, you should see a banner that says you now have push access to the repository. Click "Open in GitHub Desktop" to automatically clone the repository onto your local drive. Make sure you pay attention to where the local directory is saved. Open your local repo in your text editor and make a small change to the code. Make sure you can push your changes, and verify they are reflected on the project webpage. Let's take a moment to make sure all groups are able to do this.
The above methods allow for the possibility of two people working on the same file at the same time, then pushing conflicting versions of that file. GitHub has a lot of smart ways of resolving such conflicts, but we can also structure our workflow with branches. You can think of branches as simultaneous variations of the code. If I want to try adding a new feature to my project, there's a bit of risk involved. It's possible it could interfere with other code people have written -- maybe we accidentally used the same variable name twice, for example.
One way I can mitigate that risk is to create a new branch, and write my code there. For example, if I want to add a search feature to my project, I might create a new branch in GitHub Desktop (Current Branch - New) and call the new branch "search-test-nm" or something like that, indicating the reason for the branch and the author. I'd then write my code within that branch. I might work on it for several days, and commit my code several times per day. Finally, once I've got that feature working, I can merge it into the master branch. The master branch sould always contain the most recent, functional code, and should be the branch that serves the webpage. You can visualize this process as a branching structure, where branches are sometimes merged back into the master "trunk". Let's create a new branch for each person in the group.
When it comes time to merge files, we need to create a "Pull Request" to the owner of the repository. The pull request is kind of like saying "I made these changes in my own branch, will you please pull them into the master branch?" Once you've made some changes on your personal branch, commit those changes and push them. Then, on your repository dashboard, click "New pull request". This will allow you to merge your branch into the master branch (or any other). It will flag any conflicts and ask you to resolve them. Let's take a moment and make sure we can make new branches in our group repo, add new commits, create pull requests and merge branches.
This is a bit beyond the scope of the class, but useful information for if you ever want to contribute to an open source project on GitHub. Forking a repository means you make an instance of a repo from someone else's account, including their branches and commit history. You can add your own branches and eventually create a pull request to have your contribution merged back into the master branch. For example, I could fork the repository that contains the p5 library, add new functionality to p5, and create a pull request to have that new functionality become a part of the library.