Consider introducing git commit standards

[jbesraa]

Currently our git history looks very different between the different users. It would be great if we could enforce some standards so its easier to read it.

I propose to use the same Contribution Flow section from rust-lightning: https://github.com/lightningdevkit/rust-lightning/blob/main/CONTRIBUTING.md

Contribution Workflow
---------------------

The codebase is maintained using the "contributor workflow" where everyone
without exception contributes patch proposals using "pull requests". This
facilitates social contribution, easy testing and peer review.

To contribute a patch, the workflow is as follows:

  1. Fork Repository
  2. Create topic branch
  3. Commit patches

In general commits should be atomic and diffs should be easy to read.
For this reason do not mix any formatting fixes or code moves with
actual code changes. Further, each commit, individually, should compile
and pass tests, in order to ensure git bisect and other automated tools
function properly.

When adding a new feature, like implementing a spec object, thought
must be given to the long term technical debt. Every new features should
be covered by functional tests.

When refactoring, structure your PR to make it easy to review and don't
hesitate to split it into multiple small, focused PRs.

The Minimum Supported Rust Version (MSRV) currently is 1.63.0 (enforced by
our GitHub Actions). 

Commits should cover both the issue fixed and the solution's rationale. These
[guidelines](https://chris.beams.io/posts/git-commit/) should be kept in mind.

To facilitate communication with other contributors, the project is making use
of GitHub's "assignee" field. First check that no one is assigned and then
comment suggesting that you're working on it. If someone is already assigned,
don't hesitate to ask if the assigned party or previous commenters are still
working on it if it has been awhile.

Any changes that have nontrivial backwards compatibility considerations should
have an entry added in the `pending_changelog` folder which includes the
CHANGELOG entries that should be added in the next release.

[pythcoiner]

seems contribution flow already here

[jbesraa]

Yea you are right. It is though missing the git commit guidelines:

"Commits should cover both the issue fixed and the solution's rationale. These guidelines should be kept in mind."

[rrybarczyk]

Can we enforce a branch naming convention? Or is that out of scope for the issue?

I prefer <issue number-short-present-tense-description>, for example 813-standardize-cli.

[jbesraa]

Not sure if that is something worth forcing as its not really created in the stratum repo but in the forked repo

[pythcoiner]

Not sure if that is something worth forcing as its not really created in the stratum repo but in the forked repo

agree

[Fi3]

Can we enforce a branch naming convention? Or is that out of scope for the issue?

I prefer <issue number-short-present-tense-description>, for example 813-standardize-cli.

I don't like use issue number (that are a github concept) in commits. IMO git log should not depend on third parties like github.

[rrybarczyk]

Can we enforce a branch naming convention? Or is that out of scope for the issue? I prefer <issue number-short-present-tense-description>, for example 813-standardize-cli.

I don't like use issue number (that are a github concept) in commits. IMO git log should not depend on third parties like github.

That's fair. But we do use github, and if we used a different platform, that platform would still have issue numbers.

Alternatively, we could prepend the year and month like yyyy-mm-branch-name. I believe this is how rust lightning does it. If we do that, I would like to really enforce the use of linking issues and PRs with github's "Development" feature: