Students use one of a pool of laptops on the team (for the most part), so we just make branches in the main repo and do PRs to master instead of forking and doing cross-repo PRs. We disable git credential caching so commits made are credited to whoever is working at the time.
We start every season with a lofty goal for group and peer reviews which usually breaks down once the mechanical team actually gives us a robot to test on
We make a new branch when we go to each competition and make all fixes in there which we evaluate back at home before merging to master (because we may have made quick bandaids to account for miswiring that can be fixed, or mechanical problems, etc).
As far as actually teaching and using git, I explain the basics of what branching, committing, pushing, fetching, and merging are. I then give the kids a limited number of commands that they are “allowed” to use (checkout (-b), add (-u), commit -m, fetch --all, merge, push) - if a student is truly interested to know more I will help them. Merge conflicts are mentioned and handled with a mentor if they occur.
I’ve been trying to get mine to use ‘add -p’ to make more topical commits. Otherwise you end up with one giant commit after someone has run their rototiller through the code and the commit message says “kinda works now”
It’s gratifying when you can see a student go from “bah, I don’t need this” to using it for their school projects because they’ve learned how to derive some value from it.
My team has a java training repo that all students have to create their own branch to use, this makes it easy for me to check on their progress and have them using git as soon as they join the team. We also do not assign laptops so student have to push if they want to be able to save their code. We also require commit messages that actually explain what was changed and we try to show them good messages and give them feedback on them.
Once they are familiar with git, we have a branch for every task for the subteam. We keep track of these tasks using trello/scrum. This means that any student can work on any code. As an example, if the two people on elevator are gone, someone would volenteer to work on that at the beginning on the meeting if that is critical and then they would pull the elevator branch, work on it and then commit at the end of the meeting. Then they will do a short recap of what they did so the rest of the subteam knows whats up and another person could continue where they left off.
Reviewing comes with PR and only captains/menters can accept them. We require all code to be reviewed before merging with master (Usually happon out of meetings).
As for actually using git we use the built in intellij interface, though we have used tortoise git in the past.
Oh I should mention, we have tried both git GUIs and IDE integrations in the past and we somehow always get into some messed up state, 2 years ago we retreated to just using git bash (which we can now just start as a terminal in VSCode). Different things work for different teams, though.
We do that as well. Generally, at a competition (during a lull or the night after) we can deal with splitting up each change into commits, but the workflow of creating a branch, Github pull request, etc. didn’t work well during pre-competition sprints and the competition itself. We use a more traditional Github Flow based branching model (with branches for each feature or component) for our software library and during the earlier parts of build season.
All code needs to be reviewed by another member of the software team before it’s merged into the master branch of any of our repositories. That way, we can merge things quickly even if some people aren’t available, but we always have two sets of eyes on all our code.
In terms of interfacing, we generally use the (excellent) Git integration in IntelliJ IDEA.
Last year, only me and two other mentors worked on the robot code. When it was just one of us working on the robot, we pushed to master. If we were working on something at the same time, we each usually have our own branch to work on and will eventually merge them.
During competition when it was just me working on the code, I pushed to master.
If more people work on the robot this year, they’ll probably get their own branch to work on and we’ll merge their code as well.
I’d dispute that it’s the “industry standard.” Personally, I prefer having Git right in my IDE, and I know many if not most like the power and flexibility of the command-line. It’s all the same thing under the hood so it really comes down to personal preference.
I think GitKraken is excellent for FRC, it is much simpler than the CLI which does have more features, but IMO most of them are overkill for FRC. Currently we are using GitKraken or the built in Git integration in IntelliJ IDEA.
I can only speak from my experience as a student on a team. On my old team, we used GitHub for repository hosting, and as an issue tracker. We had an organization with repositories for each project (one per vision co-processor, one per robot type (Competition Robot and its Prototype shared a codebase), etc), and each repository had its own issues created. While we didn’t write unit tests for our code, each java repository had a Travis CI configuration file so whenever there was a commit pushed to a remote branch, it would try to download the dependencies and build the project. Each master branch was protected so that modifications had to come via a Pull Request approved by a maintainer. Anyone could be a maintainer, but with the understanding that if you broke the master branch (or lead to a situation where faulty code was deployed onto a robot during a competition) you’d permanently lose the ability to be a maintainer, so this gave everyone to opportunity to be a maintainer while understanding the responsibilities that came with it. In addition for a pull request to be approved, the associated Travis CI build needed to pass. If a maintainer merged code whose CI build didn’t pass, they’d be extra blacklisted. When someone wanted to work on an issue, they would assign it to themselves and they’d create a remote branch. Each pull request had to have an issue associated with it (e.g.: Fixes #254 in the description). Each student has their own laptop, and unfortunately we all had to run windows. I personally used the git CLI available from git-scm.com, while others used a GUI (I think it was SmartGit). I personally despise using a GUI (except the git integration in IntelliJ/Jetbrains IDEs, due to how easy it is to commit granular changes), and I strongly encouraged peers to use the CLI, because a part of an FRC education should be familiarizing yourself with CLI tools, especially if you’re using GradleRIO. The workflow changes for events. Each day at events we’d assign someone to be on duty, and they would create a branch in the form of mabosday0 or nedcmpday2. From then on the code that was on their branch was what would be deployed to the robot. If they needed to make modifications, like changing a constant, then they would create a test branch, commit the change, and test the change on the robot before merging it into the event branch. At the end of the day they’d push their local event branch to the remote. This ideally ensures that you know which code to push to the robot, and gives you the flexibility to make changes at events without much overhead.
Oh, and we had a slack channel where each commit would automatically be announced, so you’d hear your phone going off throughout the night as we neared competition season.
We’ve been using Git for several years now. I used to encourage more branching and pull requests, but I eventually relaxed since I didn’t really see many benefits. Even without much “process” to speak of, the students can still learn Git fundamentals and some good practices for their commits.
If your team uses a chat tool like Slack, as ours does, I recommend making GitHub send a notification for each new commit. That way you can see the students’ work and retroactively review their code, without being a code review bottleneck on everything they do.
Also, I strongly recommend making Git tags before and after events. Crazy things happen in the heat of competition and it’s nice to be able to quickly refer to a previously good state.
I really like ideas about creating a branch for each competition, and reviewing and merging back to master after each event. Really going to try to push that idea this year. Also trying to emphasize to the students, add 1 thing. Commit. Fix 1 thing. Commit. Also using real and meaningful commit messages.
Thanks again, and keep the ideas flowing.
Mentor FRC 5534