How do you teach students to resolve merge conflicts?

Wondering if anyone had exercises they liked to use?

I don’t know yet :disappointed_relieved:

Using classrooms part of the introduction to git(hub) labs cover a simple exercise.
With one textdocument in the start repo (contains a line for name and first name) students need to team up with at least one other student. (group exercise)
All students involved need to create a branch they call their first name and on that branch they complete the info in the text document (e.g. firstname and name) After doing that they commit their changes and one by one start a pull request.
The first one will go without issues, as from the second one merge conflicts will need to be addressed.

That’s (at present) one of the introduction labs we’ve got setup.

I wrote these workshops to help our student better understand git and github. I do it live (so there is some things that I say that isn’t fully written up) but I hope this will help you out. The first two activities I have done a few times and it seems to go over well. The third and fourth probably needs some work. Please let me know what works or doesn’t work for you:

The workshop is split in the following manner:

activity 1: introduce git terminology using the github ui by very slowly writing the alphabet song (history, branch, pull request, merge conflicts (and how to resolve). This is a single person activity.

activity 2: repeat activity 1 by doing it using command line git (obviously no pull requests… but how you would merge is covered)

activity 3: working in groups (collaboratively write out the lyrics to the itsy bitsy spider) - how to use issue tracker, pull requests etc (note that I set up the basic repo link using my github classroom but I had to deactivated it so that it stops spamming my research group but you can probably just take this and replace the link with a group assignment through your own classroom).

activity 4: repeats activity 3 but the writing is done offline.

1 Like

I teach that two people had to think different, but they must talk for put of course.

I’ve followed the first two activities which were a great introduction in git, better than the original tutorial here. However, I couldn’t follow the last two activities as the target location doesn’t exist.

Hi there,

I had to removed the links because of the spam it was causing to other members of the research group that the repos were created under. I just created a new org and recreated the links so that repos are created under this new org instead. The tutorials should work now. Anyhow thank you for the feedback, would love to see how the other two workshops fair.

Either this:

Or straight inside Atom would be the best places to do it efficiently and in a very visual manner :slight_smile:

With pleasure, I test your last two activities as well. Activity 3: I’m not sure whether I did everything as you expected. I first joined your TeamTest, then, I went back and created my own team Tome Kit. After that, I created a fake account eero-pand and went to the link provided by you - my team wasn’t present there. So I joined TeamTest again. In the code section, there are no files like or Instead, there’s a manual how to create the latter. Am i doing something wrong is do you want to change your instructions?

oops… I forgot that I had starter file in the original repo. I think it was just a blank file though so I’ll just update the instructions. Thanks!

I use GitHub heavily in my software engineering class - they do a lot of work in it.
A lot of the time, however, they avoid this problem with assignments that are individual, or for group projects pair programming with only one person committing, or just never working simultaneously.

I have a class lab assignment where we go over this:

This lab is after I’ve introduced Agile development, and they’re getting comfortable with the idea.
I then start the lab off by explaining that I want them to make me a 4-function calculator with a GUI in C# (C# is the language we’ve been using in the class). The entire class acts as a team responsible for building this project, and I usually have them group up a bit so they can pair program.

I then sit back, and act as relatively clueless product owner - they get to define tasks, user stories, plan their sprints out, whiteboard the interface, etc.

This usually ends up taking 2 class periods (~150 minutes)

Around the end of the second sprint - everyone starts getting upset, because whoever committed last blew away the changes they’d all made to the project!

At this point, we take a break from the exercise, and I remind them about branches (which we go over in our first github lab, but everyone largely forgets about), and then we talk about how to properly merge, as well as navigating Visual Studio’s merging conflict interface.

Generally by the end of this lab they have a good handle on things :wink: