Guidelines when you are ready to make changes in existing code of yours or another's and you want to commit them and then push them without creating merging problems.
A. Create a branch or checkout an existing branch that your code changes are going to affect, and if needed only the first time you work at this repo clone, then the repo locally
B. Do your Changes
Everytime you finish with your code changes you have to follow this procedure:
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:
[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
[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
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
#>
[Issue-Code] <type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
# 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
git clone http://<username>@<remote-project-directory>.git
git checkout master
git checkout -b <development branch> # e.g. git checkout -b dev
git checkout -b <development feature branch> # e.g. git checkout -b dev/featureA
# optionally, just to verify you are in the correct branch
git branch
git checkout dev/<featureA>
git fetch -p
git merge
# create new branch
git checkout -b <new branch> #(convention: <new branch> should follow this instruction: dev/<featureA>$<type-of-change>/<name-of-feature-or-component-affected-by-changes>)
# e.g. git checkout -b dev/featureA$feat/Login
# optionally, just to verify you are in the correct branch
# update the dev/<featureA> branch
git checkout dev/<featureA>
git fetch -p
git merge
# checkout the existing remote branch
git checkout <remote-branch> # e.g. git checkout dev/featureA$feat/Login
git rebase dev/<featureA> # if there were changes in dev/<featureA>, then after having merged above, re-base the <remote-branch> on dev/<featureA> to apply all changes again on the new base that is set from the dev/<featureA>