Git

2910 readers

2 users here now

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Resources

Rules

Follow programming.dev rules
Be excellent to each other, no hostility towards users for any reason
No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

founded 1 year ago

MODERATORS

[email protected]

What's your commit message style? (programming.dev)

submitted 1 year ago by [email protected] to c/[email protected]

14 comments fedilink hide all child comments

cross-posted from: https://lemmy.sdf.org/post/1352760

Was digging through a project at work today where some guy in 2014 made 100+ commits in a single day and the only one that had a comment said "upgrading to v4.0".

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

Driven through me as Lead Developer, we've adopted a Conventional Commits style using convco for conformance check and changelog/release note generating (customized template).

feat(auth): Introduce configurable permissions (ticketref) (!MR)

We've extended allowed/used types of fix and feat to include docs, test, refac, and misc. We explicitly decided against types like @CodeSupreme linked like style, perf, build, ci, chore, revert. Slim number of types has value. build, ci are scoped to misc(proj) or misc(ci). Reverts are of the original type or misc chores with impact - not a disconnected separate type - and indicated in the commit title.

We develop in branches, and are free to be messy until we found and implemented a solution at which point we clean up commits to an intentional, documented changeset (using Git interactive rebase with squashing etc).

We use a semi-linear history, so once a changeset is approved we rebase and merge with a merge commit - so we only have at most one merged parallel branch in the history tree. The generated changelog only considers merge commits - where the changeset is documented as a whole (same title and description as the merge/review request).