Everytime you finish with your code changes you have to follow this procedure:
- you should set in stage the changes you want to apply to your local branch
- commit your stage changes to your local branch of your local repository with a commit message
Later, you can also push the commit to your remote branch. Check here to find out how to do that.
The git commands for the above procedure are:
# Check the files in your workspace that have been changed and verify you are in the correct branch
git status
# Select the files you want to put in stage and commit thereafter
git add <files-in-workspace-to-be-staged-space-separated> # if you want all files to be put in stage, then $ git add .
# Optionally, verify that all the files you wanted in stage area are set
git status
# Commit files to your local branch of your local repository
git commit # this opens your default editor to enter the commit message. Elsewise, you can also commit inline using git commit -m '[Issue-Code] <type-of-change>(<files-affected>): your message using the Commit Message Conventions' as shown below[Issue-Code] <type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>Any line of the commit message cannot be longer 72 characters! This allows the message to be easier to read on Github/Bitbucket/etc. as well as in various git tools.
Subject line contains succinct description of the change.
Allowed [Issue-Code]
The Github/Bitbucket(Attlasian Jira)/etc. issue code to which this commit refers to.
Allowed <type>
- feat (a new feature)
- fix (bug fix)
- perf (a code change that improves performance)
- ci (changes to CI configuration files and scripts (e.g. kubernetes, swarm, jenkins, openshift, heroku))
- build (changes that affect the build system or external dependencies (e.g. gulp, npm, yarn, .env variables))
- docs (documentation only)
- style (formatting, missing semi colons)
- refactor (a code change that neither fixes a bug nor adds a feature)
- test (code changes in tests)
- chore (maintain (e.g. remove console.log, unnecessary comments))
Allowed <scope>
Scope could be anything specifying place of the commit change. For example $window, ./App, ./LoginView/style, etc.
<subject> text
- start the subject text with WIP if the commit changes are still in progress and there maybe breaking errors (check the second example)
- use the imperative, present tense: “change” not “changed” nor “changes”
- don't capitalize first letter
- no dot/period(.) at the end
- just as in subject use imperative, present tense: “change” not “changed” nor “changes”
- includes motivation for the change and contrasts with previous behavior
Also check this link
Referencing issues
Commit messages can automatically close/fix/resolve/reopen/etc. issues in Github/Bitbucket/etc. by using some fixed keywords, which you can find in Github, Bitbucket, etc.
For example: This closes #Issue-Code-34, reopens #Issue-Code-23, and refs #Issue-Code-42.
git commit
# this opens your default editor to enter the commit message. Then you can write your message following the 'Commit Message Conventions' shown below#you can also commit inline
git commit -m '[Issue-Code] <type-of-change>(<files-affected>): your message using the Commit Message Conventions' as shown below
# e.g. git commit -m '[Issue-Code-26,Issue-Code-32] feat(LoginView): add terminal name in login auth request
#>
#> Needed for Audit find.
#>
#> This closes Issue-Code-26 and refs Issue-Code-32'Example-1
[Issue-Code-26,Issue-Code-32] feat(LoginView): add terminal name in login auth request
Needed for Audit find.
This closes Issue-Code-26 and refs Issue-Code-32
Example-2
[Issue-Code-17, Issue-Code-29] fix: WIP for e-signature return error, change payload for upload docs
Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw exceptions.
Refs Issue-Code-17, Issue-Code-29