build details

Show: section status errors & todos local changes recent changes last change in-page changes feedback controls

Git usage guide for Fall 2017

Modified 2017-09-11 by Andrea Censi


Modified 2017-10-18 by Jon Michaux

These are the repositories we use.

Git policy for homeworks (TTIC/UDEM)

Modified 2018-05-17 by Andrea Censi

This does not apply to Zurich.

Homeworks will require you to write and submit coding exercises. They will be submitted using git. Since we have a university plagiarism policy (UdeM’s, TTIC/UChicago) we have to protect students work before the deadline of the homeworks. For this reason we will follow these steps for homework submission:

  1. Go here and file a request at the bottom “Request a Discount” then enter your institution email and other info.
  2. Go to exercises-fall2017
  3. Click “Fork” button in the top right
  4. Choose your account if there are multiple options
  5. Click on the Settings tab of your repostory, not your account
  6. Under “Collaborators and Teams” in the left, click the “X” in the right for the section for “Fall 2017 Vehicle Autonomy Engineers in training”. You will get a popup asking you to confirm. Confirm.

If you have not yet cloned the duckietown repo do it now:

$ git clone

Now you need to point the remote of your exercises-fall2017 to your new local private repo. To do, from inside your already previously cloned exercises-fall2017 repo do:

$ git remote set-url origin

Let’s also add an upstream remote that points back to the original duckietown repo:

$ git remote add upstream

If you type

$ git remote -v

You should now see:

origin (fetch)
origin (push)
upstream (fetch)
upstream (push)

Now the next time you push (without specifying a remote) you will push to your local private repo.

Git policy for project development

Modified 2017-10-18 by Jon Michaux

Different than the homeworks, development for the projects will take place in the Software repo since plagiarism is not an issue here. The process is:

  1. Create a branch from master

  2. Develop code in that branch (note you may want to branch your branches. A good idea would be to have your own “master“, e.g. “your_project-master” and then do pull requests/merges into that branch as things start to work)

  3. At the end of the project submit a pull request to master to merge your code. It may or may not get merged depending on many factors.

Because of mathjax bug

No questions found. You can ask a question on the website.