release/hotfix branch fails finishing, the user may just try so again.

Require branch and tag to be absent when start is run (for release/hotfix)

Require branch to exist when trying to finish (for release/hotfix)

Die the finish script when either the fetch, checkout or tagging fails.

- Move resolve_name_by_prefix() from git-flow-feature to gitflow-common
- Rename require_name() to require_name_arg()
- Refactor expanding of nameprefixes

- Lower-cased all local variable names
- Explicitly typeset all local variable names, to prevent issues with
  setting/overriding variables in the global namespace.
- Explicitly typed integer types as integer (typeset -i) to enable simpler
  arithmetic calculations on them.

Renamed shFlags.sh -> gitflow-shFlags

this feature branch *including* the changes in the current working tree.

If an explicit feature branch is named (may be a prefix of a branch name),
the diff shows only changes that are already committed.

The only exception to the rule is git-flow-support, which has an
explicitly required <base> argument (since we cannot deduce a sane default
name for base).

Furthermore, these <base> arguments are checked to refer to commits on:
- develop (for feature, release)
- master  (for hotfix, support)

Removed any occurrences of optional <base> arguments in finish subactions.
The finishing target branches are clearly defined by the model. The <base>
argument will probably confuse users. If they want the power to merge
those feature branches into *other* branches then develop, for example,
they can still use the magical power of Git itself for that. Gitflow
should not provide such support.

again, the convenience functions flag() and noflag() have been used and
all occurrences of 0 and 1 are replaces by true and false. This makes it
safe (and more readable!) to test for active/inactive flags.

Also specify $FLAGS_PARENT explicitly, to avoid having the generated usage
texts by shFlags mention the full Unix path to $0, but instead use the
more recognizable varient 'git flow feature'.

Now also installs the shFlags.sh script. (The license lines are included in its header.)

Signed-off-by: Stefan Naewe <stefan.naewe@atlas-elektronik.com>

Fix: do integer comparison, not string comparison. wc returns stuff like '   13', which is perfectly equal to 13.

overview, very Gitish.

Simplify the default "make" message.

Conflicts:

	git-flow-feature

Implement the flags for each of the 'feature' subcommands.

shFlags is a library written to greatly simplify the handling of
command-line flags in Bourne based Unix shell scripts (bash, dash, ksh,
sh, zsh) on many Unix OSes (Linux, Solaris, Mac OS X, etc.).

Most shell scripts use getopt for flags processing, but the different
versions of getopt on various OSes make writing portable shell scripts
difficult.  shFlags instead provides an API that doesn't change across
shell and OS versions so the script writer can be confident that the
script will work.

(Taken from http://code.google.com/p/shflags/)