This guide will help you get started with working with repositories within this github organization. It will cover how to work with repositories, how to work with branches, and how to work with pull requests.
The most useful commands can be found here for quick reference.
Commit messages should be clear and concise, try and summarize what you did as breifly as possible such as "Fix Bug 208" or "Add Telemetry Downlink". If you need to go into more detail, then you can add a description to the commit message.
For the main message follow this guide:
[Add/Fix/Remove/Update/Refactor/Document] [summary]
For the description consider answering these questions:
- Why is it necessary? (Bug fix, feature, improvements?)
- How does the change address the issue?
- What side effects does this change have?
Do not push directly to the main
branch.
- Create a
dev
branch to manage your changes. - Push updates to the
dev
branch from your local computer. - Merge the
dev
branch intomain
when the code is stable and ready.
# Create the dev branch and push your latest commit to it
git checkout -b dev
git push origin dev
- Do not use
main
for development. - Follow the guidelines in Pushing to Branches to collaborate effectively.
This workflow ensures the main
branch remains stable and avoids conflicts during development.
If you are working on a feature or bugfix, find the branch that seems most relevant to your current task and push to that branch with the proper commit messages. If you are working on a new major feature, or there is no related branch to the issue you're working on, see Branches for how to create a new branch.
Pull requests should be made when you are ready to merge your changes into the master branch or a feature branch. This should be done when you have completed a feature or bugfix, or when you have reached a good stopping point in your work.
When pulling into the master branch your pull request will have to be reviewed by another member of the team. This is to ensure that the code is up to the standards of the team and that there are no obvious bugs or issues with the code.
New branches should be created when a new major feature in the software is being worked on or there is no related branch to the issue you're working on. Branches can be named flexibly, but should generally fall under one of these categories.
Categories:
- Feature Branches (
feature/
)- For new features or functionalities.
- Example:
feature/add-gyroscope-support
- Test Branches (
test/
)- For adding unit, integration, or other tests, especially those with temporary changes.
- Example:
test/gyro-integrity-checks
- Bugfix Branches (
fix/
)- For fixing bugs in production or feature branches.
- Example:
fix/gyro-range-error
- Refactor Branches (
refactor/
)- For improving code structure without changing functionality.
- Example:
refactor/reorganize-sensors
- Chore Branches (
chore/
)- For non-code changes like documentation, configuration, or build scripts.
- Example:
chore/update-readme
- Create a new local branch based on the change you plan on making.
git branch feature/gyroscope
- Checkout your branch
git checkout feature/gyroscope
- Edit the code to make your changes
- Add the edited files to be staged
git add sensor_handling.py
- Commit the staged changes to your local branch
git commit -m "Add gyroscope support"
- Push the changes the remote repository
git push origin feature/gyroscope
- Within GitHub, create a pull requests to merge the new feature into the master branch.
- Once the pull requests is approved, the code has been succesfully changed.