Taito CLI provides some version control commands that make it easier for you to follow commonly defined version control conventions. An organization may also override the default version control conventions with a custom Taito CLI plugin.
All commit messages must be structured according to the Angular git commit convention (see also Conventional Commits). This is because application version number and release notes are generated automatically for production release by the semantic-release library.
Some commit message examples:
docs: installation instructions [skip ci]
fix(login): fix header alignment Problem persists with IE9, but IE9 is no longer supported. Closes #87, #76
feat(ux): new look and feel BREAKING CHANGE: Not really breaking anything, but it's a good time to increase the major version number.
You can use any of the following types in your commit message. Use at least types
feat. Normally you shouldn't use the
wip type with dev branch, but you can use it in this tutorial.
wip: Work-in-progress (small commits that will be squashed later to one larger commit before merging them to one of the environment branches)
feat: A new feature
fix: A bug fix
docs: Documentation only changes
style: Code formatting
perf: Performance tuning
test: Implementing missing tests or correcting existing ones
revert: Revert previous commit.
build: Build system changes
ci: Continuous integration changes (cloudbuild.yaml)
If you would rather manage your git branches with GUI tools or git commands instead of taito commands, you can display the version control conventions by running:
The aforementioned command should display the following version control conventions defined by Taito CLI, unless your organization has overridden some of them.
Environment branches: - Branch naming: dev, test, uat, stag, canary, master. - Environment branches should be merged to one another in the following order: dev -> test -> uat/qa -> stag -> canary -> master. - Environment branches should be merged using fast-forward only. - 'dev' is the only environment branch that you should commit changes to. Feature branches: - Branch naming with 'feat/' prefix, for example: feat/delete-user. - Feature branches are created from 'dev' branch and merged back to it using `non-fast-forward` to keep a clear feature branch history. - You should rebase your feature branch with the `dev` branch before merging or creating a pull-request. It is recommended to squash some of your commits during rebase to keep a clean version history. - You should run all tests before merging or creating a pull-request. - You should delete a feature branch once it is no longer needed. Hotfix branches: - TODO
There is a lot to remember. However, if you use Taito CLI for managing your branches, you don't have to remember all these conventions.
Feature branches are handy especially in the following situations:
Code reviews are very important at the beginning of a new software project, because this is the time when the basic foundation is built for the future development. At the beginning, however, it is usually more sensible to do occasional code reviews across the entire codebase instead of feature specific code reviews based on pull-requests.
Note that most feature branches should be short-lived and located only on your local git repository, unless you are going to make a pull-request.
taito feat -h
Create a public feature branch and make some changes to it:
taito feat: delete-post ** Commit and push some changes **
Create a private feature branch, commit some changes to it as multiple commits, merge all changes to the dev branch as a single commit, and delete the feature branch:
taito feat: delete-image ** Commit some changes as multiple commits ** taito feat squash
taito feat squashis a handy command when you are working alone and want to keep version history clean by using feature branches. For team work it is recommended to use
taito feat mergeor
taito feat prinstead.
Switch back to the
delete-post feature branch, make some changes to it, rebase it with the dev branch and merge it using fast-forward:
taito feat: delete-post ** Commit and push some changes ** taito feat merge
Create a public feature branch, make some changes to it, rebase it with dev branch, and create a pull-request:
taito feat: reporting ** Commit and push some changes ** taito feat pr
taito env -h
Change to dev branch:
Merge changes from current environment branch (dev) to the next (test):
taito env merge
Merge changes from dev branch to canary, and to all environment branches in between them:
taito env merge:dev canary
Next: 4. Project management