Hi, Iโm Vincent! Iโm a software engineer who loves:
- Simplifying things
- Building open source libraries
- Building products (full stack)
- Building developer tooling (including programming language design)
๐ Find me on the web:
Git extensions to provide high-level repository operations for Vincent Driessen's branching model.
Home Page: http://nvie.com/posts/a-successful-git-branching-model/
License: Other
For example:
$ git flow finish feature --rebase xxx
There is no need to install gitflow in GIT_EXEC_PATH. It would be absolutely OK to install
in e.g. /usr/local/bin by default.
Background: I have the latest git version always installed in /usr/local/git-VERSION with a symlink
as /usr/local/git. Doing the normal 'make install' would put gitflow in /usr/loca/git-VERSION/bin forcing
me to reinstall gitflow when updating git.
Take care of the situation where two release branches live next to each other. In that situation, a "finish release" action should merge back changes into the other release, not into 'develop'. Or at least warn about it. Or not support creating a new release branch if the other isn't finished yet.
It would be kind of cool if the git-flow config could optionally include the path to a script for automatically invoking a version-bumping script. That way, as soon as git flow release start v0.2.3
is typed in, the version bump happens and can be committed on the new branch immidiately, to lessen the chances of forgetting.
Of course, callbacks like this will be much easier to implement when git-flow is converted to Python, per #33, and might be better served as general event callbacks, instead of being specific to "version-bumping", so that I could tell git-flow to execute a script after git flow release start
and the same script after git flow hotfix start
.
Origin repositories should be optional, always. There should be no situation anymore in which git-flow nags about it not existing.
This could be implemented using an optional "-k / --keep" flag, like so:
git flow feature finish -k foo
Not removing the feature branch after a successful merge in develop
makes it easy to undo the merge, simply by removing the merge commit. On develop, such an undo would look like:
git reset --hard HEAD^
Corrupt install on RHEL5 (CentOS 5.4)
install -d -m 0755 git --exec-path 2>/dev/null || echo /usr/libexec/git-core
install -m 0755 git-flow git --exec-path 2>/dev/null || echo /usr/libexec/git-core
install -m 0644 git-flow-init git-flow-feature git-flow-hotfix git-flow-release git-flow-support git-flow-version gitflow-common gitflow-shFlags git --exec-path 2>/dev/null || echo /usr/libexec/git-core
install: cannot stat `gitflow-shFlags': No such file or directory
make: *** [install] Error 1
$ git flow init
...
$ git flow start feature xxx
fatal: 'origin': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
Remote branch 'origin/develop' does not exist and is required.
I keep my homedir in git (dotfiles, anyway), so everything in ~/git thinks it's unstaged, which means when I type git flow init
in ~/git/new-repo
, it fails. I tried git flow init -f
but got
flags:WARN getopt: invalid option -- 'f'
-- 'init'
flags:FATAL unable to parse provided options with getopt.`
When I start a release branch:
$git flow release start release-1.1 1fe0166
Switched to a new branch 'release/release-1.1'
Summary of actions:
- A new branch 'release/release-1.1' was created, based on '1fe0166'
- You are now on branch 'release/release-1.1'
Follow-up actions:
- Bump the version number now!
- Start committing last-minute fixes in preparing your release
- When done, run:
git flow release finish 'release-1.1'
I want to follow up and bump the version nmber. But why and how? Is it done automagically when I do finish ?
Feature branches should be merged into develop using the --no-ff option, correct? I just closed a feature, and it merged in with a fast-forward:
Jeremy-Bushs-MacBook-Pro:Vendo jeremybush$ git flow feature
checkout-process
- user-admin
Jeremy-Bushs-MacBook-Pro:Vendo jeremybush$ git flow feature finish user-admin
Switched to branch 'develop'
Updating 363bd1a..2eed2d2
Fast-forward
application/classes/controller/user.php | 51 ++++++++++++++++++++++++++++
application/classes/model/user.php | 3 +-
application/classes/view/user/manage.php | 6 +++
application/templates/layout.mustache | 3 ++
application/templates/user/manage.mustache | 23 ++++++++++++
5 files changed, 85 insertions(+), 1 deletions(-)
create mode 100644 application/classes/view/user/manage.php
create mode 100644 application/templates/user/manage.mustache
Deleted branch feature/user-admin (was 2eed2d2).
Summary of actions:
- The feature branch 'feature/user-admin' was merged into 'develop'
- Feature branch 'feature/user-admin' has been removed
You are now on branch 'develop'
You can see the tree for this here: http://github.com/zombor/Vendo/network
The adding manage my account for logged in users
commit should have been merged from the feature branch with the --no-ff flag.
I'm using 0.4-dev.
Currently when starting a new feature/etc on a 'dirty' working directory it shows a message:
fatal: Working tree contains unstaged changes. Aborting.
What if we changed that functionality do to a git stash
of the before creating the branch, create the new branch for the feature/etc, then git stash apply
after switching to the new branch?
This forum post proposes the use of "-s resolve" for merge/rebase to work around the bug.
$ git flow track feature xxx
Branch 'origin/feature/xxx' does not exist and is required. <โ First run gives an error
$ git status
nothing to commit (working directory clean)
$ git branch -a
develop
Summary of actions:
Shell scripts are a little bit hostile towards Windows developers. Any plans?
I just installed git-flow by hand and
git flow init -f
returns
flags:WARN getopt: option invalide -- 'f'
-- 'init'
flags:FATAL unable to parse provided options with getopt
I don't know if it is an shFlag issue or git-flow one. I launched the shFlag/bin/gen_test_results.sh and it failed only on:
'public' test suite:
testEnhancedHelpOutput
I just tried installing your git-flow solution and I am getting the following error.
git flow feature
/usr/local/git/libexec/git-core/git-flow: line 57: /usr/local/git/libexec/git-core/shFlags/src/shFlags: No such file or directory
I am guessing this might be related to the submodule you recently added?
Let me know if you have any ideas on how to fix this problem.
Thanks!
trying the following command results in an error:
git flow init
flags: FATAL unable to determine getopt version
There is no command called getopt in the latest cygwin, there is an internal command getopts though.
I get this:
git flow feature finish -F fix_payment_method_creation
No branch matches prefix '-F'
Tried putting the -F option in all positions but no luck. I am hoping this will delete the remote branch. Am I doing something wrong?
Pretty self-explanatory ;-). Because of that it's unusable after install.
I would like to use ~/.gitconfig to setup defaults for gitflow. It seems to partly work for branch prefixes but ignored for develop and master branches.
I have next .gitconfig setup:
[gitflow "branch"] master = master develop = work [gitflow "prefix"] feature = feature/ release = release/ hotfix = hotfix/ support = support/ versiontag = v
Here is git flow init output:
git flow init Initialized empty Git repository in /Users/mk/test/git/gitflow3/base/.git/ No branches exist yet. Base branches must be created now. Branch name for production releases: [master] \c Branch name for "next release" development: [develop] \c How to name your supporting branch prefixes?
I think it should suggest options from .gitconfig.
Also it shows only question line for prefixes, but don't give chance to change or see them.
The branch master exists. Even git flow init
says it. But it says it doesn't exist anyway.
rees@tardis ~/pyd $ git flow init Which branch should be used for bringing forth production releases? - PY_3X - gh-pages - master Branch name for production releases: [] master Local branch 'master' does not exist.
This is on Gentoo with git version 1.7.1 and git flow version 0.4-dev.
[nvie@cru:/home/driev00/ad] feature finish RFC124
Branches 'develop' and 'origin/develop' have diverged.
And local branch 'develop' is ahead of 'origin/develop'.
Switched to branch 'develop'
Your branch is ahead of 'origin/develop' by 3 commits.
Auto-merging CHANGES
CONFLICT (content): Merge conflict in CHANGES
Automatic merge failed; fix conflicts and then commit the result.
mkdir: 0653-357 Cannot access directory /.
/: The file access permissions do not allow the specified action.
A file or directory in the path name does not exist.
/home/nvie/gitflow/git-flow[24]: /.gitflow/MERGE_BASE: 0403-005 Cannot create the specified file.
Apparently, the variable DOT_GIT_DIR is unavailable in that environment. Happens on line http://github.com/nvie/gitflow/blob/develop/git-flow-feature#L297
Look into this further.
It would be great to have the ability to do something like git flow release delete v1.0.2
, instead of git checkout develop && git branch -D release/v1.0.2
(which I'm not even sure correctly discards a release branch) and hoping no important steps were missed.
Update readme regarding installing Cygwin package System/util-linux to make gitflow work.
Error:
$ getopt
bash: getopt: command not found
I think git flow init should set master and develop branches to track correspondent origin branches if they are avaiable. I find myself creating them by hands with --track option instead of git flow init.
For those of us on shared hosting....
Any volunteers?
Expanding git-flow is becoming increasingly tedious. The subcommand structure isn't flexible enough to support heterogenous subcommand styles and flag parsing is a pain in the ass to get right on all platforms.
Also, there is a lot of duplication in the code already because of limitations in the way sh forces you structure your code.
This calls for a total reimplementation in a higher-level language of choice. That will be Python. Since the project is still rather small, this should not be too big an issue.
I proposed dropping the "flow" command for start/finish tasks and using optional arguments and defaults instead of feature/release/hotfix/support.
Instead of
git flow start [type]
git flow finish [type]
use
git start [type]
git finish [type]
The type could be specified using options:
-f/--feature
-r/--release
-h/--hotfix
-s/--support
When calling git-start, -f is assumed. E.g.:
git flow start feature <name> => git start <name>
git flow start hotfix <name> => git start -h <name>
git-finish would look at the current branch name to guess which type of branch you're finishing. But you can pass -f/-r/-h/-s to override the default convention.
Right now the git-flow-release script only creates 'light weight' tags.
It would be nice to be able to configure creation of annotated of even signed tags.
I know that git flow is useable on Windows with Cygwin, but is there a reasonable way to use it in MSysGit? I've gotten very fond of Git Bash...
This results on ubuntu with git flow init resulting in:
mib@mib-netbook:~/test$ git flow init
/usr/lib/git-core/git-flow: 78: typeset: not found
Unknown subcommand: 'default'
usage: git flow init
Modifying git-flow to use /bin/bash instead of /bin/sh fixes this for Ubuntu, but might break more sensible OS's.
Its purpose is much like "tracking" a remote peer's feature, to work on it together and share commits, passing by the origin repo until it's finished.
git flow feature clone <remote> <name>
For example, Alice has a feature called "refactoring" and wants Bob to run a peer review on it. Then, Bob fetches Alice's branches (given he has read access in Alice's repo). He receives a remote branch now called "alice/feature/refactoring". To do this, he calls:
git flow feature clone alice refactoring
he should get a local branch called feature/refactoring
, that is based on alice/feature/refactoring
, but is not tracking that in the Git sense (because a subsequent git push
will not have commit access to Alice's repo and will therefore fail). The clone action:
git fetch alice
)Then Bob commits his peer review comments and tells Alice to fetch again. Alice does the same thing on the other side, then:
git flow feature clone bob refactoring
If we add an optional flag to this command called --track
, we can replace the git flow feature track <name>
subcommand implementation by a call to git flow feature clone --track origin <name>
.
I'm not quite happy with the name of the subcommand yet. To avoid confusion with the git clone behaviour, I think the final name should be something different. Maybe something more general like "update"? Also I think it would be nice to make no distinction between the situation where the local feature branch does not yet exist (i.e. "branch"-like) and the situation where it does already exist and you want to update (i.e. "pull") Alice's (or a third person's) changes in again.
I follow instructions in README file, use 'git flow init' instead of 'git init' and get fatal errors (RHEL5):
$ git flow init
fatal: Not a git repository
fatal: Not a git repository: ''
fatal: Not a git repository: ''
fatal: Not a git repository: ''
fatal: Not a git repository: ''
Not a git repository
$ git flow help init
fatal: Not a git repository
fatal: Not a git repository: ''
fatal: Not a git repository: ''
fatal: Not a git repository: ''
usage: git flow
Available subcommands are:
init Initialize a new git repo with support for the branching model.
feature Manage your feature branches.
release Manage your release branches.
hotfix Manage your hotfix branches.
support Manage your support branches.
version Shows version information.
Try 'git flow help' for details.
I wonnder why bugfix branches are missing in git flow. I think they are the same as features but with different prefix. Are they supposed to live in develop branch as commits without special branches?
Using Ubuntu 10.04 and code from develop branch (4de01f2)
$ git flow init -f
flags:WARN getopt: option invalide -- 'f'
-- 'init'
flags:FATAL unable to parse provided options with getopt.
It's been mentioned in the original blog post's comments section, and on this thread: the current way releases are finished merge the release branch into master and develop, but does not record a relation between them, which makes git-describe
output very inconvenient (if not to say very confusing :)).
For example: consider the case where you have a version 1.0 tagged, then finish a new 1.1 release. When using git-describe
, it scans the commit tree upwards, and finds 1.0 as the first tagged commit, generating a misleading identifier somewhat like 1.0-52-g25def71
, instead of something like 1.1-8-25def71
.
This requires a change to the original branching model, too.
I did create a local feature branch manually, based on a remote feature branch (peer/feature/RFC132), which set up tracking. Then, when finishing-by-rebasing the feature branch succeeds, git-flow
tries to remove the feature branch, but Git nags about it not having been pushed back into peer/feature/RFC132.
Output:
[nvie@cru:/home/nvie/ad] feature finish -r RFC132
Branches 'develop' and 'origin/develop' have diverged.
And local branch 'develop' is ahead of 'origin/develop'.
Will try to rebase 'RFC132'...
Current branch feature/RFC132 is up to date.
Switched to branch 'develop'
Your branch is ahead of 'origin/develop' by 16 commits.
Merge made by recursive.
CHANGES | 1 +
src/modules/j2calias.py | 13 ++++++++++---
2 files changed, 11 insertions(+), 3 deletions(-)
warning: not deleting branch 'feature/RFC132' that is not yet merged to 'refs/remotes/peer/feature/RFC132', even though it is merged to HEAD.
error: The branch 'feature/RFC132' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature/RFC132'.
When attempting to use the message flag for finishing a release I am getting an error.
Here is what I attempted to run:
git flow release finish 0.1.3 -m 'Releasing version 0.1.3'
And here is what it returns:
flags:WARN getopt: invalid option -- 'm'
-- 'release' 'finish' '0.1.3' 'Releasing version 0.1.3'
flags:FATAL unable to parse provided options with getopt.
Running the latest from the develop
branch.
Say that you start working on a feature (xyz) and need to jump off to do a hotfix or work on another feature or something. Right now I am simply committing where I am with the current feature, starting a new git flow hotfix and then doing a git checkout feature/xyz. I BELIEVE this is correct but since Ive been trying to stick to the whole "git flow" thing I think it makes sense to have a "git flow release/feature/etc continue" or "git flow release/feature checkout" or the like
Thoughts?
Hi. I'm writing a zsh completion plugin for git-flow. http://github.com/chevalun/git-flow-completion
It's usable now, but contains a annoying bug.
For now, if the feature list is empty, git-flow will return a hint like this
No feature branches exist.
You can start a new feature branch:
git flow feature start []
But it's different for a script or a program to handle an error report like this, since it is the only API.
If returning a non-zero value when feature, hotfix, release list is empty, then it is more convenient for programmers writing programs based on git-flow.
Or maybe output the hint to stderr. I'm not sure if it is a good idea.
In order to ease the maintaience work, it will be nice to add web interface in front of the command line
In web gui, it can provide
Now you have to manually do git stash
, git flow feature start foo
, git stash pop
each time. Annoying.
This happens just before the end of the operation
[...]
create mode 100644 web/js/frontend/play.js
local: 1: release/0.6.0: bad variable name
M plugins/wkToolkitPlugin
Switched to branch 'develop'
[...]
Just installed gitflow under Cygwin (using zsh). When I git flow init
the repository I first got the following error:
flags:FATAL unable to determine getopt version
I needed to install the util-linux
package which got me getopt (enhanced) 1.1.4
and was a bit difficult to find in Cygwin's package list. Perhaps this could be added to the readme.
Now with getopt in place I still cannot initialize the gitflow repository. The new error messages read as follows:
$ git flow init
flags:ERROR flag name (help) is reserved
flags:FATAL unrecognized option (,)
very often it is required to do not only some changes before the release, but also afterwards. For example (I'm sure that there are many other use cases where "after-processing" is required): developing in java with maven you have to push the version before a release. Afterwards you have to change it to the next version as a snapshot: e.g.:
1.0.0-SNAPSHOT -> 1.0.0 -> 1.1.0-SNAPSHOT
The problem with the current git-flow workflow is that you have to do these changes directly in the development branch. IMHO it will be much clearer in the history if you would do something as the following:
$ git flow release start 1.0.0
--bump version from 1.0.0-SNAPSHOT to 1.0.0
--do other changes
$ git flow release finish 1.0.0 --master
--this will merge the release/1.0.0 into the master and tag it; but do not kill the branch
--now i can change the version from 1.0.0 to 1.1.0-SNAPSHOT
$ git flow release finish 1.0.0 --develop
--finally merge the release/1.0.0 branch into the dev branch and delete the branch
IMHO this will really help :) WDYT?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.