Howdy all,
I would really like to help my team use git and Github this year. Just not really sure what the best way to do that might be?
So I thought I would ask how others are using it? Do you have a workflow or process that could be shared?
Any insights would be greatly appreciated.
Thanks
Russ
FRC5534 Mentor
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.
Pretty much the same at team 1989. Only thing I might add is that our Git is public so it serves not only as a git purpose but to publish our code stay within the rules of reusing it etc.
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.
If you are using LabVIEW, I recommend checking out the following resources:
This year, I am using GitHub and SourceTree with my team.
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.
When learning to use git, I recommend utilizing the Desktop program, but for those who want to use command prompt, use this: https://gist.github.com/davfre/8313299 and https://www.digitalcitizen.life/command-prompt-how-use-basic-commands
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.
Use GitKraken, https://www.gitkraken.com/. It is free and has become pretty much the industry standard on Windows, Mac and Linux.
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.
Especially when VSCode has pretty darn good git support built in. For my day job I almost exclusively use VSCode plus git CLI.
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.
By any chance is that java training repo public or shareable? Sounds like a fabulous idea.
Thanks
Russ
QFT. Having known-good points in time that you can easily roll back to is one of best and simplest ways you can add layers of safety into your software development processes.
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.
Russ
Mentor FRC 5534
It is currently not public as it is not fully complete. We hope to have it public by next season.