jordan-gillard · January 15, 2025 20:16 · jordan-gillard · Jan 7, 2025
diff --git a/.git-commit-template.txt b/.git-commit-template.txt

 #------------Subject Line Length (50)------------#
 #-----------------------Body Line Length (70)------------------------#

 #---------------------------------TYPE-------------------------------#
 # build:    Changes affecting build system or external dependencies
 #           (example scopes: gulp, broccoli, npm)
 # ci:       Changes to our CI configuration files and scripts
 #           (example scopes: Travis, Circle, BrowserStack, SauceLabs)
 # docs:     Documentation only changes
 # feat:     A new feature
 # fix:      A bug fix
 # perf:     A code change that improves performance
 # refactor: A code change that neither fixes a bug nor adds a feature
 # style:    Changes that do not affect the meaning of the code
 #           (white-space, formatting, missing semi-colons, etc)
 # test:     Adding missing tests or correcting existing tests

 #-------------------------------FORMAT-------------------------------#
 # <type>(<scope>): <subject>
 # <BLANK LINE>
 # <body>
 # <BLANK LINE>
 # <footer>

 #-------------------------------SCOPE--------------------------------#
 # may be provided to a commit’s type, to provide additional
 #   contextual information and is contained within parenthesis,
 #   e.g., feat(parser): add ability to parse arrays.

 #-------------------------------FOOTER-------------------------------#
 # The footer should contain any information about Breaking Changes
 #   and/or reference GitHub issues that this commit Closes.
 # Breaking Changes should start with "BREAKING CHANGE:" with a
 #   space or two newlines. Rest of commit message is used for this.
 # Footers other than BREAKING CHANGE: <description> may be provided
 #   and follow a convention similar to git trailer format, like:
 # Fixes: ISSUE / COMMIT
 # Helped-by: AUTHOR <EMAIL>
 # Reference-to: ISSUE / COMMIT
 # See-also: ISSUE / COMMIT
 # Cc: AUTHOR <EMAIL>
 # Reviewed-by: AUTHOR <EMAIL>
 # Signed-off-by: AUTHOR <EMAIL>

	#------------Subject Line Length (50)------------#
	#-----------------------Body Line Length (70)------------------------#

	#---------------------------------TYPE-------------------------------#
	# build: Changes affecting build system or external dependencies
	# (example scopes: gulp, broccoli, npm)
	# ci: Changes to our CI configuration files and scripts
	# (example scopes: Travis, Circle, BrowserStack, SauceLabs)
	# docs: Documentation only changes
	# feat: A new feature
	# fix: A bug fix
	# perf: A code change that improves performance
	# refactor: A code change that neither fixes a bug nor adds a feature
	# style: Changes that do not affect the meaning of the code
	# (white-space, formatting, missing semi-colons, etc)
	# test: Adding missing tests or correcting existing tests

	#-------------------------------FORMAT-------------------------------#
	# <type>(<scope>): <subject>
	# <BLANK LINE>
	# <body>
	# <BLANK LINE>
	# <footer>

	#-------------------------------SCOPE--------------------------------#
	# may be provided to a commit’s type, to provide additional
	# contextual information and is contained within parenthesis,
	# e.g., feat(parser): add ability to parse arrays.

	#-------------------------------FOOTER-------------------------------#
	# The footer should contain any information about Breaking Changes
	# and/or reference GitHub issues that this commit Closes.
	# Breaking Changes should start with "BREAKING CHANGE:" with a
	# space or two newlines. Rest of commit message is used for this.
	# Footers other than BREAKING CHANGE: <description> may be provided
	# and follow a convention similar to git trailer format, like:
	# Fixes: ISSUE / COMMIT
	# Helped-by: AUTHOR <EMAIL>
	# Reference-to: ISSUE / COMMIT
	# See-also: ISSUE / COMMIT
	# Cc: AUTHOR <EMAIL>
	# Reviewed-by: AUTHOR <EMAIL>
	# Signed-off-by: AUTHOR <EMAIL>