...
After a developer is assigned a Jira task, they begin work:
...
.
Using the type from Conventional Commits, decide what the primary type of work is, such as feat for a new feature
| Expand |
|---|
| title | List of the commit `type` values that we use: |
|---|
|
build: change in build system or dependencies
ci: change in continuous integration / deployment
docs: change to documentation
feat: a new feature is being added
fix: an existing bug or defect is being fixed
perf: change to improve performance
refactor: change to improve code quality
revert: reverts changes in a previous commit
style: change to code style/formatting
test: add missing tests or correct existing tests
|
Ensure that the main branch in your cloned fork is up to date
| Expand |
|---|
| title | The fetch/rebase GitHub workflow |
|---|
|
The fetch and rebase GitHub workflow used by Kubernetes is a common way to keep cloned repos in sync with the origin and upstream repos. |
...
Note: Some people prefer to pull and create merge commits, and that’s fine because we squash commits when a Pull Request is merged into upstream/main.
|
With an example Jira task FORMS-1234 that is a new feat, create a branch off your main with a name like
...
feat/1234-new-map-component
...
...
the branch anything you want, but: |
...
...
...
...
...
Crank out some code and tests (or tests and code, if you like TDD) and whatever docs are needed
This is a test
| Expand |
|---|
|
These are some notes |
...