We use SVN (or any other direct alternative to Git)
We use google drive/Dropbox etc… (Remote/Cloud storage)
We make local backups (flash drives, external storage devices, having a backup on another PC))
We do not use version control
I don’t know / Other (please comment)
0voters
Although Git or SVN is recommended, every team is not the same. I’ve seen some teams that only do local backups and Google Drive backups, because their school has restrictions on their computers, so they can’t connect to Github or BitBucket, etc…
if the current system that you use works best for your team, then that is all that really matters.
Google Drive/OneDrive/Dropbox/etc is NOT version control. At best, it’s a backup solution. It doesn’t handle simultaneous edits at all, and has no concept similar to the .gitignore file, so you have no way of preventing certain files from being shared.
For any teams using one of those systems, I urge you to PLEASE learn git (or other actual version control system). I promise, it’s really not that complicated unless you’re using it in weird/atypical ways.
This guide is written for FRC uses, but Git is a huge tool. Github just surpassed 100 million developers, meaning there are countless numbers of resources to get started.
I think a lot of beginner Git users should also know how to use git --amend; I’ve seen many of our teammates commit broken code to a repo, which is followed by 3 commits fixing the other previous commits.
“super autonomous, neural network, blockchain based autonomous driving”
“some small fix”
“fix that fixed the small fix”
“fix that fixed the fix for the small fix”
“fix that fixed the fix for the fix that fixed the small fix”
(this is an exaggerated scenario)
This is probably just me being nitpicky, but I still think that it’s very useful to know --amend
I would agree, with the caveat that --amend should NOT be used on any branch that others would be touching. The reason being that --amend changes git history, so if someone has pulls the branch down between your initial commit and the amend, then adds their own commits in parallel to your amend, you’re almost guaranteed to have merge conflicts to fix/history to reconcile when both push again. Fixing this is very much not a “beginner”/“novice” skill. For this reason, I find it easier to save teaching that option for slightly more experienced students.
That said, either --amend or rebase should be used locally to clean up those errant commits, OR you should be using pull requests in github and choosing “rebase merge” (or “squash merge”) after reviewing the changes. This will give you the clean history without risking git history related issues.
I’ve found that VSCode has super intuitive support for basic git. As long as you have someone on the team that is slightly more familiar (to guide the ones who only know basics and handle merge conflicts), just using that UI goes a long way. You don’t even need to dig into branching and rebasing to have basic version control.
For an anecdote, I’m working with 3 new programmers this year, 2 pretty much completely new to the concept of programming, and none familiar with version control. Within about a month in the Fall (and with me not pushing that hard, while also teaching them how to use the language), I got them to the point of being comfortable enough to at least have some muscle memory for it, on par with a lot of professionals (so not great, but okay enough).
The other option here is to learn how to git rebase to combine multiple small commits into bigger ones before pushing. I personally like to commit often on my local branch to have lots of granularity and then rebasing into a couple larger commits before pushing to the remote.
Huge +1 to learngitbranching—the interactive visualizations make it way easier to understand than any written tutorial can, especially when things get non-linear or you need to use relative references or stuff. Would recommend this to anyone learning git who isn’t already familiar with command line tooling.
To the 1% who (only?) make local backups make sure that at least one copy is often taken “off-site” - such as every day. A backup isn’t a backup unless it’s in a different fire or weather zone depending on your climate.
I have personal experience with six occasions of the horrendous mess and costly inconvenience of a burst water pipe.
if your team has multiple people programming on more than one laptop/computer, I would very much recommend GitKraken. Clone your repository from github and its interface is fairly simple to understand
There’s obviously some CD bias at play, but these results are encouraging. It’s really not possible to develop anything more than a toy project without some VCS, and git is industry-standard for a reason.
My team used to do version control (or lack thereof) with USB drives. After a push from a programming mentor and multiple instances of the ‘newest code’ being misplaced, we switched to GitHub.
We police our github usage pretty extensively, otherwise its easy for kids and mentors to get lazy about it or not use best practices (or push stuff to the wrong places when cleaning up for the day).
We’ve also got a student pushing the commit hash to our dashboard so we know exactly which commit is deployed to the robot which will help when debugging stuff. @dh28567
