I think this is the key. Ultimately, there’s a gap in executing process.
More than once, we’ve had students redo work because they started from the wrong spot, or failed to commit and push before another student started.
The shared, simultaneous editing of a single codebase is one way to get around this - google docs style collaboration. However, it’s not at all a scaleable solution - any professional software development environment will require properly tracked change history, with by-developer contributions clearly shown. It may work for small projects and teams, but i’d be worried you’d hit its limits very quickly. Especially with many high school fingers typing code, it’s hard to guarantee that “latest is correct”.
The bottom line: keeping anything well-organized requires discipline. Whether it’s a toolbox or a codebase, there’s no substitute for taking the time to do the right thing. A big reason I’d be worried about using VS code simultaneous editing is I see it re-enforcing bad habits. Git provides purposeful speed bumps to ensure you know exactly what you are changing and why. Then again, I’m old and crotchety when it comes to such things.
The most effective methodology for enforcing a process I know of involves a three-pronged attack:
- Do training in the pre-season to ensure each student knows how to use the tool, and why they should be using it.
- Provide an algorithmic process that every student must follow prior to starting every piece of work (ex: Fetch, checkout latest master, make a new branch, push branch, etc.). Print it out in big bold letters and post it in a highly visible spot.
- If a student still fails to follow the process, force them to re-do the work. Some people learn well from pain.
One final edit as a point of reference:
All our laptops have a common login that all students use. We maintain a single github repo, with a single clone of it on every laptop. Every student who uses that laptop uses that same workspace and repo. By process, students always start a new activity from a pre-discussed point in development history (usually origin/master latest), and always on their own branch. Separately, a senior student or mentor merges all the completed work together and makes new releases.
If a student has to stop an activity partway though, it’s expected they commit and push the work, even if it’s not functional yet. The next student who uses the laptop always needs to check which branch is checked out in the repo prior to starting to make changes.
We generally have enough computers that students tend to usually use just one or two machines - this helps the process since they can often forget to commit and push, but still not have their code messed up (as long as they notice the next day and quickly fix it). With more sharing, the cost of forgetting the process goes up quite a bit.