A draft on developing guidelines for myself and the teams I work with

Development guidelines.md

Git workflow tutorials

General principles

1. Prefer automation to guidelines whenever possible, use tools to automate stuff. Do not write style guidelines; instead, embed linter in your projects and pre-commit hooks instead; use commit templates

2. Create a culture

3. Make tools available

4. Kaizen

Let everybody experiment, learn from each other and embed better techniques in the workflow; encourage a culture where new tools and practises are welcomed.

Resources

Atomic commits

A commit should contain one and only one irreducible unit of change

A commit should contain changes that are related to one single irreducible task. Do not fix a bug while adding a feature. Do not change your build system (.jshintrc, gulpfile, etc.) while doing something else.

Every commit is a single unit of work: you should be able to remove a feature that you added by removing the single commit - without affecting anything else.

http://seesparkbox.com/foundry/atomic_commits_with_git

This brings us to the usefulness of Semantic commit

Semantic commit messages

Commit messages should always use the same format and provide structured information

Using a rigid commit message format helps in keeping your commit atomics.

feat: add hat wobble
^--^  ^------------^
|     |
|     +-> Summary in present tense, imperative form
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

http://seesparkbox.com/foundry/semantic_commit_messages

Semantic commit template

using a template in your git commit editor really helps using a semantic format:

    # If applied, this commit will..                   eol --> |:
    <type>:

    # Message body; Explain why this change is being made:

    # Provide links to any relevant tickets, articles or other resources, e.g.:
    # Closes Redmine#32442, Redmine#23424

    # Allowed <type> values:
    # * feat (new feature for the user, not a new feature for build script)
    # * fix (bug fix for the user, not a fix to a build script)
    # * docs (changes to the documentation)
    # * style (formatting, missing semi colons, etc; no production code change)
    # * refactor (refactoring production code, eg. renaming a variable)
    # * test (adding missing tests, refactoring tests; no production code change)
    # * chore (updating grunt tasks etc; no production code change)

Rebasing - rewriting history

https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history

Git bisect

From the creator

Linus torvalds rules:

• 74 character max
• Header line: explain the commit in one line (use the imperative)
• explain why you did the changes, do not describe the changes

https://github.com/torvalds/subsurface/blob/master/README#L87

better commit messages

git commit templates http://chris.beams.io/posts/git-commit/ https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message