Teacher @rschuetzler had this very excellent question–wonder if others had or input:
One thing I do to encourage more committing is actually include points on the assignment for having a reasonable number of commits. So after I’ve taught them how Git/GitHub work and talk about good committing behavior, I reinforce it with points on the assignment. It’s not perfect, but I think it helps.
Perhaps try some negative reinforcement? Create an activity where commits were neither atomic nor incremental, then have students try and debug both the code and its history.
I’ve found providing tangible milestones can help. Often my students struggle on two ends with commits: “every save is worth a commit” or “is this a big enough change to consider it a commit?”.
To push them in the right direction, you can try setting good commit milestones for assignments that are structured. For assignments with more freedom we’ve found having them use trello boards/github project boards or even issues to pre-define milestones or tasks, then they can use those to know when to commit.
Aside: Feature/branch workflow tends to help with this too, and keeping the master branch protected can force them into the PR mindset as well if that’s a goal.
I would go somewhere along this route too: the whole idea of “best coding practices” is built around the fact that although they increase initial effort in sticking to the practices, they save a whole lot more of effort when things go wrong (often even preventing them from going wrong). So something like give them an assignment and have them commit at will, have them switch their works with each other and alter it, then pass the code on to a third person, and have this final round be a testing and debugging round. This will teach them at once to write code for others and not themselves, and the importance of atomic, meaningful commits
This is what I’ve experienced too. I ask my students:
- Does the code solve the problem at hand (e.g. bug fix or new feature)?
- Are you sure it’s complete (are all tests passing, if it’s at a stage where unit tests are also taught, otherwise, have you tested it and does it work)?
One thing I’ve been trying to work into assignments is the concept of Issues. I give students an assignment where they have to provide bugfixes to an existing codebase. This gives them an opportunity to see how responding to issues is a god metric for commits. In the real world it’s not always 1 issue = 1 commit, but it’s a good example of demonstrating where commits should happen. I’ve only started doing this kind of assignment this year but it seems to be working well.
edit: Ultimately what I want to do is give them multiple issues to work through in sequence that rely on one issue being solved before another in the same set of files. Then I can teach them the value of committing and reverting changes but I haven’t managed to come up with a comprehensive assessment brief for this yet.
Any commit is good unless (1) it beaks the build, or (2) it degrades functionality, and this is because it blocks other people from working. But there is a way to allow commits without the risk – branches and pull-requests. So, a student can be working on a feature branch and commit any change that does not break the build. When they think it is an incremental improvement, they can submit a pull-request, which should be reviewed by the team/class and the lead/teacher.
This way, students are encouraged to commit and push anything that does not break the build. Other students can see what they are doing, and comment or improve it themselves (that’s why it’s “social coding.”)
Then, when they decide to submit a pull-request, peer pressure will quickly teach them what it takes to be an “incremental enough” improvement to go into master.
I’ve been working with some of my students to create issues in their repos before working on problems. This provides them a focus on what problem they are working on and does a good job of letting them know when a commit should be done.