New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Motivating Git and making it more accessible #429

Open
JCSzamosi opened this Issue Aug 2, 2017 · 4 comments

Comments

Projects
None yet
4 participants
@JCSzamosi

JCSzamosi commented Aug 2, 2017

In our first workshop, my co-instructor and I taught the git lesson pretty much exactly as written, up to and including episode 9 (conflicts). After our workshop we got a quite consistent feedback from participants that they felt like the git section of the workshop was a waste of time. They thought it was very hard to learn, many of them came away feeling like they still didn't understand it, and they for the most part didn't feel like they needed it anyway.

We therefore made some major changes to how we taught it the second time. Since this second time seems to have been much more successful in all the areas described above, I thought I'd share what we did.

We made two major changes. The first was to skip episode 1 and instead:

  • ask participants how often they find themselves keeping multiple copies of documents, scripts, or data files simply because they don't want to lose the old version
  • discuss how hard it is to go back through those old versions and make sense of them[1]
  • explicitly teach manual version control from the Keeping Track of Changes section of Good Enough Scientific Computing[2].

This all took about 30 minutes, and seemed to really motivate our participants to learn what came next.

The second major change was replacing episode 5 with a tutorial on how to navigate history and download old versions of files from GitHub instead of on the command line. At our last workshop, checking out and navigating commits on the command line took a long time to teach and felt mostly unsuccessful and frustrating for all involved, but moving them functionally to a GUI for only that part of the lesson seemed to work really well this time. We stressed that this did mean they needed to put all their projects on GitHub, and offered BitBucket as an alternative if they were looking for a large number of small, free private repos.

[1] (as an aside, we didn't include the PhD comics strip because, although it's funny for many of us who use version control, we felt it might be patronizing, or at best not relatable, to people for whom that is the only thing they've ever known.)

[2] We felt this last was very important, partly because even if a person doesn't start using git, giving them the tools to make their version control systematic is still an improvement, and partly because we wanted to show how laborious doing version control by hand can be, to motivate them to learn a tool.

@JCSzamosi

This comment has been minimized.

JCSzamosi commented Jan 2, 2018

Continuing in my attempt to make the git lessons more accessible, I have written a version of the lesson that does not rely on the command line. I anticipate moving away from GitHub Desktop and towards a remote-agnostic tool, but this was a first pass attempt.

I recently co-ran a Data Carpentry workshop that included Git but not Shell, so we needed a way to teach git with a gui. The lesson can be found here

@rgaiacs

This comment has been minimized.

Contributor

rgaiacs commented Jan 2, 2018

Continuing in my attempt to make the git lessons more accessible, I have written a version of the lesson that does not rely on the command line. I anticipate moving away from GitHub Desktop and towards a remote-agnostic tool, but this was a first pass attempt.

As far as I know, GitHub Desktop doesn't work on Linux machines and we are trying to not discriminate about learners choice of OS. If you are looking for a graphical user interface, check gitk and git gui which are part of the standard Git project.

@JCSzamosi

This comment has been minimized.

JCSzamosi commented Jan 4, 2018

We found a port for GHD on Linux. You can see it in our setup instructions here. That said, I agree that GHD is not a great gui, and we're going to look into gitk or something like that for future workshops.

@peetucket

This comment has been minimized.

peetucket commented Oct 23, 2018

When I've tried to explain git and why it may be useful to people who've never used it before, I try to use analogies. I like to to think of paper documents (a file), a copy machine (committing a file), a file cabinet in your office (the local git repository), and a bank safe deposit box (GitHub). The allows people to understand the chain of events that happens from creating a file, to committing to a local repo (saving a snapshot for yourself), to pushing to GitHub (now its available to everyone). This can help with the confusion that can easily arise between the commits, an instance of a specific git repository, and GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment