coderefinery/github-without-command-line

Collaborating and sharing using GitHub without command line.

Collaborating and sharing using GitHub without command line

Licensed under CC-BY.

Currently the best way to give credit is to list your derivative work here: https://coderefinery.org/lessons/reusing/

But we are working on making these lessons citable: https://coderefinery.org/blog/2021/11/21/towards-citable-lessons/

Similar workshops which serve as inspiration

• https://github.com/lexnederbragt/github_collab_workshop
• https://github.com/arockenberger/github_collab_workshop

github-without-command-line's Issues

More about citations

Good material about citation.cff in https://cicero.xyz/v3/remark/0.14.0/github.com/coderefinery/research-software-engineering/main/presentation.md/#46 up to 48

And more links to quick reference
https://cicero.xyz/v3/remark/0.14.0/github.com/coderefinery/research-software-engineering/main/presentation.md/#49

Also this optional step in https://coderefinery.github.io/github-without-command-line/creating-using-web/#step-6-adding-a-license-to-an-existing-repository could be in https://coderefinery.github.io/github-without-command-line/doi/

Are the title cards on top of Markdown used at all?

If not I guess we can remove them?

Fetch on GH Desktop can do more than fetch on command line

If you "fetch" changes on GH desktop and they are fast-forward, they got automatically merged/pulled to my surprise.

Image borders are ignored

Probably we should use Markdown/Sphinx syntax anyway instead of HTML.

Explain clone better/clearer

"do i have to download each file one by one?" - me explaining cloning was not sufficient. So make this point a bit clearer

basics: add picture

• include description of what the things mean e.g. "fork (different people working on it)"
• one that shows a merge commit (between fork and master?)

Add citation guidance?

Hi! I've found these materials really useful and would like to reuse some of them, but it's not really clear how to cite them. Would it be possible to add instructions on how to do that? Thank you again for creating this resource 🤩

I ended up creating instructions on my own

They are mostly in Finnish
https://hackmd.io/@MatiasJJ/GitHub-koulutus

Main difference: people do their own shared repos

Creating repos: "discussion" not really clear what to do there

proposed lesson based on this material be added to Carpentries Incubator

Hi there Code Refinery folks, a year or so ago I forked this really wonderful lesson in order to teach it as part of a Carpentries workshop at the Smithsonian. Since then, the Smithsonian lesson (https://github.com/MikeTrizna/github-without-command-line) has changed quite a bit, and someone made the suggestion that we generalize it a bit to contribute it as part of the Carpentries Incubator series.

I just submitted the proposal here: carpentries-incubator/proposals#166. Would you all like to be added as maintainers? Also I want to be very clear that the lesson started as a fork from this Code Refinery lesson, so please let me know how best to make that attribution (in addition to the ones that are already in the README and intro).

Also, please let me know if you are opposed to this. I'd be happy to rewrite a few episodes from scratch to be completely original. You can also email me at [email protected], if that makes more sense.

Thanks again for creating such a great lesson!

Update figures/text in DOI episode

Working on it ...

Install instructions for macOS

Some (all?) participants using macOS were confused not finding GH Desktop on the lanchpad but found it in Downloads.

basics: add more example to "interesting repositories"

• add documentation example
• paper example where a paper was written on latex/git
• book examples written on github

branch protection instructions could be somewhere else

In introduction, discuss the concept of "individual-based" vs "group-based" data/work

Perhaps at the beginning, when framing why to use git at all, we can talk about how work goes better when you switch to a group-based access model where shared access is the default, instead of everything fundamentally owned by individuals who manage sharing as-needed. Without this idea, the point of "git for a group" is a lot harder to get across. Then, say, "with git you can easily have collaboration be the default". (I guess this is a similar argument to web-based cloud storage). Do you think this is useful to say, and do we make it?

This would be parallel to the idea of "track changes for yourself", perhaps after it.

Idea from reviewing #41 where it mentioned group-based repos.

Add illustrative example comics to the intro/basics

Eg. xkcd or phdcomics

creating-using-desktop: planned changes

• first option: download file from github. Hide full link/github interface to prevent people from thinking this is the first choice for downloading. But allow people to make their own data, too.
• mention that one can share existing projects also via web
• after we have fetched origin in step 6 can we see the network somwhere to see what happened?

creating-using-web: planned changes

• Make the recipe copyable
• Show how to verify that we are on the right branch in step 4
• step 4: explicitely say the point of looking at both branches
• main room follow-along with pauses and Q&A, no BO rooms yet

Better explanations on Git and GitHub

A little bit more illustrative explanation especially for git

Code documentation guidelines

add in quick reference
RB's slides if nothing else?

new episode: how to organize a group's work

• github organizaitons (should i start a repo under my account or open a new org?, should i add everybody as collaborator?)
• github vs gitlab?
• permissions
• PRs vs direct commits for types of projects
• small vs large changes

Add timings to episodes index

Broken link

Thank you for this awesome resource ✨

It seems like the link to the licence is broken?

General question on lesson workflow and timing

• Title: Why do you say "Almost no command line required". Is command line required at all?

• Apart from the title (see comment above), I like how the lesson is organize with 4 sections (motivations, repo creation, collaboration within the same repo and with fork).

I don't know how non-technical are the attendees so my comments may be irrelevant. But you tell me...
Overall the lesson may be a bit too long (1h30 including time to seat, connect to wifi, etc.).

1. Introduction and motivation: I understand the logic but starting from "what is a commit" is a bit weird.
   I am probably rather classical here but I would start with:

• What is version control? (and then I like the way you explain snapshots)

• Why version control is important?

• Git and github (and I like how it is explained in the lesson).

I would forget tags and branches in the intro.

2. Creating a repository on GitHub and recording changes

I would forget branches too. I don't think there is enough time to cover this part. But I may be wrong...

3. Collaborating on a project within the same repository

I would work in pairs (that's what we do at UIO and it works pretty well). It is simpler to organize.

4. Collaborating on a project using forks
   Important section so we need to make sure enough time is dedicated to this part.

Some more links to the Quick reference

• The turing way: A great general resource on reproducible, ethical and collaborative data science
• How to make repo private/public
• All CR lessons
• CR material on readmes
• good readme info

Mention that one can share/track tex files

One participant was positively surprised by this.

Mention permalink

some instructions to create and share permalink eg. in Quick reference

https://cicero.xyz/v3/remark/0.14.0/github.com/coderefinery/research-software-engineering/main/presentation.md/#13

contributing: planned changes

• example:
  - recipe book
  - one longer text (concat some recipes from tacofancy with blanks)
  - https://github.com/sinker/tacofancy
• non-talking instructor prepares a conflicting commit during session (check what the first PR does)
• conflict can be shown as demo
• consider using dark/light mode in github to change roles
• mention "pull request" in page or section titles more

Few things I don't want to forget

• good commit message
• diff after edit
• adding collaborators
• sending PR with a typo and fixing the PR with a commit
• conflicts?

Improve quick reference

• show how to get info. e.g. "network view", current branch, list of commits
• add "pull request" = change proposal

Instructions for deleting github account

Show how to resolve a conflict

Just a note to me.