Versions Compared

Version Old Version 1 New Version Current
Changes made by

Peyton McKee

Caio DaSilva

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

What Are Git Submodules

Lets say your you’re bob and you wanna setup a lemonade stand.

...

  1. PARENT BRANCHES POINT TO THE SUBMODULE EQUIVALENT OR SENIOR BRANCH

    1. This essentially means if you have a main branch on a parent repository, this branch can only ever point to the main branch in the submodule, since the main branch is the only branch on submodule that is of equivalent or higher level to the parents main branch.

    2. develop may point to either develop or main of a submodule, since develop is equivalent to develop and main is higher than develop. However this does not mean that develop/fsae in a parent can point to develop/fhe in a submodule. develop/fsae can point to develop/fsae, develop or main in the submodule. This also means that develop in a parent should never point to a feature branch in a submodule. The feature branch should be merged into either develop or main in the submodule and the parent then have its submodule updated.

  2. HEAD to HEAD

    1. This means that heads of parent branches should always be pointing to the head of submodule branches. So, whenever a change to develop in a submodule is made, all applications using that submodule must have their develop branches updated to match the updated submodule. Same with changes to main.

    2. If you are the author of a PR to a submodule, it is your responsibility to understand where the submodule is being used, and make the appropriate submodule updates in the associated applications branches. This ensures that all changes are understood by maintainers of parent repositories.

    3. Feature branches using a higher level branch do not need to be updated by the author of the submodule change, its the responsibility of the maintainer of that feature branch to update as needed.

  3. Parents should review

    1. Ideally a PR should get approvals from maintainers of all parent applications before being merged. This ensures proper understanding of the changes made and how they should affect parent applications so that bugs the maintainers do not understand do not appear.

Submodule Workflow

We have a repository called Embedded Base that contains the drivers, middleware, and communication definitions needed across multiple devices on the car. For this reason, we include Embedded Base a submodule on several parent repositories. I will be using Embedded Base as the example submodule to demonstrate the typical submodule workflow.

Let's say you are assigned a task on a parent repository and it requires a change to one of our drivers in Embedded Base:

  1. Create a new branch for the task in both the parent repository and Embedded Base

  2. Make the necessary changes in Embedded Base and the parent repository to complete the task

  3. Push your commits to the remote branch of Embedded Base and make a pull request

  4. After the pull request is approved and merged, switch to the main branch in Embedded Base and pull the remote changes

  5. In the parent directory, run the following command to point to the updated submodule:

    Code Block
    git submodule update --init

  6. Commit the changes to Embedded base, push to the remote parent repository, and create a pull request