We currently use branches with slash (/) delimiters. This means that
our branches often look like this: f/my-feature.
Given a release branch f/my-feature, it's awkward to apply the stage-
prefix: stage-f/my-feature, since this represents a "directory" relationship
in the git filesystem, where stage-f is the directory.
Furthermore, staging is the name of our staging app git remote, which means
that we cannot use staging/ as a prefix instead of stage-. Using stage/
might also cause confusion.
Therefore, to accommodate the slash delimiters most gracefully, and avoid
confusion with the staging/ prefix of branches that live on the staging
remote, this change proposes qa/ as the convention:
Also:
Reasons for
qa/
naming convention:We currently use branches with slash (/) delimiters. This means that our branches often look like this:
f/my-feature
.Given a release branch
f/my-feature
, it's awkward to apply thestage-
prefix:stage-f/my-feature
, since this represents a "directory" relationship in the git filesystem, wherestage-f
is the directory.Furthermore,
staging
is the name of our staging app git remote, which means that we cannot usestaging/
as a prefix instead ofstage-
. Usingstage/
might also cause confusion.Therefore, to accommodate the slash delimiters most gracefully, and avoid confusion with the
staging/
prefix of branches that live on the staging remote, this change proposesqa/
as the convention:release branch:
f/my-feature
qa branch:qa/f/my-feature