Skip to content

Instantly share code, notes, and snippets.

@noelworden

noelworden/Standardized_Commits.md

Last active August 24, 2023 08:45
Show Gist options
  • Star 4 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save noelworden/cf0c428f19be57ec0e495f7e04d24ebc to your computer and use it in GitHub Desktop.
Save noelworden/cf0c428f19be57ec0e495f7e04d24ebc to your computer and use it in GitHub Desktop.
Download ZIP
How to standardize git commit messages, #helpers
Raw
Standardized_Commits.md

  • Why standardize messages? Its clean. Easy to see what changed and when. As an up-and-coming developer, my repos will probably be potential employers first impressions of me. Clean code (proper indentions/spacing etc) and formatted commit messages help show that I care about my code.

  • The workflow is to create a .txt file as a template, and configure git to use that file as the default message when commiting.

  • The key is the character count. Note the dashed lines representing 50 characters for the summary, and 72 for the description.

####implimentation####

  • cd ~ #to confirm in the home directory

  • touch .testgitmessage.txt #this is the file to be filled in

  • add text to message with desired editor

  • git config --global commit.template ~/.testgitmessage.txt #sets git to use the file as the commit message

####message####

[]
#------------------------------------------------
#[ FEAT BUG CHG REFAC PERF DATA TOOL COPY DOC SPEC WIP ]
#Do not exceed above line in commit txt length
#------------------------------------------------



#----------------------------------------------------------------------
#Description of why, not how.
#Link to issue, if needed.
#wrap desc. text at the end of the above line, do not exceed line
#length
#---------------------------------------------------------------------
#FEAT - feature ,new stuff to the site
#BUG - any bug fix you put in place
#CHG - change that is NOT a refactor or a COPY change
#REFAC - refactors existing code but does not change functionality
#PERF -  effects the performance of the application, ie: adding sidekiq or where-exists
#DATA -  only effects the data directly, ie: add to or remove from the seed file
#TOOL - does not directly effect site users, developer or testing space, ex: pry or rubocop
#COPY - only text changes
#DOC - changes to documentation
#SPEC - any test or spec changes
#WIP- work in progress. USE SPARINGLY

####resources:####

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment