Added a note about using git commit --amend

DevelWorkflow.md

@@ -8,7 +8,7 @@ It helps to keep project revision history clean and sane. For example, suppose y
 1. Don't do any work in "master" branch, it belongs to upstream project. Do any work in topic branches. This isn't really related to "git rebase" workflow, it's part of git best practices at all.
 2. Pull upstream changes into your master branch, then propagate to your topic branch using "git rebase master".
 3. When you think you've done with implementing the feature, do self-review using "git log -p master..HEAD". Watch for forgotten debug code, re-read commit messages for clarity and typos, etc.
-4. If you need to do code changes, do new commits to apply small changes you need (like removing a single line with debug printf()). This better be done one by one, with rebase interactive (next step) after each such auxiliary commit, to not lose track.
+4. If you need to do code changes, do new commits to apply small changes you need (like removing a single line with debug printf()). This better be done one by one, with rebase interactive (next step) after each such auxiliary commit, to not lose track. An alternative way to do this is to use git commit --amend which is essentially equivalent to a git commit followed by git rebase -i to squash the two commits together.
 5. Do "git rebase -i master". Your editor will pop up, carefully read instructions. Use "r" action code to edit commit messages, reorder commits and use "f" to apply fix-up commits you created. Be very careful otherwise - it's magic tool, and as any magic, it can do you bad things if you're not considerate. Start slow and careful, you'll get up to speed quickly.
 6. Once satisfied, submit a pull request.
 7. You may get suggestions for changes, if they're small, treat them as fix-up commits, and repeat from step 4.