From time-to-time people email me with questions they have about teaching Git. One of the common problems people face is helping students to apply the confidence they've learned in the classroom to their daily tasks.

Scenario

The following is an excerpt from an email I received. (The "I" in this section refers to the person asking the question.)

One example would be when they are doing rebase and everything works (no conflicts), I feel like they understand whats going on, whats a commit, whats a blob, etc, they explain me whats happening, but when they are conflicts its like they don't know where they are, they don't wonder why there was a conflict at all, the whole rebase/merge situation confuses them.

When we teach git here we do it in a toy project, but when it comes to work with a team in a real project they start to feel that they don't know exactly whats going on. for example, "Why I did a pull and a commit message for merge is happening?" But we did explain this in the past.

The second clear example, would be when they check the history of the project, sometimes we ask them question like: "How far is github remote from your branch? Or in which branch is this commit made?" It seems like git log -p is very clear but git log -p ..feature_1 isn't.

Solution

It sounds like you need to include some "real work" scenarios in your instruction. Set up a separate copy of their actual repository and create some known conflicts for them to resolve.

In Bloom's taxonomy terms, you've done a good job of getting them to apply the knowledge, but not necessarily how to analyse a situation to see how it is the same (or different) from something they've already learned. I find that using sketches / diagrams helps to make the link between concepts they already know, and a situation that is the same root problem, but has manifested in a different way. The drawing remains the same between the two activities, so it acts as the "bridge" between what they already know, and what they have the skills to know, but don't realise.

• Activity 1: simple rebase in a toy repository. Draw a sketch of the commit graph.
• Activity 2: simple rebase in a real repository. Draw a sketch of the commit graph.
• Activity 3: rebase / merge conflict in a toy repository. Draw a sketch of the commit graph. (At which point did the rebase fail? How do you know? What do you need to do to resolve the conflict? What happens when you "continue" rebasing?)
• Activity 4: simple rebase in a real repository. Draw a sketch of the commit graph. Reinforces prior learning.
• Activity 5: rebase / merge conflict in a real repository. Complete all of the sub-tasks from Activity 3.

The first time you should make this bridge very explicit. In adult education we also talk about "near reaching" and "far reaching" knowledge transfer. Near reaching means the situation is identical to what we learned in the classroom; far reaching means you're teaching principles that need to be applied to a very different scenario when the learner gets back to the work place. If all of your classroom work is "near reaching", the students won't learn how to apply the principles. If this sounds interesting, I highly recommend Ruth Colvin Clark's book Developing Technical Training.

For the second example: I would actually use git branch -vv and git log + git branch --contains. :) There might be something lost in the translation / terms you're using? I wonder if the same thing is happening in the classroom, where you're looking for a very precise answer, but the question a little too vague for the students to make the connection? Have you created a "cheat sheet" of common commands for them? (sometimes I have students build these; and sometimes I provide them..it depends on the group) Maybe this activity would be more effective if you were asking them to choose from a list of options, instead of asking them to guess what the command should be?