Suggestion: Split the lesson into two lessons

[aragilar]

Currently the lesson is really overloaded (too much material/too many concepts), and generally teaches bad/dangerous practices (e.g. the conflicts and remote sections are going to cause grumpy collaborators, and while improvements to exploring history have made the footgun of git checkout <commit id> less likely to occur, there's probably a safer approach we could take than using git checkout).

Splitting the lesson in two, with the intro lesson covering how to work locally (plus pull and push so you can share code between your devices), and the second lesson covering collaboration (which means we have time to cover how to resolve conflicts, use branches, using fetch rather than pull etc.), would reduce the number of concepts, and allow for more exploration (e.g.
exploring history is a great time to show off GUI tools, but the lesson skips over this/there isn't time).

This does somewhat reduce the selling point of collaboration (as learners won't see any collaboration, but in my experience learners haven't been that interested in that aspect), but instead we can focus on the "right tool for the job" aspect, with the integration into whichever tool their using (e.g. RStudio), which I think may be a better motivator.

The other advantage of this is we gain some flexibility in adapting to the changing ecosystem (e.g. the need to manage ssh keys/PATs, and the need to switch the working branch for collaboration can be reduced/avoided), as its the collaborative aspects that will change, not the core aspects of add, commit, push.

[kekoziar]

Thank you for the feedback. We acknowledge that there is more content in Carpentries lessons than can be taught in a typical workshop. It's one of the reasons maintainers are so aware of scope creep and extra time added in the main lesson.

Speaking as a lead instructor, as long as we have the full half-day for the lesson, Git is the one lesson we usually have no problem getting through all of the content. We usually have 15-30 minutes of learners working in pairs to create/resolve conflicts (depending on how much time we have when we get to that section); although in the future, the added SSH section will likely cut into that time. The conflict resolution is often the learners favorite part of the workshop.

That said, there have been a lot of suggestions over the years to add content that focuses on branches and advanced collaboration; however, that would generally be new advanced content, and so we mark it as "out-of-scope" and suggest the contributor work on an advanced Git lesson. Perhaps the content you're suggesting would better fit there. As is, your proposal would take the lesson from 3 hours to about 1 hour 15-ish minutes.

[tobyhodges]

@aragilar and anyone else reading this: if you are interested in looking through an equivalent lesson that takes time to further explore branches, merging, and pull requests, I can recommend this one from The Carpentries Incubator: https://carpentries-incubator.github.io/git-novice-branch-pr/

[aragilar]

@kekoziar Possibly we're teaching to a difference audiences/skill levels, or we're teaching git at a different time in the workshop (which may explain our different experiences—if that is the case, that would be a good thing to add to the instructor notes)? I've been teaching 2 day workshops within a university, where with the full half day for git, we'd have the last 30-45 minutes for conflicts if we kept a brisk pace? I'd estimate the remaining content at about 2 hours, and with the hour we've "gained" we can spend more time showing different visualisations of the repository, and more time for exercises doing the add, commit, push flow. Ideally, I'd want my learners to come away with the concept that they can add and commit, and they have a history of their changes (I get the feeling though only a few really get it).

@tobyhodges That looks useful, and I'll add it to my list of resources in case I end up doing a full-day git course. The main change I would add would be to teach a merge tool (https://meldmerge.org/ is the most user-friendly tool I know of). Merges are usually the bit that people scared of, and it usually take a few merges before people feel confident doing them on their own.

[kekoziar]

Thanks for the pointer, @tobyhodges!

[aghr]

I agree to @aragilar. Teaching Git to Master/PhD students from biology and aligning the course to the Carpentries Git Novice, ran into issues with too much content and too little time. For absolute Git beginners, I'd prefer to spend more time on explaining/discussing fundamental ideas behind Git with slow speed than going straight through the live coding. Assessing my experience, I also came to the idea of splitting/adapting the lesson material to create two lessons; Something along: Git for absolute beginners, and Git advanced. I also agree that the lesson experience depends heavily on the students and how much experienced they are already with Bash + the idea of version-control.

[marcodelapierre]

After 5+ years of teaching coding at a supercomputing centre, and using Git for my own work, I have just taken part in the Carpentries Instructor training, and used the Git workshop as the toy workshop.
I would like to add my 2 cents about the Git workshop then.

Git is one of my favourite topics, as it makes up for a big chunk of my work week, with big impact on productivity and collaboration.
I think the current structure, content and duration is great.

I have a suggestion for improvement, which is not new here, but for which I would like to provide additional support.

I believe branching should be in this basic, half day curriculum. In my opinion it is indeed a fundamental concept to version control, as it enables to organise work in work streams, that can be for instance by topic and/or by author; moreover, it bring along the idea of peer review of the contributions (the pull requests).
If I had to make room myself in the current curriculum, I would almost get rid of Ignoring things (not vital, can be just mentioned somewhere else) and shrink Conflicts (very long right now, not needed for a newbie), and make room for a Organising contributions or similar straight after Conflicts, to introduce branches and pull requests, and provide at least one live coding example of this workflow, with its own formative assessment.