Hi all, Jumping in a bit late, but this development is great! I like the idea of offering two flavors of the git/github lesson -- a more command line based one and this more github flavored approach. I also like the idea of gathering a list of alternative things to edit -- either replacing Dracula with another option or having 2-3 ways to teach (how we handle that infrastructure can be part of a later discussion).
Thanks all! Christina On Wed, Jan 10, 2018 at 8:38 AM, Bond, Steve (NIH/NHGRI) [F] < [email protected]> wrote: > Hi Dena, > > Thanks for all of the feedback! And I really like your visual aids. > > I’ll try to spend some time to modify the clone/conflict section and add a > few new sections to go through reset and branches. > > Congrats on a successful workshop. > > -Steve > > > > *From: *"Strong, Dena L" <[email protected]> > *Date: *Tuesday, January 9, 2018 at 7:24 PM > *To: *"Bond, Steve (NIH/NHGRI) [F]" <[email protected]>, Software > Carpentry Discussion <[email protected]> > *Subject: *RE: [Discuss] Git and Github lesson (follow-up) > > > > Reporting in: I just taught from Steve’s version today, and it went > fantastically. I’ve never taught Git before. I really liked teaching with > this structure – the Dracula thing never made sense to me, whereas both the > audience and I didn’t have any problems following the “all right, we’re > adding new features to software under development” description. > > > > I would enthusiastically endorse anyone who wants to teach from this > version to give it a go! > > > > (I was particularly lucky since Maxim Belkin, my co-instructor, is > brilliant, friendly, and enthusiastic! My original co-instructor had a > house emergency and I’m really glad Max could step in. I would have been > flailing a lot when the IT pros I was teaching asked things outside my > knowledge and expertise level, but I would have been doing that with any > lesson plan.) > > > > The TL;DR and a physical mechanism for conveying concepts below: > > > > This audience: 6 IT professionals ranging in experience from “I’ve never > touched Git before” to “I’ve been using it on and off for a few years, but > I still don’t get it.” > > > > The method: Steve’s non-Dracula version of git-novice, a slide deck for > supplemental concept walk-throughs, and a bunch of file folders for > physical representation of what was happening with each edit in each step. > All my links are collected up at https://tinyurl.com/itpro-gitnotes. > > > > On the potential confusion point Steve mentions below: Two of our pairs > were OK with the fork vs clone thing and worked out how not to have name > space collisions and knew where they were at. However, our third pair was > struggling and Maxim helped them out a lot. As suggested below, I think > revising it so people are forking from a different repository than you’ve > just cloned from would help reduce the name space collision headaches. And > people were also finding that they could just accept the pull request > because they already had access after having traded authorizations for > collaboration. (So maybe have them fork from the instructor’s version > instead?) > > > > We also discovered that either there weren’t instructions explicitly > telling you to go up a directory from your previous working directory > before running a clone command, or it was well enough buried that 2 of our > 6 ended up cloning their new stuff into the folder they were already > working in. So more clearly spelling out “before you start a new project, > go back to your ~ directory” could be helpful to add too? > > > > Because these were IT pros, they were more interested in complex > workflows, resets, “hitting the undo button,” and continuous integration > capabilities than in open science and R studio, so we went off the lesson > plan at the end of step 9 and Max freestyled branching, merging, resets, > and travis-ci. > > > > I think it would be worth considering adding “how do you roll back” to the > course – they were really interested in branching and git reset and git > checkout, which don’t get touched on in the major material. One poor > individual had been manually undoing all his changes to get back to > matching the master version whenever he wanted to retrace his path, and I > think branches and git reset have changed his world. Food for thought? > > > > A teaching aid I found helpful: A “folders and notes” setup for physically > demonstrating what goes where at what step. (Image attached – in actual > class I put working-space on the left and repository on the right to match > reading order; this photo was when I was setting up mirrored versions to > test drive.) > > - Working directory: Papers in front of you > - Edits: Sticky notes that get put on a thing in your working directory > - Stage: A folded-over piece of paper labeled “stage” (because I only > had manila or hanging folders, and the inner folders were commits) > - Commit: “You take everything that’s in stage, and put it in this > manila folder. Then the manila folder goes into your local repository > hanging folder. You get more and more manila-folder commits as you add new > versions to your local repository, and each of them has its own label – > that’s this hash tag right here…” > - Repositories: Two hanging folders of the same color, one in front of > the person (local) and another in a box at the end of the room > (remote/GitHub.com). > > > > It seemed to help people visualize the differences between add, commit, > and push as I walked them through things, and the manila-folder layer gave > some starter ground work for the difference between clone (“Blue wants to > edit on Pink’s project, so Blue grabs a manila commit folder from Pink’s > remote folder and puts it in Blue’s local folder in front of them”) and > fork (“Blue doesn’t want to edit in Pink’s repository, Blue wants their > own. So first we copy Pink’s manila folder commit into Blue’s remote > directory, and then Blue has their own working space for this project, and > here’s how Blue can give Pink some edits with a pull request.”) I hadn’t > worked out how to simulate branching because I knew Maxim would handle that > the way he preferred to, but everything up to that point seemed to work > fine. > > I’d never thought I’d feel comfortable teaching Git, because I don’t use > it in my working life. But we needed teachers, so I dove in, and I loved > this lesson structure, and I want to give a huge thank you to both Steve > (for providing the lesson structure) and Maxim (for being the safety net > and expert guru all at the same time). :D > > > > *From:* Discuss [mailto:[email protected]] *On > Behalf Of *Bond, Steve (NIH/NHGRI) [F] > *Sent:* Tuesday, December 05, 2017 1:38 PM > *To:* Software Carpentry Discussion <[email protected]> > *Subject:* Re: [Discuss] Git and Github lesson (follow-up) > > > > Hi All, > > For a bit more context, we decided to strip the Dracula backdrop out of > the git lesson completely to give our workshop participants another > opportunity to write little scripts. The example we settled on was unit > conversions (dollars-to-cents, minutes-to-hours, etc.). We also wanted to > change the focus to the GitHub UI, because that is how the other > instructors and I generally manage repositories on a day-to-day basis. It > seemed weird to spend time showing students how to initialize a local > repository and then turn around and say they probably won’t often do it > that way. > > In practice, the reworked lessons have gone reasonably well. Depending on > the class, though, it has gotten a bit sketchy when we move into > collaboration and conflict resolution. In the lesson as currently written, > students are asked to pair up and then create repositories that they then > reciprocally share. Unfortunately, people tend to get confused about which > repository they are modifying, which one is their own, and which is their > partner’s. It might make more sense to have the instructor create a central > repository that everyone clones and edits. Then we could create a conflict > that affects everyone the same way. > > It’s been a while since our last workshop, so the material hasn’t been > getting much attention. If there is sufficient interest from the community > though, I’m happy to facilitate further refinements on my own fork or work > with the core team on the main SWC version. > > Best, > > -Steve > > > > > > *From: *Anelda van der Walt <[email protected]> > *Date: *Tuesday, December 5, 2017 at 10:39 AM > *To: *Software Carpentry Discussion <[email protected]> > *Subject: *[Discuss] Git and Github lesson (follow-up) > > > > Dear all, > > Back in July 2017 I started a conversation on the discuss list about > alternative Git/Github lessons that exist in the Carpentry community [1]. > So many of you responded with suggestions about how you have dropped the > Dracula example or augmented it with episodes on things like Git GUI or > Github and more. Thanks very much to everyone who responded. > > One of the first lessons I was pointed to, was Steve Bond's (copied on > this email) lesson [2] which was originally forked from the SWC git novice > lesson, but introduces Github and constantly show how to do things both in > git and github. > > Last week we ran a workshop at NWU where we trialled Steve's lesson. I > chose this lesson as it was mature enough to use off the shelf (Steve had > put a lot of effort in to make sure the lesson is refined). > > > Feedback from the workshop: > > - It was great to introduce the power of local repositories and > connect that with online repositories and collaboration. > - The lesson makes version control much more accessible even for > learners who are not yet comfortable on the commandline. > - The switching adds cognitive load but we went very slow and got good > feedback. > - I veered off the script to spend some time introducing all the > things that can be clicked on in the Github interface and people found that > very valuable, but I don't know how to incorporate this as an episode in > the lesson making it practical? > - We didn't get to the collaboration part even though we had time to > spare as people's brains were fried by late Friday afternoon. We ended the > workshop on a high. The lesson includes screenshots for every step of the > way so I recommended people referred back to the lesson when they get to > collaboration and conflict resolution. > > Afterwards a colleague did a short demo of how she uses Git from RStudio > and another colleague showed the same for his text editor (Visual Studio > Code [3] - available for Mac, Windows, Linux). This was really helpful to > show people how they can use even better tools to be more efficient and > adopt version control easier. > > I'm wondering if the community would like to try out Steve's lesson as > alternative to Dracula and provide some feedback? Maybe this is a low > hanging fruit waiting to be picked and solve some of our git > teaching/learning problems? > > Steve already did most of the work... > > > > What do you think? > > > > Thanks, > > > > Anelda > > > > [1] http://lists.software-carpentry.org/pipermail/ > discuss/2017-July/005319.html > > [2] https://github.com/biologyguy/git-novice > > [3] https://code.visualstudio.com/docs/supporting/faq > > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.software-carpentry.org/listinfo/discuss > -- Christina Koch - Research Computing Facilitator, University of Wisconsin - Madison <http://www.wisc.edu/>, Center for High Throughput Computing <http://chtc.cs.wisc.edu/> Wisconsin Institute for Discovery <http://wid.wisc.edu/>; Advanced Computing Initiative <http://aci.wisc.edu/>; ACI-REF <https://aciref.org/> email: [email protected] // phone: (608) 316 - 4041 // calendar: tinyurl.com/ChristinaCHTC
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
