010252a8a9
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.
85 lines
2.5 KiB
Markdown
85 lines
2.5 KiB
Markdown
git-flow
|
|
========
|
|
A collection of Git extensions to provide high-level repository operations
|
|
for Vincent Driessen's [branching model](http://nvie.com/archives/323 "original
|
|
blog post").
|
|
|
|
|
|
> **IMPORTANT NOTE:**
|
|
> In release 0.2, the order of the arguments has changed to provide a logical
|
|
> subcommand hierarchy.
|
|
|
|
|
|
Installing git-flow
|
|
-------------------
|
|
To install `git-flow` as a real `git` subcommand, run:
|
|
|
|
$ sudo make install
|
|
|
|
By default, this will look for the directory where Git is already installed,
|
|
and install the git-flow extension alongside the other Git subcommands. If git
|
|
is not on the system's `PATH`, it tries `/usr/libexec/git-core`. To explicitly
|
|
override this setting in case you have installed Git in another location, use:
|
|
|
|
$ sudo make GIT_EXEC_PATH=/your/custom/path install
|
|
|
|
You rarely need to override this manually, the default 'make install' should do
|
|
fine.
|
|
|
|
Or simply point your `PATH` environment variable to your git-flow checkout
|
|
directory.
|
|
|
|
|
|
Please help out
|
|
---------------
|
|
This project is still under development. What is available today is merely its
|
|
foundation. However, it is functional in its current form and should be usable
|
|
under normal use. (Don't try to create multiple release branches next to each
|
|
other and stuff like that, yet.)
|
|
|
|
Feedback and suggestions are very welcome and I encourage you to use the
|
|
[Issues list](http://github.com/nvie/gitflow/issues) on Github to provide that
|
|
feedback.
|
|
|
|
Feel free to fork this repo and to commit your additions.
|
|
|
|
|
|
Example uses:
|
|
-------------
|
|
|
|
* To initialize a new repo with the basic branch structure, instead of using
|
|
`git init`, use:
|
|
|
|
git flow init
|
|
|
|
* 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 on `develop`.
|
|
|
|
* 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 on `develop`.
|
|
|
|
* 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 on `master`.
|
|
|
|
* 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 on `master`.
|
|
|