Git at competitions


Hi CD,

I was wondering what most teams do with regard to using git at competition. If there are several programmers working on different things, on different computers, what are your best practices for merging changes at competition?

Often, we’ve had the driver tweaking small things in queue for a match, while programmers in the pit or stands are working on getting a new feature or autonomous ready to go. And merging these before has always involved a flash drive and many backup copy zipfiles being made.

Obviously, there’s no internet access, so the standard git workflow doesn’t seem workable to me. Any pro-tips and tricks to make using git easy and seamless at competitions?



We have sshd set up on all of our dev laptops (that I know of, anyway). This lets programmers pull code from each other either via the robot network or direct connected to each other’s laptopts. After the comp, rebase to github and push changes.

The following syntaxes may be used with them:


For extra credit, use this syntax to pull code onto a coprocessor while connected to the field network.


You can use git with a flash drive.


We typically won’t push to the remote repo until we’re back to the hotel.


We have run git off a flash drive at competitions, but it wasn’t worth the effort.

Lately, our rule at competitions is that there is only one programmer laptop in the pit. Multiple programmers can be discussing on changes, but they need to collaborate and enter everything on that one computer.

After the competition, they push changes up to github.


This is what we do. We all collaborate and make changes on one laptop (which also ends up being the DS Laptop). We then commit and push the changes to GitHub after the competition ends.


Anyone tried using the roborio as a git remote?


You shouldn’t. It will require you to either:
A) Compile code on the robot
B) Include compiled artifacts in your git history

Neither A nor B are good things

It may be good for storing a backup of your sources, but at that point you’re better off using a flash drive as a remote, since most flash drives are larger than the RoboRIO’s measly flash storage.


You could push source over git and artifacts out of band (and require the former to succeed before trying the latter), but at that point a flash drive is probably easier.


Same here. Keeping everything to a single laptop makes the world so much simpler. We also have enough “jobs” for people to do at competition that we can rarely have more than 2 programmers sitting around.

However, we try to avoid using the driver station laptop for programming at competition. That way the programmer can keep working on something while we are in a match or at the practice field, if needed.


Yes. We set up an extra server on each laptop that’s being used for dev at the competition (“git remote add flashdrive F:\2018_repo”), then push/pull from flashdrive.

During the competition, that single golden flash drive gets to be the blessed repository with the official “most recent” code. GitHub becomes the backup. At hotel we will sometimes sync to the interwebs for backup purposes.

After competition, we sync one final time, and restore as the golden repository.

It should be noted: I personally thing the single-laptop is still not a bad idea. Despite Git’s distributed nature, it is still good to have a constant notion of which version of the repo represents the most up-to-date “golden” copy that should actually get used on the field. Whether this is on a laptop, flash drive, etc. shouldn’t matter.


If cloud storage is really needed for some reason, it would be possible to have someone do a USB tether to a laptop for internet access. My team just uses one laptop at competition though.


Both teams I have worked with have basically just kept to one laptop during competition, and haven’t had real reason to need more. So syncing git repos wasn’t an issue.

Though my solution if I believed it would become necessary would probably be to setup a Raspberry Pi with a Network Switch to use as a local git server and allow developers to connect to it to push/pull code when needed. Then sync that with Github when we got to an Internet Connection.

Another option that we have used when is a USB Cellular modem to connect to Github to pull the code down.

Also you could in theory combine the two and have the Pi Sync to GitHub over a Cellular Modem if there are any with compatible drivers.


Although the internet connections are slower and more expensive at competition (USB phone tethering), my team’s workflow is the same at competitions as it is at home. Everyone works on feature branches and pushes their patches to our Gerrit instance in “the cloud” at their own convenience. We do this when another student needs the patchset or a student wants a remote mentor (usually me) to review and provide a second set of eyes for catching and fixing bugs (I’m usually watching the matches anyway). For extended questions and comments, we use Slack. I guess you could say we don’t let a lack of wifi interrupt our testing and review procedures. :slight_smile:

We have at most two laptops going at a time where the second is usually working on something experimental and lets us hot-swap if needed. If we need to bring other laptops in to replace those, the option is there because we sync our code to Gerrit regularly. By the time competition season rolls around, my students are pretty good at maintaining, manipulating, and navigating commit history, so we can be confident that what goes on the robot during matches has been tested and works. In my experience, emphasizing the graph theory representation of Git while teaching really helps students master the tool for when they need it most: in the heat of combat robot repairs.

In short, by taking advantage of Git’s distributed nature in review as well as production, we are more adaptable at competition. Lack of wifi at venues hasn’t been a real concern.


Ideally, in theory, very few code changes are required at competition because most of your code was written, tested, and working, before you showed up. (One day… one day…)

We also do the one-laptop model. We haven’t formalized this, it just seems to be the way it happens, but it is easiest this way to ensure we don’t lose any important bug fixes or changes.

Everyone who works on robot code uses a standard git flow model where they test in their own branch and then do pull requests to master. At a competition we’ll take the latest in master (after making sure we’re happy with it, of course) and create a new branch representing any code changes made at the competition. One software student will be in the pits doing any changes from one laptop, and push code to the robot. At night at the hotel we’ll sync back to GitHub. When we come back from competition the code changes are merged back to master.

The software laptop has typically been the personal laptop of our most senior software student, though we may try to allocate an official team one so that multiple people could use it in theory. This will be different from the driver station laptops (we have at least 2 so there’s always a spare).