Differences

This shows you the differences between two versions of the page.

--- projects:projects [2026/06/12 08:31] – [voyc git Workflow] jhagstrand
+++ projects:projects [2026/06/12 21:14] (current) – [Deploy] jhagstrand
@@ Line 70: / Line 70: @@
 =====Developer Guidelines=====
+==== Tab Indents ====
+Always use the tab character to indent.
 ====.gitignore====
@@ Line 78: / Line 82: @@
   css.min
   index.php
+  RELEASES.md
 ==== Duplicate Content ====
@@ Line 184: / Line 188: @@
 Trends in release management as of 2026.
-  * 50/72 rule. A commit message has three lines (title, blank, body).  The first line is the title and it is 50 characters long.  The second line is blank.  The third and subsequent lines make up the body; they are bullets, and they are 72 characters long.
+  * 50/72 rule. A commit message has three lines (title, blank, body).  The first line is the title and it is 50 characters long.  The second line is blank.  The third and subsequent lines make up the body; they are bullets, and they are 72 characters long.  [Ed. title is my word.  Other people say description or subject.]
-  * Conventional Commits.  The first line of the commit message is prefixed with a category: feat, fix, perf, style, refactor, test, build, chore.
+  * Conventional Commits.  The first line of the commit message is prefixed with a category: feat, fix, perf, style, refactor, test, build, chore.  This rule overrides an earlier rule that the title should be capitalized.
-  * Semantic Versioning.  Each release is numbered major.minor.patch, like 14.3.5. Modern developers don't bother with backward compatibility; when they break something they assign a new major version number.  They also don't test or debug; when something breaks they fix it and give it a patch number.
+  * Semantic Versioning.  Each release is numbered major.minor.patch, like 14.3.5. When a development group breaks backward compatibility, now a normalized behavior, they assign a new major number.  When a bug is discovered that is so dangerous it must be fixed immediately, they release a patch.
+{{https://en.wikipedia.org/wiki/Conventional_Commits_Specification | more on Conventional Commits}}\\
-[[https://en.wikipedia.org/wiki/Conventional_Commits_Specification | more on Conventional Commits]]
 [[https://semver.org/ | more on Semantic Versioning]] \\
+[[https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html | Tim Pope: A Note About Git Commit Messages, 2008.]]\\
+At voyc we use these above trends in commit messages and tag messages.  The log of commit messages is detailed for developers.  The list of tag messages is more abstract, for users and managers.  Release histories are generated by script from the list of tag messages.
+At deployment, a file named RELEASES.md is generated from the tag messages by a script.  It is not committed; it listed in .gitignore.
-Release history,
+[[..:git | more about log and tag]]
-the changelog.md or release history is generated.
+  # All tags with their full messages, most recent first
+  git tag -l --sort=-version:refname | xargs -I{} git show {} --no-patch --pretty=format:"%tag %*%(tag)%n%s%n%b%n---"
-# All tags with their full messages, most recent first
-git tag -l --sort=-version:refname | xargs -I{} git show {} --no-patch --pretty=format:"%tag %*%(tag)%n%s%n%b%n---"
+  git for-each-ref --sort=-version:refname --format="%(refname:short)%0a%(contents)%0a---" refs/tags
-git for-each-ref --sort=-version:refname \
-  --format="%(refname:short)%0a%(contents)%0a---" \
-  refs/tags
-For each commit:
-  * use conventional commit categorization [[https://en.wikipedia.org/wiki/Conventional_Commits_Specification]]
-For each release:
-  * use semantic versioning
-  * use the 50/72 rule: multiline tag message
-For commit and tag messages:
-  * use the 50/72 rule:
+==== Deploy ====
+  # in laptop dev repo
+  # git filter-repo --mailmap .mailmap --force
+  # lint
+  git checkout master
+  git merge blend
+  git branch -d blend
+  git tag v0.0.0 -m'...'
+  git push origin master --force --tags
+  git push origin --delete blend
+  # in production webserver
+  git fetch origin
+  git reset --hard origin/master
+  git push gitlab master --tags