Change to teaching version control via only Github

[iamciera]

Collaborative Version Control via only Github

These are my notes on my experience showing people Git collaboration through only Github. The files were never put onto their own machines so a lot of the problems that occur from using different operating systems was erased. Overall it was the smoothest time showing people Git and people were generally excited about it. It was an informal group of about 8 people, so very small, easy to handle.

The Activity

Everything is isolated to a README.md file. The activity goals were 1. Intro to Git and Github, 2. allow them to share ways in which they organize their work, and 2. allow them to practice Markdown syntax. I chose organizing their work as a subject matter because I wanted them to get tips from each other and generate discussion. I was with mostly molecular biologists, so the activity encouraged non-computational organization too. I felt asking for how they organized their computational work might intimidate them. Also, I love talking about notebooks!

Intro After showing them how our rrhack group collaboratively made our curriculum material, I discussed motivation and general outline of version control ect. Then went straight into activity.

Total time spent: 2 hours, but we were all pretty chill and experimenting a lot. Could be less.

Steps of Activity

• Sign up for Github
  • Introduce the main features of the home page.
• Create new repository. Call it work-organization-yourName. In the details write "tips to organizing research".
  • make sure they initiate a README.md file. They must include their name, because with forking, things get confusing fast. Once the repository was created, I again showed them around the page, highlighting that they have made one commit with the addition of the README.md file and explained that all that they are looking at is a directory with one file.
• Edit the file. Click on README.md, then click "edit this file".

• Then I had them write directly into the readme.md file this information:

  • Name?
  • What kind of scientist do you you tell people you are at dinner parties?
  • In the past month, what are the three main activities you have been doing at work?
  • What are the three most important tools/strategies you use for organizing your work?
  • If you could go back 3 years ago and tell past self only one thing about productivity at work, what would it be?

  I also required them to use at least one hyperlink, bullet point/number set, header, and display at least one picture to practice markdown. Do guide them to the preview changes option to help them along. I gave them around 20 minutes to finish this.

• Commit.
  • Talk about commit messages.
  • Show them where the repository is. Show them the repository has a url address that is composed of their user name and repository name.
• Have them make one more commit, this time they create one question to ask.
  • This also adds uniqueness to their repository content, as when they switch with their partner, things start looking very similar and might get confusing.
• Fork a partners Github repository.
  • The easiest way to have them find each other is typing directly into url. The search for user option only works if they verified their address through email and many times they do not.
• Edit forked repository by pasting in their questions below the originals. Commit.
• Create Pull request.
• Accept pull request.
• Find new Partners and repeat.
• Look at cool Github features.
  • Look at Blame, Issues, Wiki, Repo graphs, ect.. Show another cool repository example, like maybe the ggplot repository.
• Get excited about collaborating on Github.

Of course afterward I had to reiterate what they are not doing. I gave them the references on how to learn more AND repositories to practice. I have one here I started last year and maintain with two friends: https://github.com/TheCodingCollective/quotes to let people practice. Also, it might be fun to start a large rrhack practice repository where they can contribute to after the exercise.

Thoughts?

[hlapp]

I like the limited set of technologies (essentially, web only) involved here, which cuts the potential for misbehaving or gone awry software installations and client differences to zero. Also, we can see how easy it is to get started, to document (commit message), to identify (commits), and to collaborate using pull requests (which means another layer of documentation, and remaining in control, in contrast to just giving others keys to the house). We could add tagging (from which it is a tiny step to versioning) as a step up to identifying commits. And perhaps generate a merge conflict and then the instructor demos how to resolve it (rather than have students do that, which would require command line).

[kcranston]

I wrote a lesson for teaching git with GitHub-only and taught it at the Duke Marine Lab workshop.

Pros:

• no installation issues!
• the fork & PR worked surprisingly well, without any major glitches

Cons:

• students seemed frustrated by not seeing how they would use this on their own machines

Given the length of time that we spend on git, I think teaching how to use git on your own machine is more important that teaching forks and pull requests (everyone collaborates with themselves, and not everyone has collaborators using github). Not saying we shouldn't show collaboration, but teaching that instead of a personal workflow seems out of order.

Perhaps git in RStudio?

[hlapp]

Thanks @kcranston for creating the instructor notes. I think that and the feedback as well as opening #7 completes this issue, so I'm going to close it.