As referenced in #4, we might consider the naming conventions of master and solution branches.
Considering the process of scaling–say we have many teams working in this org and we want to keep all the ui-router content to one repo–there wouldn't necessarily be a master version of a lesson. But different versions that use different examples.
As we scale we might need to justify the purpose and value of a master branch vs branches named after the type of example they hold.
As referenced in #4, we might consider the naming conventions of master and solution branches.
Considering the process of scaling–say we have many teams working in this org and we want to keep all the ui-router content to one repo–there wouldn't necessarily be a master version of a lesson. But different versions that use different examples.
As we scale we might need to justify the purpose and value of a master branch vs branches named after the type of example they hold.