| You are not Logged In! |
Public:GitHub
{REMARKSBOX(type="note" title="Note")}This page is currently in development as is GitHub organization. This page currently exists to define how the github should operate. The GitHub will then be brought up to this spec. - Jonathan (23 Feb 18){REMARKSBOX}
Illini Solar Car has several git repositories within our on GitHub. You must talk with an ((Electrical Group Structure|Electrical Lead)) or Strategy & Telemetry Lead so they can give you access to our private repositories. In general, many people use git via the command line. We use it almost exclusively, and you should learn it in order to git (haha) on the same page as everyone else. On most Linux distros this is included in command line. On Mac and Windows you can download git. When "Adjusting your PATH environment," I recommend selecting "Use Git from Git Bash" and not using git in the Windows Command Prompt. When "Configuring the line ending conversions" please use the settings recommended for your operating system.
{TABS(name="git_repo_tabs" tabs="PCB|FW|Strategy & Telemetry|Tutorials")}
PCB
Our PCBs are developed in ((KiCad)) and are stored on GitHub. Our libraries are stored in a separate, public repository which is submoduled into the PCB repo.
Initial Setup
In order to get the PCBs onto your computer, use -+git clone <nowiki>--</nowiki>recursive <repo> <optional>+-. The -+<nowiki>--</nowiki>recursive+- option looks for submodules in the repo and clones them into the correct directory. If this option was omitted during the initial clone, run the command -+git submodule update <nowiki>--</nowiki>init+- to find any un-cloned submodules and clone them.
Once you have the PCBs cloned onto your computer, follow the instructions to set up ((KiCad)). Once this is done, you should be able to open the latest manufactured PCBs.
To open a PCB that is being designed, checkout the branch using -+git checkout <branch> --recurse-submodules+-. If you forget the submodule option, use -+git submodule update+- to get the correct libraries.
{REMARKSBOX(type="errors" title="Location Error")}The following Info has nothing to do with github directly and should be moved elsewhere{REMARKSBOX}
Starting a project
- Create and checkout a branch for your project in both the PCB and Libraries repositories
- * -+git checkout -b <branch>+-
- Copy the latest template from the -+Dev+- folder
- Rename your file structure to follow the ((Standards|Storage Conventions)) - you will have to rename the folder and each project file manually
- *Do not rename the -+.kicad_wks+- file or you'll be sorry the nice logo and other settings disappear
- Make an initial commit to the Libraries and PCB repositories (in that order) as below
- *For the first push use -+git push --set-upstream origin <branch>+- to create the branch on GitHub
Making changes
The following describes the process for editing PCBs without changing libraries:
- Edit the PCB files
- Stage the changes for the next commit using -+git add <files>+-. To stage all changes use -+git add .+- or -+git add -a+-.
- Commit the changes using -+git commit -m"<commit>"+-. Include a useful message to help people reading through the history see what was done.
- Push the changes to GitHub using -+git push+-
Editing libraries requires a different process, but it's the same whether editing just the Libraries or the Libraries and the PCB files.
- Edit the libraries and PCB files
- Ensure your working directory is the -+Libraries+- directory. This is to ensure changes are being made to the library repository, instead of the PCB repository.
- Stage( -+git add+- ), commit( -+git commit+- ), and push( -+git push+- ) the changes as described above.
- Change your working directory to the PCB repo
- Stage your changes. Make sure -+Libraries+- is included or the changes in the libraries will not update on GitHub.
- Commit and push as above.
Whenever changes are made on another computer, you need to get the changes with the following process:
- Pull the changes to the PCB files with -+git pull --recurse-submodules+-
- If you forgot to add -+<nowiki>--</nowiki>recurse-submodules+-, use -+git submodule update --init+-.
Finishing
TODO
Push your changes
Make a pull request
Create a tag
When you have (nearly) finished a project, you will create a pull request for your branch. You are forbidden from pulling your branch's changes into master all by yourself, in case something gets messed up.
- Go to the PCB repository on the GitHub website
- Click on the drop down menu "Branch: master" and click on your branch name
- Click "New Pull Request" in the button next to the drop down menu
- Add some sort of comment if you want, than click the green button that says "Create pull request"
- On the next page you may see
- *"Review required": you should request a review from someone by clicking "Reviewers" on the right side and finding their username (James is roryee, be sure to bug him)
- *"Merging is blocked" "merging can be performed automatically...": great, actually! You didn't mess with too much and there are no conflicts
- *something something cannot be performed automatically, or merge conflict(s): uh oh. you should check out the diffs (under the "Files changed" tab near the top) and see what you can do about it
- After someone reviews and approves your pull request, you may get an email or notification
- *it's nice when they tell it to merge for you
- *if they don't, you have to go back to the page and do it
- Special for admins: yes you can bypass checks and merge if you want. Use your power wisely.
/////
FW (Firmware)
This repository is for the vehicle firmware (i.e. all on-board software and only on-board software). The organization of this repository will follow GitFlow. Please read more about GitFlow.
Initial Setup
In order to get the code onto your computer, use -+git clone <nowiki>--</nowiki>recursive <repo> <optional>+-. The -+<nowiki>--</nowiki>recursive+- option looks for submodules in the repo and clones them into the correct directory. If this option was omitted during the initial clone, run the command -+git submodule update <nowiki>--</nowiki>init+- to find any un-cloned submodules and clone them. The submodule in this repo is a fork of mbed, which we don't usually change.
Once you have the FW cloned onto your computer, follow the instructions to set up ((MCUXpresso)). Once this is done, you should be able to flash and debug code on our MCUs.
To open code on another branch, such as a work in progress or a new feature that needs more testing, checkout the branch using -+git checkout <branch> --recurse-submodules+-. If you forget the submodule option, use -+git submodule update+- to get the correct version of mbed.
The above image shows the flow of GitFlow. We will utilize that system as follows:
Master
Hot Fix
Release
Development
Feature Branches
/////
Strategy & Telemetry
The strategy and telemetry group currently has 3 repositories: Telemetry, data-analysis, and Athena-v2.
Information about these repositories and their setups can be found in the README.md files in each repository.
clone the repository using -+git clone <repo> +-
About Repos
The Telemetry repo primarily holds the code for the ((Telemetry|telemetry)) application, the app that allows us to view and analyze car data in real time to diagnose issues and make informed decisions.
The data-analysis repo hold code used to analyze datalogger race data after the races to better understand the car and its performance.
The Athena-v2 repo has code that is currently an in-progress project currently delayed until more man and woman power is available to code. The project is a car simulation and optimizer to determine optimal strategy decisions in a calculated and methodical way.
Workflow
The workflow of branches and commits should be similar to how the FW repo works. All work should be done in separate branches if multiple people are working on one feature, they should each have their own branches and merge them together when possible. Branches should not be merged into master until they are known to work without breaking the system.
To merge a branch in to master a pull request should be made and at least two reviewers should be requested. Once these reviewers have approved the pull request can be merged into master.
If changes need to be made quickly and shared and there is not time to follow the review process (for example during a race) a separate branch of master should be made for this. The changes should then be reviewed and cleaned when there is time and then the standard merging procedure should be followed to pull the changes into master.
/////
Tutorials
Git is a super useful tool that is becoming ubiquitous with CS / ECE and more engineering fields. It is used for all sorts of things (not just code) . Version control is incredibly powerful, but because of that it can be hard to learn. Below are some recommended tutorials. Of course, as Git was made for code, there is tons of info on the internet. Being good with git will be very helpful within jobs and academics.
{TABS}