TL;DR: I created a program to manage code versions and backups and it can be found on Github
At the beginning of the season my mentors kept reminding me to back up the code and save a copy which, throughout the season, has proven to be extremely useful, but it started off as a tedious process. I would have to locate the robot’s code directory, copy it to another folder, then find the version of code I wanted to go back to by manually searching through the code for clues on what that specific version did and if it might fix a given issue.
I took it upon myself to create a program that fit my exact use cases and was more pleasing to look at than Windows file manager. This program organizes your code by date, and allows developers to label the changes they have made to the code so that, if any problems arise, the changes that caused them can be reverted. It also allows developers to mark code versions as ready for or used at a competition to help further organize.
It is currently a work in progress, but it is perfectly usable and the only planned improvements are for making the program more configurable. The program does not integrate with any online storage services such as Github, and while this may be an issue for some teams, our team’s programming computer is rarely connected to the internet so this feature wouldn’t have had much of an effect.
When I made this, our team didn’t have a Github account, but I will continue to use it as it stores all of the code locally so I don’t need wifi to use it which is helpful when I am already connected to the robot. This program also lets me mark versions as used at a competition and easily distinguish between the versions which is a feature that I use all of the time. For some teams, Github may be a better option, but I was just sharing what my team uses.
FWIW, git works offline as well. GitHub is an online storage system for git.
As a more general workflow, I would recommend creating a branch for each competition and then archiving it so that it’s trivial to restore competition code.
If you’re seriously interested, a good opportunity to expand this project would be to make it into a front end for Git (much like the GitHub Desktop application). To get started, I would recommend looking at nodegit, a JS library for interfacing with git.
Fun fact about git is that, since it doesn’t rely on a server to be the single source of truth, you can create a bare repo on a flash drive and pass it around laptops to use as an offline “remote” server. Instead of pushing to a github repo - since you probably won’t have internet access - you can push to the flash drive instead. Just need to remember to pass it around between programmers so they can push their code. Using a distinct branch for each competition is a good habit, too, since it lets you see changes over time and clean it up before merging it back into your main branch
Also fun with git: there are several GUI clients that let you see your git commit history visually, like Github Deskop, Sublime Merge, GitKraken, or even just by running git log --graph in your terminal.
Example for setting up a flash drive remote. The first command only needs to be run once to set up the flash drive.
my-repo> git init --bare E:\my-offline-repo.git
my-repo> git remote add offline E:\my-offline-repo.git
# later...
my-repo> git commit -m "Match 1 code"
my-repo> git push offline week-2-code # pushes to the "offline" repo on the flash drive
Beware, nodegit is an abandoned project. Moreover, if you’ll decide on using Git LFS someday you won’t be able to since libgit2, the underlying library nodegit is binding, doesn’t support hooks which are required for LFS. (There is nodegit LFS but it’s half-maintained, not on npm, and requires the git&git-lfs cli anyway)