We follow some patterns on creating branches and this is related to our workflow in Shortcut.
If you didn't read Pull Requests, we recommend to read it before this guide.
We work with a single stable branch: main. Everything that is merged into it, we assume that already passed in the Test phase properly.
Now that you're familiar with User Story, let's understand how it reflects our branches and accordingly to our Pull Requests:
First, we create a branch using main as the base with the following pattern:
sc-ddd/user-story-card-title
Where ddd stands for Story Card number in Shortcut, check some examples of naming User Story branches:
sc-897/collect-issues-line-numberssc-569/edit-reviewer-authorsc-642/clustering-contribution-data
If you realize that a single branch won't be enough, you can create more branches to detail your work of this User Story card. For example, let us imagine the following scenario:
We have a User Story Collect issues line numbers which its number in Shortcut is 123.
In this case, we can start creating the branch for it using main as the base:
git checkout -b sc-123/collect-issues-line-numbers
After analyzing the requirements we noticed that a single Pull Request would carry too many
changes. So we've decided to break down our changes in n pull requests, to do so we start
creating a new branch using sc-123/collect-issues-line-numbers as the base, then create the
new one:
git checkout -b sc-123/xz-add-database-migrations
Where xz stands for initials of developer, check some examples of naming sub User Story branches:
sc-321/wt-fix-reviews-count-in-repository-pagesc-781/gg-remove-sales-machine-from-subscriptions
If you developed that change in pair programming, you can use both initials ordered alphabetically:
sc-821/gg-wt-add-call-to-action-to-landing-page
Note that you're able to open new branches and Pull Requests as you consider necessary on working in a User Story card. To decide that, always keep in mind: how easy would be to review your code, so Pull Request size will be your guide.