Tips for Git

Contents

1. Commit message style
2. Merge maint-x.y to master

Commit message style

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) if build(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 use BREAKING CHANGE: in the commit log body. Example:

  feat(api): some incompatible change (#44)
  
  BREAKING CHANGE: some incompatible change explained in commit body (#44)
  

Merge maint-x.y to master

$ 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