Exercise 01: Git and Markdown with a Practical Application
Pre-Lab
- Sign up on GitHub if you haven’t already done so.
- Github translates markdown files automatically to HTML - That’s how the README.md files you see in most repositories work. Read through the GitHub Flavored Markdown documentation.
This exercise is for getting aquaintained with git and github (and markdown) with the practical application of creating online notes collaboratively. This gives you the opportunity to practice using git and github collaboration features with a bunch of plain text files before moving on to managing heaps of source code.
Assignment
Create a Note Repository
Last week, you collected a lot of information and learned to use a couple of new tools. The assignment is to build up a git repository containing a compilation of your notes.
Possible subjects are
- text editor review with link list (which one do you use and why)
- UML drawing tools review
- List of important Command Line Commands
- Ruby and Rails Installation Experiences and Tipps
- important git commands
- (optional: most important Markdown syntax)
Build Teams, create a repository within each team and add the team members as collaborators on github. The team size is up to you - it has to be at least two, the more you are the less documentation each of you has to write, but the cooperation overhead increases, too. To pass this exercise, a reasonable number of commits has to be from your account.
First Round of Notes
Divide the topics above between you and start writing notes each. Usually it’s not a great idea if two people work on the same file at the same time.
If you have notes from last week that you can just copy/use, that’s great. Feel also free to copy parts of my instructions - the licence allows that, if you state the source.
Second Round
Start exchanging the files using git and github. That is, commit your changes locally and then push them to the github repository, after pulling changes from the others.
Merge Conflicts
If you feel confident exchanging files with git and github, deliberately create a merge conflict and resolve it. Each one of you should have resolved a merge conflict - you’ll be happy that you’ve done that before if you happen to get huge merge conflicts the night before the deadline of a project.
Pull Requests
Last, exchange the repository urls with another team. You can just swap them, or exchange them in circles.
Review the notes of the other team (by looking at the repository online, then forking and cloning it). Each of you should send the other team at least one pull request. Always create a new branch for a pull request. Send the other team enough pull request such that each team member can merge a pull request.
Lab Report / What to turn in
Write up a report describing your experiences sharing files with git and github. If you’ve created a note page in your repository listing the git commands you used you can refer to that.
List the names of all people on the team together with their github handles and include the link to your github repository.
You can do your writeup as PDF or markdown file, one for each team is sufficient. If you choose a markdown file, you can copy it or its url in “Texteingabe online” in Moodle.