Currently in Conflicts the learner encounters GitHub rejecting their push for the first time, and then on pulling encounters a merge conflict that must be resolved manually.
This conflates two ideas—GitHub rejecting a commit, and conflicts that cannot be automatically resolved. It may also give the idea that any time the same file is edited by two people, it will generate a conflict that must be resolved manually. Since once of the good things about Git is its powerful conflict resolution, it would be good to avoid this impression.
Should we instead first introduce a change that Git can automatically resolve, before then making a second change that requires a manual resolution? This would give the learner a clearer picture that GitHub rejects all pushes that contain work not available locally, and also show that most of the time Git takes care of merging, with merge conflicts being a fallback used only in the minority of cases.
If we agree this is a good idea, I'm more than happy to draft the changes to the episode.
The text was updated successfully, but these errors were encountered:
@edbennett Thanks for the comment. It sounds like what you're describing is collaborating, but where different lines of the same file are modified at the same time. However, there is a problem that adding another example adds time to the lesson. Since the lesson already has more content than a workshop has time for, what do you propose is removed?
This is a good point. I think this addition would add 5, maximally 10 minutes to the episode, but that some of this would be compensated by less confusion around the conflict that Git can't automatically resolve.
The lesson is already relatively streamlined, including almost the minimal possible content to get from "nothing" to "able to push and pull to GitHub and resolve conflicts when they occur". I do think some of the callouts in episode 4 could be trimmed or streamlined. For example, in "Limit log size", the -1 option isn't one I've ever found useful, and --graph isn't particularly useful until you start to use branches.
If we choose not to include an extra piece of live code on this, I think at a minimum there should be an extra couple of sentences added in this section explaining that Git can resolve conflicts automatically, unless they affect the same or adjacent lines of text (ignoring binary files, which we don't cover anyway). Currently a learner can easily get the mistaken impression that any commit that touches same file, or even any commit that happens on the remote in between pulling and pushing, causes a conflict that must be resolved with the workflow described in the lesson.