Best GIT approach to educational project

Question

I am working on a course design and I'm preparing the project that the students will have to work on all along the course.

Each student will create a GIT repository a the beginning of the course and they will add files and modify them to add features as they learn new things. It has various milestones that will happen as they acquire the knowledge.

Now, the project definition is stored in a repository and includes a solution branch with a directory where we are storing an example on how to solve each milestone of the project.

Each milestone in the solution branch is tagged, so we can do a checkout and move to each point in the process.

But I now realize I should change something in the solution of one of the previous milestones (tags) and these changes should be propagated to the successive tags.

I don't know if there is an easy way to do this as it is, or it would be better to use branches instead of tags for each milestone. Would it make this situation easier?

Answer 1

As a cautionary note up-front, the way that git works means that if the solution is stored in the same repository as the project definition and if students are expected to clone that repository to get a copy of the project definition, then the students will also get a copy of the solution in their clone. This means that if a student is a little git-savvy, they will have access to the solution before they attempted the exercise themselves. If that is undesired, then you should keep the solution in a separate repository (for example, as if you were a student who has done the work in a previous year already).

In git, tags and branches are both just named labels to a particular commit. The main difference is that a branch-type label can easily be moved to a different commit and that typically happens automatically when a new commit is added to a branch. tag-type labels can only be moved to a new commit manually.

If it is very rare that corrections need to be made to the solution, then you could adopt a workflow where you make the correction at the milestone where it is needed and then rebase the rest of the milestones on top of the corrected version and re-apply the milestone tags to the new commits.

If it is not that rare that corrections need to be made, it might be better to maintain a branch per milestone and to apply the correction to each of them (possibly by cherry-picking the relevant commits).

Both of them require a fair bit of manual work where errors can be made, but the use of branches is easier to grasp for most people and that makes it easier to correct any errors that were made in the process.