This new subcommand lets you easily work together with peers on features. It's
intended to be extremely simple to pull changes from your co-developers.
This implementation may also be ported to release and/or hotfix branches in the
near future, if we agree on the final implementation details.
Example use
===========
Sharing development of feature branches goes as follows:
Suppose Alice and Bob are both developers on project Foo. They have local
repos that are up-to-date with `origin`. Then, Alice starts working on some
feature:
alice$ git flow feature start newprotocol
Switched to a new branch 'feature/newprotocol'
...
Then, she hacks on the new feature, commits as desired, until the feature's
finished. She then likes Bob to code-review the feature, so she asks Bob to
pull from her. (Assuming Bob has a Git remote defined, pointing to Alice's
repo.)
bob$ git remote
alice
bob$ git branch
* develop
feature/reader
master
bob$ git flow feature pull alice newprotocol
Created local branch feature/newprotocol based on alice's feature/newprotocol.
bob$ git branch
develop
* feature/newprotocol
feature/reader
master
Since the new feature branch is already checked out, Bob can immediately start
peer reviewing the code. He changes the code as desired and commits each
comment individually, so Alice can later read the Git commit log as the peer
review log.
bob$ git commit
[feature/newprotocol 1f6fa95] Forgot return statement.
1 files changed, 1 insertions(+), 1 deletions(-)
...
When he's finished, he tells Alice he's done. Alice then, in turn pulls in the
peer review commits from Bob, using the same command Bob used to fetch the
changes initially. (Because feature/newprotocol is still her current branch,
she may omit the explicit 'newprotocols' argument.)
alice$ git flow feature pull bob
Pulled bob's changes into feature/newprotocol.
If she disagrees with Bob's comments, she may again commit changes and ask Bob
to do the same again. This leads to a continuous pull cycle until both parties
agree on the final implementation. Then, Alice (as the feature owner) finished
the feature. Bob may discard his feature branch.
Before this change, `git-flow feature start` would nag about the working
tree being dirty and disallow continuation. Then, there were two
alternatives:
- stash away your changes manually, create the new branch, restore the
stash; or
- use `git-flow feature start -f` to force creation
There is absolutely no good reason for git-flow to forbid this creation,
as git allows it already. Therefore, the -f behaviour is now the default,
without an option to turn that behaviour off. Git takes care of unsafe
situations again now.
This fix also works when feature branches are created manually, based on remote
(i.e. other developers) feature branches, to work on features together.
`git branch -d` won't remove local feature branches that are set up to track
remote branches, `-D` will.
Fixes ticket #31.
existence of a valid git repo. Instead, functions gitflow_load_settings()
and gitflow_require_git_repo() have been added that can be called in each
submodule that requires such.
Specifically, git-flow init does NOT use this.
them live using git commands instead. This avoids git commands being
issued by subcommands that do not necessarily require an existing Git repo
to be initialized (i.e. git-flow init).
https://wiki.ubuntu.com/DashAsBinSh
Went back from making use of the specific Bourne shell construct 'typeset
-i' for easy integer calculations (typeset -i foo=123; foo=foo+456;) to a
more compatible way (local foo=123; foo=$((foo+456)); )
The 'typeset -f' call has been replaced by a call to 'type', effectively
not testing for existence of a declared *function*, but testing for
existence of a declared *something*. You have to sacrifice sometimes in
order to be more portable.
- 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.
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'.