Tips for Git - reanahub/reana GitHub Wiki
As of January 1st 2024, we have adopted conventional commits style, checked via commitlint and turned into user-facing release news via release-please.
Commit message structure:
<type>(scope): <description> (<#pr>)
[optional body]
[optional footer: BREAKING CHANGE: foobar (<#pr>)]
[optional footer: Closes <#issuenumber>]
Commit message description examples:
feat(api): new endpoint for workflow sharing amongst user groups (#123)
fix(api): properly respect pagination arguments (#123)
build(python): support for Python-3.12 (#123)
build(docker): optimise image size (#123)
build(deps): XRootD 5.5 (#123)
Commit message types:
- build for changes affecting build process or external dependencies (e.g. docker)
- chore for miscellaneous tasks not affecting source code or tests (e.g. release)
- ci for changes affecting continuous integration (e.g. linting)
- docs for documentation-only changes
- feat for code changes introducing new features or backwards-compatible improvements to existing features
- fix for code changes fixing bugs
- perf for code changes improving performance without changing functionality
- refactor for code changes that do not fix bugs or add features
- style for code changes not affecting the meaning (e.g. formatting)
- test for adding missing tests or correcting existing tests
Important notes:
-
Please always check existing scopes before adding new ones. The scopes will appear visibly in the release notes, grouping the news items of the same type together. Avoid
build(dockerfile)ifbuild(docker)exists. -
Please always include
(#123)at the end of the commit message description to indicate the pull request number. This will then be used by release-please to insert links to pull requests in the release news. -
Please don't use
feat(api)!in the commit message headline to indicate breaking changes. This does not work with commitlint. Please useBREAKING CHANGE:in the commit log body. Example:feat(api): some incompatible change (#44) BREAKING CHANGE: some incompatible change explained in commit body (#44)
$ reana-dev git-upgrade -c ALL
$ reana-dev git-checkout -c ALL master
$ cd reana-ui
$ reana-dev git-upgrade -c . --base maint-0.7
$ reana-dev git-upgrade -c .
$ git checkout -b merge
$ git log master..maint-0.7 # what changes we would merge?
$ git merge --log maint-0.7
$ git status # file1.py and file2.py have conflicts
$ vim file1.py # solve conflicts
$ git add file1.py
$ vim file2.py # solve more conflicts
$ git add file2.py
$ git status # all clean
$ git merge --continue # we are done!
$ git diff master merge # inspect all code changes
$ reana-dev run-ci ... # try to run; whoops, it's broken
$ vim file3.py # some other file may needs adaptation
$ git add file3.py
$ git commit --amend
$ git show master:file4.py > file4.py # some yet another file may be easier to edit out again from its master state
$ vim file4.py
$ git add file4.py
$ git commit --amend
$ git diff master merge # one last look
$ reana-dev run-ci ... # let's retest
---
$ git push origin merge
$ gh pr create -t "Merge branch 'maint-0.7'" -b "addresses reanahub/reana#<ISSUE_NUMBER>" --web