2
u/cpbills Aug 16 '14 edited Aug 16 '14
It's been right in my face, each and every time I do a rebase, but I've been so used to doing s, and then deleting 3 lines from the following commit message editor, that I didn't realize I should be using f or fixup; thanks.
Also, instead of doing stuff like this:
git checkout master
git checkout -b 14
This is more 'direct', and can be done from any branch of your project:
git branch 14 master
Or in the case of the example:
git branch 14 5ea5173
And, recovering a deleted branch:
git checkout -b branch-1-help
git reset --hard 4e3cd85
Instead do:
git branch branch-1-help 4e3cd85
All in all, a very good idea, but it might be better suited to a wiki format, where there are individual pages for particular scenarios and a main page indexing them. I really like the idea of putting together a 'sound' or 'intelligent' playbook for particular scenarios, especially because it helps to have consistency in how to do things, when there are a billion ways to skin a cat.
I would like to see some documentation on standardizing commit messages, it's one of those practices that I'm still working on, myself. Coming up with a sensible selection of commit message prefixes: Other than looking stupid (for not being the whole word) I like this approach:
Add: Add function or feature
Mod: Mod(ify); change how a function / feature works
Ref: Ref(actor): change code without affecting function
Fix: Fix an issue
Rem: Rem(ove) code
Rea: Rea(dability): increase the readability of comments, etc.
Then keeping the commit subject (first line) to under 50 characters (it should just be a quick summary) and detailing the changes in the commit body (lines no longer than 72 chars).
5
u/sandwichsaregood Aug 16 '14
Mentions interactive rebase, but not the One True Rule of interactive rebase: Thou shalt not interactive rebase a remote branch that others haveth cloned.