VsCode with team Windows account

#1

Hello all,

I stumbled upon this Medium article, and it got me thinking about how I would love our team’s programming crew to run. We are blessed to have a few talented programmers on our team and a few more up-and-coming programmers who just joined.

One thing I would love is to require that a programmer log into a workspace to work on their code so they can sync with their own repo that will contribute to the final robot code.

What we currently do is ask students to build their own workspace on a machine, connect it to their own repository, and switch to it when opening VsCode. However, they do not always remember to do so, so sometimes they are editing other students’ code directly.

We are working on Windows machines (we do not have enough to allocate each device to each programmer) and using a team shared account.

Does anyone have any recommendations to help teach team members effective team git workflows?

Thanks.
~Mr. R^2

#2

I would recommend using branches. Have each programmer create their own branch in the main repository and remind them to switch to their own branch whenever they are writing code.

2 Likes
#3

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:

  1. Do training in the pre-season to ensure each student knows how to use the tool, and why they should be using it.
  2. 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.
  3. 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.

3 Likes
#4

C_MacC and gertworm,
Thank you. That is what I was thinking as well.

These are profound words. We struggle with the former as well. It is incredibly important however. We have some organized and energetic members working on helping us keep the tools organized, and last year, when they began, they increased our productivity at least tenfold. A lack of discipline costs a lot of time. The discipline is infections, we are all learning how to be more productive together.

So, I have a few follow up questions.

  1. Do you teach the team members git through command line, VsCode, or both?

  2. How do you handle off-line changes, for instances at an event? Do you commit locally, and ensure you push changes to the repo when you get back up online?

Your responses are clarifying a proposal I will make about our workflow moving forward.

~Mr. R^2

Edit: C_MacC, We are using branches. Last season, we separated branches by function. When we added a function (either type of mechanism or increased function e.x. drivetrain, elevator, turn - to - target…). This was helpful most of the time.

1 Like
#5

Indeed. The hopeful corollary: you can invent tools and processes to make the discipline easier. 5S is one way to do it with toolboxes. Git (and a defined git workflow) is one way to do it with software.

To your comment on branches: Take a look at Git flow, a concrete model of how to use branches for development. It may be a bit heavy-handed for your work, but it is a start. The general paradigm I like to stick to is that each branch should have only one developer associated with it. This keeps people off of each other’s toes.

To your other questions:

Almost everyone uses Git Extensions to visualize the version tree and do commit/push/fetch/etc. - there’s lots of other options out there too for this. vsCode and command line get used occasionally too, though most students prefer the GUI.

For work at an event: We create a bare copy of the repo on a flash drive (affectionately named “flashdrivehub”), which some trustworthy student or mentor wears around their neck on a lanyard. Whenever code changes are made on any laptop that need to be pushed, we plug in flashdrivehub and push and pull with that repo.

For the period of time which we’re using flashdrivehub, Github actually becomes out of date, and is no longer the “golden” or “blessed-correct” repository. However, we usually sync the day’s changes up to Github when we get back to the hotel that night. Just in case flashdrivehub goes missing.

Similarly though - there’s usually only one or two laptops in use for development at competition, which keeps things quite simple.

2 Likes
#6

Thank you again. This is all helpful info. I was not familiar with Git Extensions (or 5S for that matter, it looks incredible). It seems to be exactly what we are looking for. I also love the event solution. We are trying to maximize our last few weeks before kickoff, and I think building in behaviors when we start some experiments (like an Omni drive base), will pay dividends when crunch time comes.

~Mr. R^2

Edit: I had heard of 5S, just not used that term.

#7

Personally, I used the VsCode interface the majority of the time, though I do recommend teaching some basic git commands. Additionally, the GitLens extension is useful to have.

We used a single laptop to make changes. Periodically throughout each day, and at the end of each day, I would copy the entire project folder onto a flashdrive I kept in my pocket, and would upload the code to GitHub when I got back to the hotel.

A few other resources that you may find useful are the official FRC documentation about Git and The Complete FRC Git Tutorial.

1 Like
#8

These are helpful too. We have a lot to work with here. As you both said too, these skills will help our team now, and our members later in life.

Thanks again.

~Mr. R^2

1 Like