f68d405cc3
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. |
||
---|---|---|
shFlags@2fb06af13d | ||
.gitmodules | ||
AUTHORS | ||
bump-version | ||
git-flow | ||
git-flow-feature | ||
git-flow-hotfix | ||
git-flow-init | ||
git-flow-release | ||
git-flow-support | ||
git-flow-version | ||
gitflow-common | ||
gitflow-shFlags | ||
LICENSE | ||
Makefile | ||
README.mdown |
git-flow
A collection of Git extensions to provide high-level repository operations for Vincent Driessen's branching model.
IMPORTANT NOTE:
In release 0.2, the order of the arguments has changed to provide a logical subcommand hierarchy.
Installing git-flow
After downloading the sources from Github, also fetch the submodules:
$ git submodule init
$ git submodule update
Then, you can install git-flow
, using:
$ sudo make install
By default, git-flow will be installed in /usr/local. To change the prefix where git-flow will be installed, simply specify it explicitly, using:
$ sudo make prefix=/opt/local install
Or simply point your PATH
environment variable to your git-flow checkout
directory.
Please help out
This project is still under development. Feedback and suggestions are very welcome and I encourage you to use the Issues list on Github to provide that feedback.
Feel free to fork this repo and to commit your additions. For a list of all contributors, please see the AUTHORS file.
License terms
git-flow is published under the liberal terms of the BSD License, see the LICENSE file. Although the BSD License does not require you to share any modifications you make to the source code, you are very much encouraged and invited to contribute back your modifications to the community, preferably in a Github fork, of course.
Typical usage:
Initialization
To initialize a new repo with the basic branch structure, use:
git flow init
This will then interactively prompt you with some questions on which branches you would like to use as development and production branches, and how you would like your prefixes be named. You may simply press Return on any of those questions to accept the (sane) default suggestions.
Creating feature/release/hotfix/support branches
-
To list/start/finish feature branches, use:
git flow feature git flow feature start <name> [<base>] git flow feature finish <name>
For feature branches, the
<base>
arg must be a commit ondevelop
. -
To list/start/finish release branches, use:
git flow release git flow release start <release> [<base>] git flow release finish <release>
For release branches, the
<base>
arg must be a commit ondevelop
. -
To list/start/finish hotfix branches, use:
git flow hotfix git flow hotfix start <release> [<base>] git flow hotfix finish <release>
For hotfix branches, the
<base>
arg must be a commit onmaster
. -
To list/start support branches, use:
git flow support git flow support start <release> <base>
For support branches, the
<base>
arg must be a commit onmaster
.