Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Sep 25, 2012
  1. @jeromebaum
Commits on Jul 9, 2012
  1. Merge pull request #211 from pcragone/develop

    authored
    Added 'init()' function to git-flow-{feature,release,hotfix,support}
Commits on Jun 1, 2012
  1. @memleak
Commits on Apr 21, 2012
  1. @pcragone

    Added 'init()' function to git-flow-{feature,release,hotfix,support},…

    pcragone authored
    … which gets called if subargument is not help
Commits on Apr 19, 2012
  1. @mykehsd

    Feature finish squash parameter

    mykehsd authored
    Adding an optional (false by default) -S option to 'git flow feature finish' to allow squashing
    the commit
Commits on Feb 13, 2012
  1. Fix indenting.

    authored
  2. @vedang

    Added a -r flag to git-flow-feature-pull to support pull with rebase

    vedang authored committed
    Signed-off-by: Vincent Driessen <vincent@3rdcloud.com>
Commits on Nov 23, 2011
  1. Fix wording.

    authored
Commits on Oct 25, 2011
  1. @chad3814

    added a -D flag to the git flow finish command to try extra hard to d…

    chad3814 authored
    …elete the local branch after finishing the feature
Commits on May 16, 2011
  1. Update usage docs and changelog.

    authored
  2. Implement git flow feature finish without a branch name to finish the

    authored
    current branch, if any.
    
    This fixes #127.
Commits on Apr 14, 2011
  1. - Removed quoting in has $SOME_BRANCH $(get_remote_branches), as the …

    Konstantin Tjuterev authored
    …check was always false
    
    - Added fetching develop branch from origin when fetch flag is on in feature finish
Commits on Feb 3, 2011
  1. Fix: "eval set" called in the wrong context.

    authored
    This is the real fix for the incorrect fix that I reverted in the
    previous commit.  parse_cmdline was used to DRY up the source, but this
    introduced a bug because the "eval set" line changes the positional
    parameters semantics, but does it in the wrong context, so the calling
    function never receives the changes.
    
    This closes at least the GitHub issues #54 and #86.
  2. Don't just take the last argument, take the first.

    authored
    This patch was originally contributed as a workaround for the cases
    where there were flags that took the first argument position.  This fix
    was just plain wrong and this commit reverts it.
Commits on Oct 8, 2010
  1. Manually select the last argument.

    authored
    This implementation does not rely on Bash-specific functionality.
Commits on Oct 5, 2010
  1. Tidy up a bit.

    authored
  2. @gjherbiet

    Added -k option to keep (feature|hotfix|relase) branch when calling '…

    gjherbiet authored committed
    …finish'.
Commits on Aug 22, 2010
  1. @adamgibbins

    Fixed incorrect color flag

    adamgibbins authored
Commits on Aug 21, 2010
Commits on Jul 21, 2010
  1. Fix whitespace issues.

    authored
Commits on Jul 20, 2010
  1. @talios

    Finishing features now only update / and / if they exists, this allow…

    talios authored
    …s you to work on a unpushed repo, or a git svn repo
Commits on Jul 9, 2010
  1. Added new experimental `feature pull` subcommand.

    authored
    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.
  2. Forgot to update usage text.

    authored
  3. Allow new feature branches in dirty working trees.

    authored
    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.
Commits on Jul 8, 2010
  1. Force deletion of the feature branch after finish.

    authored
    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.
Commits on Jun 29, 2010
  1. @Zoramite

    Adding an extra line to the output for extra spacing.

    Zoramite authored committed
  2. @Zoramite

    Adding extra instructions when running the list option without any co…

    Zoramite authored committed
    …rresponding branches found.
Commits on May 27, 2010
  1. Added 'feature checkout' subcommand.

    authored
    This can be used as a shortcut to "git checkout feature/full-feature-name".
    Feature branch prefix names may be used for convenience.
Commits on Apr 4, 2010
  1. Fix: unnecessary requirement of origin when creating a new feature br…

    authored
    …anch.
    
    Only test if local branch is behind origin if origin exists.
Commits on Apr 1, 2010
  1. @gmallard
Something went wrong with that request. Please try again.