Collaborative git

Previous: Solo git

Next: Functions, namespace, memory management

Required course material for the lesson

Powerpoint: Git
Optional - do you want to know more
Online: Coderefinery's introduction to git This is one of many git resources on the net.
Online: Markdown guide
Online: CI/CD - Continuous Integration and Continuous Delivery. It’s a DevOps practice used with GitHub/GitLab.
Resource: Example code - parsing command line options

Subjects covered

• GitHub - inviting people to your repo
• Git - branching, merging

Exercises to be handed in

Do the exercises in Python where applicable. Use git to track changes. Make one program per exercise (if relevant). Commit at least once per solved exercise - more often if you feel it relevant. At the end push everything to GitHub or more frequently if that is your pleasure - backup is nice. You gather all exercises into one file and hand that in on DTU Learn, hint cat in Unix. This is going to be the way we operate for large parts of the course.

Everybody has to create a new private repository for your collaborative exercises for this single lesson on GitHub as described in the powerpoint. One per student. If you work alone - make two. You can choose whatever name you like for the repository. Form a little group, preferably a group of two as the exercises are meant for two, but max three if a person is left out. Invite your fellow group member(s) to your repository. You are to "share" repositories. Be sure to exchange emails, so you can communicate after class, if you don't make all the exercises in class. After all, git is really meant for collaboration apart.
A less exciting alternative to forming a small group, is to create two local repos of your GitHub repository as shown in the powerpoint. You will then have to pretend to be two persons working together. However, you will have an opportunity to test more things with git and how it works as you have full control.

Generally the hand-in to each exercise is the program you made/fixed/updated, plus the git commands you used to manage the repo. This can be be made in one file with comments.

1. Copy exercise 9 from last week into your new repository and introduce an error in the exercise. Make it a real algorithm error, not just a syntax error.
   
   
2. Now switch with the other person: Download his/hers repo, fix the error, push it back to the repo.
   
   
3. First read and understand the Example code - parsing command line options. Now you have to make a program that can work with options. As more options are going to be added as the exercises progresses, better be smart and systematic about it from the beginning. The file input to this program will always be a tab-separated file, like ex1.dat. Make a program stat.py which takes a file name from the command line. There may be an option '-c <positiveinteger>' that denotes a column name in the file. The usage is therefore 'stat.py [-c <positiveinteger>] <filename>'
   If there IS an option -c the program should just read all the numbers in specified column (the number after -c option) into a list. If there is NO -c option, the program should read all numbers in all columns into a list - the order does not matter. There is no output (yet). Push to your repo.
   
   
4. Switch to your partners repo. You now must add an option and a function to the program to his/hers program. The option is '-a' and the function average should calculate the average of the numbers in a list. When using option '-a' the program should print the average of the list. Push the repo at least once when done or more often.
   
   
5. Switch back to your own repo. Pull so you know it is updated. Now add the option -m and the function median which computes the median number of the list. Upon use of the -m option the median number should be printed. Push.
   
   
6. This is about using branches to collaborate. First you and your partner decides who's repo is going to be used. It does not matter much because you are going to switch later. The owner of the repo adds the option -n and a function obs, that compute the number of observations in a list of numbers. Upon use of -n option the number is printed. You get it now. When adding an option and a compute function, you should always print the result of the compute if the option is used - not gonna say it again.
   Meanwhile the partner opens a branch in his/hers local version of the owners repo and add the option -b and a function biggest, that computes the biggest number in a list. The partner should merge the branch with the repo using the rebase method AFTER the owner has pushed the new function.
   When done you switch roles and repos.
   
   
7. This is about collaborating, not by using branches, but by planning who does what. You work on the same repo in your local versions. Again, decide on who is going to go first - you will switch later. The owner of the repo makes ready for the option -t and the printing if -t is used. The function is called trimmedmean and the partner makes it and only it. The function computes the mean (average) of the numbers in the list AFTER removing the 5% lowest numbers and the 5% highest numbers. Merge the two commits it in any order. There should not be any conflicts if done right. Switch roles.
   
   
8. This is what could happen, if you do not plan together, and do not use branches. Who goes first, you're gonna switch. Both of you add the -f option and the function frequent, which finds the most frequently occurring number in the list. The owner pushes first and the partner after. Now a major conflict has arisen. Solve it by the owner reverting the commit, and allowing the partner to push the final version. Switch roles.