Using GitLab
Using GitLab for your project has a lot of advantages. Not only is this a way to safely backup your code, it also allows easy version management and will allow others to use your work too, even after you leave the university!
The AIRLab Delft GitLab group is structured as follows:
Robot Packages
The robot packages will be specific to a hardware platform. They will contain common packagfes for its respective platform (e.g. robot_control, robot_description, etc).
The robots that we currently have at the lab are:
- TIAGo ++ (coming soon!)
Generic Packages
The generic packages are implementations of skills or tools a robot can use (e.g. perception of bananas, full body mpc, a script to shake hands etc). These packages are not specific to any robot or any demo. These packages are highly reusable on any robotic platform, acting as modules that can be added to a setup or replace another module in a setup (e.g. full body mpc can replace moveit + movebase).
The generic packages that we currently have available are:
Demo Packages
These packages contain configuration and launch files for specific demos along with demo-specific forks of generic or robot packages. Adding these forks allows for a specific implementation of a generic package that can be changed without altering the upstream repository. Upstream changes also do not affect these forks.
These forks exist to have a copy around of the sources of certain packages that were used during the demo. This way demos are easier to perform without the need for reverse-engineering an old demo.
The demo packages themselves do not contribute a lot of code themselves. Instead, they contain launch files and configurations depending on generic packages outside of the demo organisation.
MSc Students
All MSc students will get a folder in the AIRLab Delft GitLab group in which they can create repositories and store forks of generic packages.
GitLab Do's and Dont's
| Do | Don't | Explanation |
|---|---|---|
| Store versioned files (e.g. code) | Store binary (machine generated) files (e.g. build files, datasets, pdfs) | Binary files are not versioned and take up a lot of space, it doesn't make sense to store non-versioned files in a version control system |
| Use the issue tracker | Write about issues in other places | Keeping issues in one place makes them easy to track |
| Create branches for new features | Work in master branch, possibly breaking it | This prevents issues in master branch due to changes you make to the core code to implement a new feature |
| Use branches for development | Use branches to maintain different funcionalities of the code | All code funcionalities should be available in master branch |
| Merge and remove branches when done | Keep branches for different functionalities of the code | This keeps the repository clean |
| Commit small changes | Commit a lot of changes at once | Small commits make it easier to track when something broke and why |
| Commit often | Commit once in a while | See above |
| Commit with meaningful messages | Commit messages such as 'minor changes', 'bug fixes' | This makes it easier to find what commit broke something or fixed something |
| Add issue # to commit ('fix #6') | Commit with message 'fixed a bug' | This allows tracking of issues and how they are fixed |
| Create a complete README | Leave README empty or incomplete | Everyone should be able to reproduce from README |