Quote:
Originally Posted by PopeRyanI
One other thing I just wondered about is how people manage workflow with multiple programmers. My team uses Github a lot, but we have not really dealt with multiple people working on the same project at the same time. My initial thought was to have people create their own fork and then send pull requests when their code is ready to test on the robot. Then the head programmer (me) would merge their pull requests and incorporate their new commands and subsystems into the Robot and OI files. Thoughts on this system?
|
That's pretty much what we use. The hardest part with something like this is getting the individuals to commit to their online fork frequently (preferred every hour or two of editing) so that it is not lost. (Make sure they understand that "commit" does not mean "cannot be undone"!!)
We also have a rule that only code in the master or another "common" fork is deployed to the robot or hardware test platform. Given the limited number of RIOs around, anything worth testing is worth having in a public pool of code.
As with any project, it is always easiest to manage merging the changes if each thing is only being worked on by one person (or at least in a single fork). Of course, that "thing" may be rather small, and involve overlapping files, so one person might be working on the PID loop, another on the encoder interface, and a third on the driver (main loop).
Have a test plan, particularly include regression testing (that is, test that previous bugs that you have fixed weren't inadvertently re-introduced). Run this test suite weekly or after each major upgrade (e.g. new subsystem or refactoring of code) seems pretty stable, whichever comes first.
Edit: And if you have a specific wiring and/or pneumatics subteam, teach them how to access the info they need from your repository (e.g. pinouts), or provide them a hardcopy update whenever this info changes. Work with them to also get things like their color coding into the repository, whether they make the changes, or submit them to a programmer. It'll make both of your lives easier!!
Edit2: And let me also recommend Robot Builder - as a first step. We use robot builder to create all of the little nitnoid pieces that tie a new subsystem or command in to the infrastructure, then write all the specific code in whichever IDE we're using that year. Our first few years, manually inserting new subsystems caused us much more time to correct than if we had started with robot builder.