You are not Logged In!

Difference between revisions of "Public:GitHub"

From Illini Solar Car Wiki
Jump to navigation Jump to search
 
(27 intermediate revisions by 8 users not shown)
Line 1: Line 1:
−
{{WIP|Moving to subpages, getting rid of tabs, adding info for the other Repos. This page will turn into generally using github|Jonathan}}__NOTOC__
+
''For Managing GitHub see: [[GitHub Management]]''{{RemarksBox Info
−
{{RemarksBox Info
 
 
   | Title      = Note
 
   | Title      = Note
−
   | Text      = This page is about the set-up and workflow we use on Github. Other pages are used for how git is used with certain software such as [[KiCad]] or [[MCUXpresso]]. Additionally, it does not include info about github management, teams, and projects as used by Illini Solar Car, which is at [[GitHub Projects|GitHub Projects]]
+
   | Text      = This page is just generally about setting up and using Git and GitHub. See specific instructions for workflows on each repo in their subpages linked below.
 
}}
 
}}
  
−
Illini Solar Car has several git repositories within our organization [https://github.com/illinisolarcar|organization 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 [https://git-scm.com/downloads| 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 unless you know what you are doing.  
+
[https://www.github.com/IlliniSolarCar GitHub] is a website for hosting and working with [[Wikipedia:Git|Git]] repositories. Git is a distributed version control system for text based files (primarily software) created by the Linux Kernel development team. Unlike most version control systems, it is distributed which means that every single person has the full fledged repository on their machine and thus there is no single point of failure. For collaboration there need to be one copy of the repository that is the origin that is accessible to everyone to push/pull their changes to. For us, that is on GitHub. If you do not currently have a GitHub account you will need to make one. Please make sure your GitHub account has your illinois email address on it (either as primary or secondary) so that we can easily add your account.
  
−
If you're new to Github they're many resources on the internet to learn more about it. Watching some youtube videos on the basics and trying it out by creating your own repository is a great way to get started.
+
GitHub adds many features on top of just git, including issue tracking and [[GitHub Projects|projects]], [[Wikipedia:Continuous integration|Continuous Integration]] including [[GitHub Actions]], Releases, and more. Below you'll find info for general use of git and links to pages for specific instructions for each of our repos. To get access to GitHub talk to an Electrical Lead or Telemetry Lead.
  
−
= General Guidelines=
+
== Active ISC GitHub Repos ==
−
* Make your commit messages useful
 
−
* Pull often!
 
−
* Commit often (but not too often)
 
−
* If you aren't sure what you are doing ask for help!
 
−
* If you think you broke something talk to someone right away!
 
−
** It essentially always fixable but we want to do so quickly so others don't run into problems
 
  
−
= Info on how to use git by group:=
+
=== Electrical ===
 +
* Hardware
 +
** [[GitHub/PCB]] - for all boards
 +
** [[GitHub/isc-hw-libs]] - hardware libraries for the boards
 +
* Firmware
 +
** [[GitHub/b-fw]] - Brizo's Firmware
 +
** [[GitHub/mbed]] - Operating System for our firmware
 +
** [[Github/FW-MCC]] - MCC Firmware
 +
** [[Github/FW-BMS]] - BMS Firmware
 +
** [[Github/FW-Wheel]] - Wheel Firmware
  
−
<tabs>
+
=== Telemetry ===
−
<tab name="PCB">
+
* [[GitHub/Telemetry]] - the telemetry application
−
== PCB==
+
* [[GitHub/Athena-v2]] - race strategy software
  
−
Our PCBs are developed in [[KiCad]] and are stored on GitHub.The [https://github.com/IlliniSolarCar/PCB PCB repository] is ongoing and will likely continue as the location for PCBs until there is a major change.
+
=== Shared ===
 +
* [[GitHub/CAN]] - defines our CAN Bus Specifications for firmware and CAN
 +
{{Collapsible Box|title=All GitHub Subpages|content={{Subpages}}|autocollapse=true|width=}}
  
−
The component libraries for PCB design are stored in a [https://github.com/IlliniSolarCar/isc-hw-libs|separate repository]. This repo is public. It is [https://git-scm.com/book/en/v2/Git-Tools-Submodules submoduled] into the PCB repo for use in our hardware design.
+
== Installing Git ==
 +
Most of our team members use Git from the command line exclusively, and we recommend that you do too in order to git (haha) on the same page as everyone else.. It will help make sure that you learn and understand the tool and give you the full powers of Git, as most git GUI programs aren't able to provide all the features.  
  
−
''Using git for PCBs started in 2017/18 when we switched to Kicad. Before that we used [https://diptrace.com/|DipTrace] which does not use git compatible files. Our older PCBs may not be on GitHub, but they should be available on [https://uofi.app.box.com/folder/44871834665 Box] as PDFs.''
+
=== Linux ===
 +
You are done, it ships with git - congrats! {{Emoji Grin}}
  
−
===Initial Setup===
+
=== MacOS ===
 +
Many Macs also ship with git, you can check by running <code>git --version</code>. It will either tell you the version or how to install it.
  
−
In order to get the PCBs onto your computer, use <code>git clone --recursive <repo URL> <optional custom folder name></code>. The <code>--recursive</code> 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 <code>git submodule update -- init </code> to find any un-cloned submodules and clone them.
+
=== Windows ===
 +
On windows you need to install git, we recommend git bash for windows:
 +
* Download Git Bash for Windows: https://git-scm.com/downloads
 +
* Run the Installer
 +
* When ''Adjusting your PATH environment'', I recommend selecting "Use Git from Git Bash" and not using it from the Windows command prompt.  
 +
* When ''Configuring Line Ending Conversion'' please use the default for your operating system unless you know what you are doing.
  
−
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.
+
== Using Git and GitHub ==
 +
If you're new to git and/or github there are many resources on the internet to learn more about it. Watching some youtube videos on the basics and trying it out by creating your own repository is a great way to get started.
  
−
To open a PCB that is being designed (i.e. not on master), checkout the branch using <code><nowiki>git checkout <branch> --recurse-submodules</code>. If you forget the submodule option, use <code>git submodule update</code> to get the correct libraries. If you do not have the correct libraries you will only be able to see the components that were in the submodule version linked from the master branch.
+
=== General Guidelines===
−
 
+
* Commit often (but not too often)
−
''If you cannot get components from our libraries to work for a PCB, it may have been designed before the big libraries update that came with Kicad 5. See info on the [[KiCad]] page about upgrading projects.''
+
* Make your commit messages useful
−
 
+
* Pull often!
−
=== PCB Repo Workflow===
+
* Keep your branches limited in scope
−
 
+
* Name your branches and Pull Requests Nicely
−
Designing PCBs is not a collaborative project; multiple people can't work on one board at the same time independently without a lot of things getting rewritten or messed up. Therefore git is mostly just a versioning tool and the PCB repo is mostly linear. Every PCB will have its own development branch. If needed (there are new parts) it will have its own corresponding branch on the hardware libraries.
+
* Describe what you did on your Pull Requests
−
 
+
* If you aren't sure what you are doing ask for help!
−
When a board is ready for review a pull request (PR) will be opened. If applicable a PR on the libraries repo will be opened too. Note that the libraries PR must be merged and the libraries submodule on the PCB branch must be updated to master ''before'' it is merged. Pull requests will be merged into master once reviewed and approved.
+
* If you think you broke something talk to someone right away!
−
 
+
** It essentially always fixable but we want to do so quickly so others don't run into problems or base their new work on broken things
−
Boards will only be manufactured if they are on master. Some past boards on master may not have been manufactured, but in general the master branch is boards that have been made and other branches are boards that are in progress.
+
[[File:Gitworkflow.png|frame]]
−
 
 
−
===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 <code>git add <files> </code> To stage all changes use <code>git add</code> or <code>git add -a</code>
 
−
#Commit the changes using <code>git commit -m "<commit message>"</code>Include a useful message to help people reading through the history see what was done.
 
−
#Push the changes to GitHub using <code>git push</code>
 
−
 
 
−
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 <code>Libraries</code> directory. This is to ensure changes are being made to the library repository, instead of the PCB repository.
 
−
#Stage( <code>git add</code> ), commit( <code>git commit</code> ), and push( <code>git push</code> ) the Library changes as described above.
 
−
#Change your working directory to the PCB repo
 
−
#Stage your changes. '''Make sure''' <code>Libraries</code> '''is included or the changes in the libraries will not update on GitHub'''.
 
−
#Commit and push as above.
 
−
 
 
−
If you do not do this, git will not have the right libraries associated with your PCB branch. When others open it and update their submodule they won't be able to see the components you added to libraries.
 
−
 
 
−
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 <code>git pull --recurse-submodules</code>
 
−
#If you forgot to add <code>--recurse-submodules</code>, use <code>git submodule update --init</code>
 
−
 
 
−
 
 
−
===Starting a project===
 
−
# Create and checkout a branch for your project in both the PCB and Libraries repositories using <code>git checkout -b <branch></code>
 
−
# Copy the latest template from the <code>Dev</code> 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 <code>.kicad_wks</code> 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 <code>git push --set-upstream origin <branch></code> to create the branch on GitHub
 
−
 
 
−
</tab>
 
−
 
 
−
 
 
−
<tab name="FW">== FW (Firmware)==
 
−
 
 
−
This repository is for the vehicle firmware (i.e. all on-board software and only on-board software). Unlike PCB there is a separate FW repo for each vehicle.
 
−
 
 
−
Currently we have <code>ARGO-FW</code> (for Argo) and <code>b-fw</code> (for Brizo). The organization of the active repo (i.e. the current car) will follow GitFlow. The older repos will also follow that to extent although once no longer active all of the changes are essentially hot fixes. Please [https://datasift.github.io/gitflow/IntroducingGitFlow.html read more about GitFlow.]
 
−
 
 
−
===Initial Setup===
 
−
 
 
−
In order to get the code onto your computer, use <code>git clone --recursive <repo> <optional></code>. The <code>--recursive</code> 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 <code>git submodule update --init</code> to find any un-cloned submodules and clone them. The submodules in this repo are a fork of mbed and the [[CAN bus|CAN]] repo. Argo uses calsol/mbed and Brizo uses IlliniSolarCar/mbed. Typically you will not need to change mbed and should work with the submodule on master. You will have to work with the CAN repo whenever adding or changing the messages sent on the CAN bus.
 
−
 
 
−
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 work on code.
 
−
 
 
−
To open code on another branch, such as a work in progress or a new feature that needs more testing, checkout the branch using <code>git checkout <branch> --recurse-submodules</code>. If you forget the submodule option, use <code>git submodule update</code> to get the correct version of mbed.
 
−
 
 
−
== Branch organization==
 
−
 
 
−
On the firmware repos there will be many more branches than on PCB. Below is an image showing how a repo using git flow may look.
 
−
 
 
−
[[File:GitFlowHotfixBranch.png|none]]
 
−
 
−
 
 
−
The above image shows the flow of GitFlow. We will utilize that system as follows:
 
−
 
 
−
=== Master Branch===
 
−
 
 
−
Stable code for the car lives here. It should only be tested code that we would be willing to run at competition. This also means that whatever code the car will be using at competition needs to be on master before the competition.
 
−
 
 
−
=== Hot Fix Branches===
 
−
 
 
−
A hot fix branch would be made to fix a bug on the master branch. These should not be branches where significant architecture changes are made. Just changes to fix bugs such as edge cases that were missed. Additionally, at competition any changes made are hot fixes.
 
−
 
 
−
=== Release Branch===
 
−
 
 
−
The release branch is code that is good to be tested on the car. This code has been tested and is stable on the bench and reviewed for use on the car. It can then be tested on the car statically and then driving.
 
−
 
 
−
If you need stable code for other boards to test something on the bench this is where you can get it.
 
−
 
 
−
=== Development Branch===
 
−
 
 
−
This is code is code being tested on the bench. Once the code for your board is ready to go for testing it should be pull requested (and reviewed) into this branch.
 
−
 
 
−
=== Feature Branches===
 
−
 
 
−
Each board will have its own main feature branch where it is all put together. This branch should be maintained by the project leader. Then various features of this project will have their own feature branches. Some boards may be simple enough not to need these additional branches but most will not be. Before creating all of the additional feature branches the code outline should be made on the main branch for that project to organize the code and therefore minimize conflicts in merging.
 
−
</tab>
 
−
<tab name="Strategy and Telemetry">
 
−
 
 
−
The [[Strategy and Telemetry|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 <code>git clone --recursive <repo> </code> and <code>git clone <repo> </code> for the other two.
+
=== How Git Works ===
 +
To the right is a (large) diagram of git. The remote repository is the GitHub repository that you connect to via the lightning (internet).
 +
Before we discuss the local parts we need to briefly have an idea of how git stores information. Git does not store every single version of every single file. Instead it stores the "diff" (difference/changes) for each version in the history. This allows it to efficiently store the information of the full history without repeating and wasting a lot of data. This information is stored in the hidden git folders, so what you see for files on your computer is just your active workspace, but all the info about your local repository is there.  
  
−
The <code>--recursive</code> 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 <code>git submodule update --init</code> to find any un-cloned submodules and clone them. This only applies to the Telemetry repo that contains the CAN submodule with the CAN messages for the car.
+
On your computer you will have 3 distinct areas:
 +
* Workspace
 +
* Staging Area
 +
* Repository
  
−
===About Repos===
+
'''The Workspace'''
  
−
The Telemetry repo primarily holds the code for the [[Telemetry|telemetry]] [[Server and Database Documentation for the Telemetry Application|application]], the app that allows us to view and analyze car data in real time to diagnose issues and make informed decisions.
+
This is the files you see on your computer and where you are actively working.  
  
−
The [[Data Analysis|data-analysis]] repo hold code used to analyze datalogger race data after the races to better understand the car and its performance.
+
'''Staging Area'''
  
−
The [[Athena Version 2|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.
+
Once you have some files ready to go you put them in the staging area. You stage a specific version of a file, Git will keep track of the specific version you stage (via `git add <filename>`) and further changes to that file will not be in the staging area until you stage the file again.  
  
−
===Workflow===
+
'''Local Repository'''
  
−
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.
+
Once you have all the files for this change ready to go you can officially add it to the git history by putting it into your local repository. Next time you push it will also be added to the remote repo. Note that these don't have to be complete changes. You can commit partial changes or the various steps, and this is encouraged, so that you don't lose work and can rollback to intermediate versions later if something changes or goes wrong.  
  
−
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.
+
The diagram to the right also shows that commands to use to get between the different parts. Read our [https://github.com/IlliniSolarCar/git-cheatsheet Git Cheatsheet] for more on how to use each of this commands, I reccomend keeping this open to reference while looking through the cheatsheet.  
  
−
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.
+
=== Try it Out ===
−
</tab>
+
Now that your know a bit about what is going on, why not try it out and see git/GitHub in action! A good way to do this is to do GitHub's [https://guides.github.com/activities/hello-world/ guided hello world activity], this should take you less than 10-15 minutes!
  
−
</tabs>
+
== GitHub Tips ==
 +
Using Git Effectively is an important part of being a contributor to the Electrical and Telemetry groups. Here are some tips for doing so:
 +
* Make sure people can figure out who you are on git - either from a picture or your username being obviously related to you
 +
* Pay attention to the other pull requests and issues happening in the repos you work on
 +
** Its good to see what others are working on
 +
** See how reviews go and what is looked at
 +
** Give input!
 +
* Set up Personal Reminders for ISC: https://github.com/settings/reminders
 +
** The Illini Solar Car Organization on GitHub is linked to the ISC slack, you can set GitHub to send you daily summaries and/or real-time notifications for any of:
 +
*** Your Pull Request being reviewed
 +
*** Your Pull request failing a check
 +
*** Your review being requested
 +
*** And more!
 +
** We reccomend at least getting notifications for your PR being reviewed and people requesting your review on a PR, that way the info doesn't get lost in your email and you can respond timely!
  
 
== Tutorials ==
 
== 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.
 
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.
−
[[File:Gitworkflow.png|thumb|Git workflow]]
 
 
* [https://github.com/IlliniSolarCar/git-cheatsheet ISC Git Cheatsheet]
 
* [https://github.com/IlliniSolarCar/git-cheatsheet ISC Git Cheatsheet]
 
* [https://docs.google.com/presentation/d/1-LV8cFV8CfE6pLvHza3WeOPIuVB4yOZinFEIl2e3QEE/edit#slide=id.gc6f73a04f_0_0 ISC Git Presentation on Drive]
 
* [https://docs.google.com/presentation/d/1-LV8cFV8CfE6pLvHza3WeOPIuVB4yOZinFEIl2e3QEE/edit#slide=id.gc6f73a04f_0_0 ISC Git Presentation on Drive]
−
* [http://www.ndpsoftware.com/git-cheatsheet.html Another Git Cheatsheet]
+
* [http://www.ndpsoftware.com/git-cheatsheet.html Interactive Git Cheatsheet]
 
* [https://git-scm.com/book/en/v2 Git manual]
 
* [https://git-scm.com/book/en/v2 Git manual]
−
* [http://gitref.org/index.html Another good Git reference]
 
 
* [https://www.youtube.com/c/githubguides Github video guides]
 
* [https://www.youtube.com/c/githubguides Github video guides]
−
* [https://try.github.io/levels/1/challenges/1 Interactive intro to git]&nbsp;
+
* [https://try.github.io/levels/1/challenges/1 Interactive intro to github]&nbsp;
 
* [http://learngitbranching.js.org/ Git branching tutorial]
 
* [http://learngitbranching.js.org/ Git branching tutorial]
 
* [https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/ Git merge conflict resolution]
 
* [https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/ Git merge conflict resolution]
 
* [https://www.lynda.com/Git-tutorials/Git-Essential-Training/100222-2.html Lynda.com tutorial]
 
* [https://www.lynda.com/Git-tutorials/Git-Essential-Training/100222-2.html Lynda.com tutorial]
 +
* [https://hkn.illinois.edu/assets/presentations/git.pdf Git Presentation by Dave Boutcher of Ocient]
 +
{{Platforms Navbox|collapsed=}}

Latest revision as of 14:16, 13 August 2023

For Managing GitHub see: GitHub Management

InfoIcon.png Note
This page is just generally about setting up and using Git and GitHub. See specific instructions for workflows on each repo in their subpages linked below.

GitHub is a website for hosting and working with Git repositories. Git is a distributed version control system for text based files (primarily software) created by the Linux Kernel development team. Unlike most version control systems, it is distributed which means that every single person has the full fledged repository on their machine and thus there is no single point of failure. For collaboration there need to be one copy of the repository that is the origin that is accessible to everyone to push/pull their changes to. For us, that is on GitHub. If you do not currently have a GitHub account you will need to make one. Please make sure your GitHub account has your illinois email address on it (either as primary or secondary) so that we can easily add your account.

GitHub adds many features on top of just git, including issue tracking and projects, Continuous Integration including GitHub Actions, Releases, and more. Below you'll find info for general use of git and links to pages for specific instructions for each of our repos. To get access to GitHub talk to an Electrical Lead or Telemetry Lead.

Active ISC GitHub Repos

Electrical

Telemetry

Shared

  • GitHub/CAN - defines our CAN Bus Specifications for firmware and CAN
All GitHub Subpages


Installing Git

Most of our team members use Git from the command line exclusively, and we recommend that you do too in order to git (haha) on the same page as everyone else.. It will help make sure that you learn and understand the tool and give you the full powers of Git, as most git GUI programs aren't able to provide all the features.

Linux

You are done, it ships with git - congrats! 😀


MacOS

Many Macs also ship with git, you can check by running git --version. It will either tell you the version or how to install it.

Windows

On windows you need to install git, we recommend git bash for windows:

  • Download Git Bash for Windows: https://git-scm.com/downloads
  • Run the Installer
  • When Adjusting your PATH environment, I recommend selecting "Use Git from Git Bash" and not using it from the Windows command prompt.
  • When Configuring Line Ending Conversion please use the default for your operating system unless you know what you are doing.

Using Git and GitHub

If you're new to git and/or github there are many resources on the internet to learn more about it. Watching some youtube videos on the basics and trying it out by creating your own repository is a great way to get started.

General Guidelines

  • Commit often (but not too often)
  • Make your commit messages useful
  • Pull often!
  • Keep your branches limited in scope
  • Name your branches and Pull Requests Nicely
  • Describe what you did on your Pull Requests
  • If you aren't sure what you are doing ask for help!
  • If you think you broke something talk to someone right away!
    • It essentially always fixable but we want to do so quickly so others don't run into problems or base their new work on broken things
Gitworkflow.png

How Git Works

To the right is a (large) diagram of git. The remote repository is the GitHub repository that you connect to via the lightning (internet). Before we discuss the local parts we need to briefly have an idea of how git stores information. Git does not store every single version of every single file. Instead it stores the "diff" (difference/changes) for each version in the history. This allows it to efficiently store the information of the full history without repeating and wasting a lot of data. This information is stored in the hidden git folders, so what you see for files on your computer is just your active workspace, but all the info about your local repository is there.

On your computer you will have 3 distinct areas:

  • Workspace
  • Staging Area
  • Repository

The Workspace

This is the files you see on your computer and where you are actively working.

Staging Area

Once you have some files ready to go you put them in the staging area. You stage a specific version of a file, Git will keep track of the specific version you stage (via `git add <filename>`) and further changes to that file will not be in the staging area until you stage the file again.

Local Repository

Once you have all the files for this change ready to go you can officially add it to the git history by putting it into your local repository. Next time you push it will also be added to the remote repo. Note that these don't have to be complete changes. You can commit partial changes or the various steps, and this is encouraged, so that you don't lose work and can rollback to intermediate versions later if something changes or goes wrong.

The diagram to the right also shows that commands to use to get between the different parts. Read our Git Cheatsheet for more on how to use each of this commands, I reccomend keeping this open to reference while looking through the cheatsheet.

Try it Out

Now that your know a bit about what is going on, why not try it out and see git/GitHub in action! A good way to do this is to do GitHub's guided hello world activity, this should take you less than 10-15 minutes!

GitHub Tips

Using Git Effectively is an important part of being a contributor to the Electrical and Telemetry groups. Here are some tips for doing so:

  • Make sure people can figure out who you are on git - either from a picture or your username being obviously related to you
  • Pay attention to the other pull requests and issues happening in the repos you work on
    • Its good to see what others are working on
    • See how reviews go and what is looked at
    • Give input!
  • Set up Personal Reminders for ISC: https://github.com/settings/reminders
    • The Illini Solar Car Organization on GitHub is linked to the ISC slack, you can set GitHub to send you daily summaries and/or real-time notifications for any of:
      • Your Pull Request being reviewed
      • Your Pull request failing a check
      • Your review being requested
      • And more!
    • We reccomend at least getting notifications for your PR being reviewed and people requesting your review on a PR, that way the info doesn't get lost in your email and you can respond timely!

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.

ISC Online Platforms
Communication
Data Storage
(Social) Media
This is all active platforms the team uses. See Online Platforms for previously used or considered platforms
Retrieved from "https://wiki.illinisolarcar.com/w/index.php?title=Public:GitHub&oldid=26732"