Giter Club home page Giter Club logo

gitflow's Introduction

git-flow (AVH Edition)

A collection of Git extensions to provide high-level repository operations for Vincent Driessen's branching model. This fork adds functionality not added to the original branch.

Getting started

For the best introduction to get started with git flow, please read Jeff Kreeftmeijer's blog post:

http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

Or have a look at one of these screen casts:

A quick cheatsheet was made by Daniel Kummer:

http://danielkummer.github.io/git-flow-cheatsheet/

Installing git-flow

See the Wiki for up-to-date Installation Instructions.

Integration with your shell

For those who use the Bash or ZSH shell, you can use my fork of git-flow-completion which includes several additions for git-flow (AVH Edition), or you can use the original git-flow-completion project by bobthecow. Both offer tab-completion for git-flow subcommands and branch names with my fork including tab-completion for the commands not found in the original git-flow.

FAQ

  • See the FAQ section of the project Wiki.
  • Version Numbering Scheme.
    Starting with version 1.0, the project uses the following scheme: <MAJOR>.<MINOR>.<REVISION>\
  • AVH is the acronym of "A VirtualHome"

Please help out

This project is under constant 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 repository and to commit your additions. For a list of all contributors, please see the AUTHORS file.

Any questions, tips, or general discussion can be posted to the Google group: http://groups.google.com/group/gitflow-users This is the original group set up to support the nvie branch, but I am monitoring the list as well for any questions related to my version. When you do post a question on the list please indicate which version you are, using the complete version number.

Contributing

Fork the repository. Then, run:

git clone -b master [email protected]:<username>/gitflow-avh.git
cd gitflow-avh

The -b master switch has to be added since the fork operation automatically clones the develop branch of the official gitflow repository and cloning it results in a local repository with just a develop branch.

If you do not have gitflow installed yet install it by running make && make install.

After that initialize the local gitflow repository with gitflow itself:

git flow init -d
git flow feature start <your feature>

Then, do work and commit your changes.

git flow feature publish <your feature>

When done, open a pull request to your feature branch.

License terms

git-flow is published under the FreeBSD License, see the LICENSE file. Although the FreeBSD 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.

git flow usage

Initialization

To initialize a new repo with the basic branch structure, use:

git flow init [-d]

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.

The -d flag will accept all defaults.

Screencast git flow init

Creating feature/release/hotfix/support branches

  • To list/start/finish/delete feature branches, use:
git flow feature
git flow feature start <name> [<base>]
git flow feature finish <name>
git flow feature delete <name>

For feature branches, the <base> arg must be a branch, when omitted it defaults to the develop branch.

  • To push/pull a feature branch to the remote repository, use:
git flow feature publish <name>
git flow feature track <name>
  • To list/start/finish/delete release branches, use:
git flow release
git flow release start <release> [<base>]
git flow release finish <release>
git flow release delete <release>

For release branches, the <base> arg must be a branch, when omitted it defaults to the develop branch.

  • To list/start/finish/delete hotfix branches, use:
git flow hotfix
git flow hotfix start <release> [<base>]
git flow hotfix finish <release>
git flow hotfix delete <release>

For hotfix branches, the <base> arg must be a branch, when omitted it defaults to the production branch.

  • To list/start support branches, use:
git flow support
git flow support start <release> <base>

For support branches, the <base> arg must be a branch, when omitted it defaults to the production branch.

Share features with others

You can easily publish a feature you are working on. The reason can be to allow other programmers to work on it or to access it from another machine. The publish/track feature of gitflow simplify the creation of a remote branch and its tracking.

When you want to publish a feature just use:

git flow feature publish <name>

or, if you already are into the feature/<name> branch, just issue:

git flow feature publish

Now if you execute git branch -avv you will see that your branch feature/<name> tracks [origin/feature/<name>]. To track the same remote branch in another clone of the same repository use:

git flow feature track <name>

This will create a local feature feature/<name> that tracks the same remote branch as the original one, that is origin/feature/<name>.

When one developer (depending on your work flow) finishes working on the feature he or she can issue git flow feature finish <name> and this will automatically delete the remote branch. All other developers shall then run:

    git flow feature delete <name>

to get rid of the local feature that tracks a remote branch that no more exist.

Share hotfixes with others

You can publish an hotfix you are working on. The reason can be to allow other programmers to work on it or validate it or to access it from another machine.

When you want to publish an hotfix just use (as you did for features):

git flow hotfix publish <name>

or, if you already are into the hotfix/<name> branch, just issue:

git flow hotfix publish

Other developers can now update their repositories and checkout the hotfix:

git pull
git checkout hotfix/<name>

and eventually finish it:

git flow hotfix finish

Using Hooks and Filters

For a wide variety of commands hooks or filters can be called before and after the command.
The files should be placed in .git/hooks
In the directory hooks you can find examples of all the hooks available.

Showing your appreciation

Of course, the best way to show your appreciation for the git-flow tool itself remains contributing to the community. If you'd like to show your appreciation in another way, however, consider donating through PayPal:

PayPal

gitflow's People

Contributors

adamgibbins avatar adutra avatar agross avatar aleno avatar algernon avatar asheiduk avatar baby-gnu avatar bstpierre avatar chad3814 avatar craigfowler avatar dolmen avatar ecararus avatar ejholmes avatar emreberge avatar floga avatar gene-pavlovsky avatar hollow avatar jptoto avatar kevinawoo avatar kiall avatar luiscoms avatar nvie avatar oppodelldog avatar petervanderdoes avatar pokey avatar putermancer avatar shoozza avatar shpoont avatar silasfn avatar zoramite avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

gitflow's Issues

[: -eq: unary operator expected

Every time I've tried to use the -avh branch on my OS/X machines I get the following problems when finnishing a feature branch or release:

flags:ERROR short flag required for (keeplocal) on this platform
/Users/amrk/Dropbox/gitflow-avh/gitflow-common: line 65: [: -eq: unary operator expected
Switched to branch 'develop'
Updating ea53ee8..66beeaec
Fast-forward
 smx3.partyresource/src/main/java/smx3/partyresource/service/PartyServiceImpl.java | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)
/Users/amrk/Dropbox/gitflow-avh/gitflow-common: line 66: [: -ne: unary operator expected
/Users/amrk/Dropbox/gitflow-avh/gitflow-common: line 66: [: -ne: unary operator expected

This appears to merge the branches, but then fails to delete the branch, and can quickly leave your repository in a rather messy state if not noticed.

Speed issues on Windows

I've not tested this on Linux, but on Windows, git flow commands are painfully slow. Starting a release or hotfix branch takes anywhere from 40 seconds to a minute, yet normal git operations seem to be relatively snappy (so I don't believe it's related to the slowness some report with git on windows).
The slowness is the same whether I'm running under git bash, cmd, or powershell. The same slowness occurs with the original nvie fork as well.

Is this behavior limited to Windows? Does it have something to do with msys/bash?

Improve output of the option -h,--help

When you do something like git flow release start -h the output is generated by shFlags and it doesn't look nice.

$ git flow release start -h
USAGE: git flow release start [flags] args
flags:
  -h,--[no]help:  show this help (default: false)
  -F,--[no]fetch:  fetch from origin before performing local operation (default: false)

I prefer to make it look and feel the same as the official git commands when you do -h

For git flow release start -h the output should look like:

$ git flow release start -h
usage: git flow release start [options] <version>

Available options are
    -F, --fetch           fetch from origin before performing finish

Unlike the official git commands, which show a man page when you call them with --help, git flow will show the above format. Maybe at a later stage the --help will show a man page.

Ideas for QA branches/releases

I've been thinking about the idea behind having the ability to create a release from a branch other than develop, with the goal of releasing from a QA branch that has been tested and is isolated from new features being integrated into develop.
Here's an idea for a workflow utilizing this:

git flow qa start v1.0
(now on qa/v1.0)
git commit -am "some bug fixes"
git flow release start v1.0
git commit -am "bump version"
git flow release finish v1.0
(release merged with develop, release and qa branches deleted)

I could see lots of variations on that workflow, it's just an example for discussion.
What does everyone else do?

Ambiguous variables used in hooks/filter calls

Certain variables don't have to be passed on to the hook/filter scripts as they are already available.

The following variables are available for the scripts:

  • DOT_GIT_DIR
  • HOOKS_DIR
  • MASTER_BRANCH
    -DEVELOP_BRANCH
  • ORIGIN

We'll update the scripts by stating these variable are available and what they mean.

Get the correct working directory.

Pull request #42 caused a problem. The command readlink is not the same across the different operating systems.

Version 1.4.0-dev.22 should address this problem, but it needs to be tested on the different operating systems.

The list below shows whether or not git-flow works on the given operating systems.

Linux  - Passed
FreeBSD - Needs testing
OpenBSD - Needs testing
NetBSD - Needs testing
Mac OSX - Needs testing

If you run git-flow on one of the above Operating Systems, that still needs to be tested, please help out and test the development version.
After installing the development version, run git flow version and post here if it worked.

If you run an operating system that's no in this list and the test fails please do the following:
Run uname -s, and if the output isn't in the list, please post that output and your operating system.

Note: On OSX, I believe the output of uname -s should always be Darwin but if you run OSX and the test fails also post the output of uname -s

Have the abillity to keep/delete local/remote branches on release finish

Currently when you do a release finish the remote branch is removed by default.

We will add new options which will allow you to keep either local or remote. With the --keep option both branches will be kept.

Possible option-names: --keep-remote, --keep-local, there will be no short flags for these.

Set flags on by default

Create the ability to have default values for certain flags.

For example:

  • The fetch flag in git flow {release|hotfix|feature} finish.
    Instead have always have to enter git flow feature finish -F, the -F should be done by default, if you don't want to do the -F you can always use --nofetch.

"release start" now requires a branch?

I just noticed that somewhere in the recent commits creating a release branch now requires one to specific the base branch now that its configurable, if it's absent ( which used to default to the 'develop' branch) you now get:

$ git flow release start 3.0.7
Fatal: Base 'DEVELOP_BRANCH' needs to be a branch. It does not exist and is required.

Is this now by design that we MUST specify the release base branch?

Single commit feature is fast-forwarded

Seeing as this seems to be the actively developed version of git-flow, I figured I would "port" my issue over here. 8-)

There is code in git-flow to check if a feature has only a single commit, and if so, to do a fast-forward merge. This conflicts with the description of the git flow workflow described in the original article. I think it's useful to know that a commit was part of a feature, and the --no-ff flag makes that easily visible.

Can we at least have an option to always use --no-ff for merging features? I'm not sure if this also applies to hotfixes and release branches.

Problem executing gitflow-shFlags on OSX

Latest HEAD gives errors when creating features:

$ git     flow feature start split-auth-tests
readlink: illegal option -- e
usage: readlink [-n] [file ...]
/Users/amrk/Dropbox/gitflow-avh/git-flow: line 84: ./gitflow-shFlags: No such file or directory

It looks like this behaviour was introduced by Daniel Dehennin's f61656d commit.

In place release correct implementation?

As discussed in #21
As I'm going through the code, I'm not sure I understand the following bit:

if flag inplace; then
    BRANCH="$(git_current_branch)"

The git_current_branch is not correct, the in-place release should release the develop branch, not the branch you are currently on, according to the original issue #133 and that means it would never have to merge back in the develop branch but it actually should merge in the master branch.

As I'm thinking this through I honestly believe we should get rid of the inplace flag and replace it with a sub-command

git flow release branch [\<branch_name>]

Some points about this

  • No need for a release branch.
  • By default the branch would be the develop branch, but it can't be a release/hotfix/feature branch. I don't see why you would do that anyway.
  • If it's not the develop branch, the user can select to merge the branch into the develop branch.
  • Never delete the branch.
  • Merge the branch in the master branch.
  • and maybe some other things I can't think of right now.

Environment settings for git-flow only

With git you can set environment variables to change behavior, Maybe we should implement a way to set these environment variables just for gitf-flow

An example of such a variable is:

GIT_MERGE_AUTOEDIT

From the git 1.7.10 release notes:

From this release on, the "git merge" command in an interactive
session will start an editor when it automatically resolves the
merge for the user to explain the resulting commit, just like the
"git commit" command does when it wasn't given a commit message.

If you have a script that runs "git merge" and keeps its standard
input and output attached to the user's terminal, and if you do not
want the user to explain the resulting merge commits, you can
export GIT_MERGE_AUTOEDIT environment variable set to "no", like
this:

#!/bin/sh
GIT_MERGE_AUTOEDIT=no
export GIT_MERGE_AUTOEDIT

You might want this behavior for git-flow, but not by default for git.

flags: FATAL unrecognized option () when using --help

Tested in versions dev.51 and dev.56 on Windows, when using the --help flag such as

git flow hotfix finish --help

I receive the error

flags:FATAL unrecognized option ()    

This is low priority as far as I'm concerned, it's not affecting my work.

Keep track of the base

Currently we can give a base for the following commands:

  • feature start
  • hotfix start
  • support start

The behavior that is implemented in the original software doesn't allow to merge those branches back into the original base.

I suggest we setup a way to keep track of the base of each of those branches and when we do a finish we check if the base still exists and merge with that base.

This should also be setup for release start, which doesn't allow a base.

Edit: Reference nvie/gitflow/issues/239

Help Init new repository on my mac osx

mac osx 10.8.3

jason$ git flow init
flags:ERROR short flag required for (showcommands) on this platform
flags:ERROR short flag required for (local) on this platform
flags:ERROR short flag required for (global) on this platform
flags:ERROR short flag required for (system) on this platform
flags:ERROR short flag required for (file) on this platform
/usr/local/homebrew/bin/../Cellar/git-flow-avh/1.5.2/bin/gitflow-common: line 79: [: -eq: unary operator expected
/usr/local/homebrew/bin/../Cellar/git-flow-avh/1.5.2/bin/gitflow-common: line 79: [: -eq: unary operator expected
/usr/local/homebrew/bin/../Cellar/git-flow-avh/1.5.2/bin/gitflow-common: line 79: [: -eq: unary operator expected

Which branch should be used for bringing forth production releases?

  • master
    Branch name for production releases: [master]
    /usr/local/homebrew/bin/../Cellar/git-flow-avh/1.5.2/bin/gitflow-common: line 79: [: -eq: unary operator expected
    Branch name for "next release" development: [develop]
    /usr/local/homebrew/bin/../Cellar/git-flow-avh/1.5.2/bin/gitflow-common: line 79: [: -eq: unary operator expected
    /usr/local/homebrew/bin/../Cellar/git-flow-avh/1.5.2/bin/gitflow-common: line 79: [: -eq: unary operator expected
    /usr/local/homebrew/bin/../Cellar/git-flow-avh/1.5.2/bin/gitflow-common: line 79: [: -eq: unary operator expected

How to name your supporting branch prefixes?
Feature branches? [feature/]
/usr/local/homebrew/bin/../Cellar/git-flow-avh/1.5.2/bin/gitflow-common: line 79: [: -eq: unary operator expected
Release branches? [release/]
/usr/local/homebrew/bin/../Cellar/git-flow-avh/1.5.2/bin/gitflow-common: line 79: [: -eq: unary operator expected
Hotfix branches? [hotfix/]
/usr/local/homebrew/bin/../Cellar/git-flow-avh/1.5.2/bin/gitflow-common: line 79: [: -eq: unary operator expected
Support branches? [support/]
/usr/local/homebrew/bin/../Cellar/git-flow-avh/1.5.2/bin/gitflow-common: line 79: [: -eq: unary operator expected
Version tag prefix? []
/usr/local/homebrew/bin/../Cellar/git-flow-avh/1.5.2/bin/gitflow-common: line 79: [: -eq: unary operator expected

Option for global hooks and filters directory

Currently the hooks and filters need to be located in the .git/hook directory of the repository.

We would add an option that gives you the ability to set a global directory.
You would be able to know which repository the script was called from by using a newly added exported variable which has the absolute path to the repository.

Redo the config command for the base

The config command has two subcommands for the setting and getting the base.

git flow config set-base and git flow config get-base

In hindsight I think it's better to use the following solution

git flow config base [<options>] <branch> [<base>]

Where the options would be as follow:
--get Get the base for the given branch (default behavior).
--set Set the given base for the given branch.

New command/prefix/? for "subfeature" branches?

A lot of the time in my workflow I find myself writing a particular feature with several subcomponents, and manually creating "subfeature" branches for those subcomponents, then merging them back into the main "develop" of that feature branch. It'd be nice to have support in gitflow for this sort of workflow - something like:

git flow subfeature start <name> <base>

Which, with base as "install" and name as "registry", for example, would create a new branch subfeature/install/registry.

git flow subfeature finish install/registry would then merge that branch back into feature/install.

Not entirely sure this is the best user interface, however, so open to suggestions on how to improve it

Thoughts?

Non-fatal error - '/usr/local/bin/gitflow-common: line 69: [: -eq: unary operator expected'

OSX 10.8.2 (Mountain Lion)
Xcode 4.5.2

Install method:

wget --no-check-certificate https://github.com/petervanderdoes/gitflow/raw/develop/contrib/gitflow-installer.sh
chmod u+x ./gitflow-installer.sh
./gitflow-installer.sh install master

Result:

MacBook-Pro-13:Development heckmang$ mkdir temp
MacBook-Pro-13:Development heckmang$ cd temp
MacBook-Pro-13:temp heckmang$ git init
Initialized empty Git repository in /Users/heckmang/Development/temp/.git/
MacBook-Pro-13:temp heckmang$ echo "blah blah blah" > README
MacBook-Pro-13:temp heckmang$ git add README 
MacBook-Pro-13:temp heckmang$ git commit
[master (root-commit) bd3c5a0] Initial commit.
 1 file changed, 1 insertion(+)
 create mode 100644 README
MacBook-Pro-13:temp heckmang$ git flow init
flags:ERROR short flag required for (showcommands) on this platform
flags:ERROR short flag required for (local) on this platform
flags:ERROR short flag required for (global) on this platform
flags:ERROR short flag required for (system) on this platform
flags:ERROR short flag required for (file) on this platform
/usr/local/bin/gitflow-common: line 69: [: -eq: unary operator expected
/usr/local/bin/gitflow-common: line 69: [: -eq: unary operator expected
/usr/local/bin/gitflow-common: line 69: [: -eq: unary operator expected

Which branch should be used for bringing forth production releases?
   - master
Branch name for production releases: [master] 
/usr/local/bin/gitflow-common: line 69: [: -eq: unary operator expected
Branch name for "next release" development: [develop] 
/usr/local/bin/gitflow-common: line 69: [: -eq: unary operator expected
/usr/local/bin/gitflow-common: line 69: [: -eq: unary operator expected
/usr/local/bin/gitflow-common: line 69: [: -eq: unary operator expected

How to name your supporting branch prefixes?
Feature branches? [feature/] 
/usr/local/bin/gitflow-common: line 69: [: -eq: unary operator expected
Release branches? [release/] 
/usr/local/bin/gitflow-common: line 69: [: -eq: unary operator expected
Hotfix branches? [hotfix/] 
/usr/local/bin/gitflow-common: line 69: [: -eq: unary operator expected
Support branches? [support/] 
/usr/local/bin/gitflow-common: line 69: [: -eq: unary operator expected
Version tag prefix? [] 
/usr/local/bin/gitflow-common: line 69: [: -eq: unary operator expected
MacBook-Pro-13:temp heckmang$ git branch -a
* develop
  master
MacBook-Pro-13:temp heckmang$ 

feature finish --squash fails to delete local branch

When you finish a feature with --squash, flow attempts, but fails, to delete the local feature branch:

error: The branch 'feature/some_feature' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature/some_feature'.

Summary of actions:
- The feature branch 'feature/some_feature' was merged into 'develop'
- Feature branch 'feature/some_feature' has been locally deleted; it has been remotely deleted from 'origin'
- You are now on branch 'develop'

Cannot resume a previously failed hotfix finish

Suppose that I have a hotfix branch, that I try to finish it, and it fails due to conflicts on the develop branch (i.e., after the merge into master).

After fixing the conflicts, if I try to resume the "hotfix finish" process, it dies saying :

"Fatal: The hotfix branch 'hotfix/xxx' is not ahead of branch 'master'"

...because the hotfix branch has already been merged into master.

This check seems to have been introduced by Issue #8.

While I agree that in normal situations it would not be adviseable to merge the hotfix branch if it's behind the base, it would be nice if one could at least bypass this check when resuming a previously failed "hotfix finish".

The only simple workaround is to create a dummy commit on the hotfix branch.

PS. I was using the latest stable version, i.e. 1.3.1.

Make name in feature publish optional.

Instead of always having to add the branch when doing a git flow feature publish, the name should be optional.

When a name isn't given, the current branch, if it's a feature branch, will be published.

finish release with -p option is not pushed

git flow version
1.5.0-dev.6 (AVH Edition)

using : git flow release finish -Fpkn 1.0.0
Summary of actions:

  • Latest objects have been fetched from 'origin'
  • Release branch 'release/1.0.0' has been merged into 'master'
  • Master branch 'master' has been back-merged into 'develop'
  • Release branch 'release/1.0.0' is still locally available
  • 'develop', 'master' and tags have been pushed to 'origin'
  • You are now on branch 'develop'

It seems that the release/1.0.0 is not pushed. The release/1.0.0 was nos published before this command. Is it a normal behaviour ?

Init and Remote Branches

Is there a way to make git flow init to create a remote tracking branch for develop if it does not already exist?

Shortcut to finish and delete

Looks like say this:

git flow feature finish my_feature_name

When you are inside the feature (feature/my_feature_name), is just annoying.
Would be easier if we just can finish without specify the name.

git flow finish

Finish the current related branch, like feature, hotfix, relase or support.

Same for git flow delete (if I'm in feature/my_feature_name, it will be deleted, and checkout dev).

My team would appreciate git flow if it get easier to do the commands.

Windows shFlags issues 1.4.0-dev.40

After updating to 1.4.0-dev.40 I'm seeing some issues that seem to be related to shFlags. Below are the results of some commands when attempting to init a new repository:

$ git flow init -d
expr: syntax error
flags:FATAL unrecognized option ()

$ git flow init
Unknown subcommand: ''
usage: git flow init

HI, any changlog or new feature?

hi, I notify that nvie/gitflow don't update for a long time, and found you are the most newly fork.
is these any changelog or feature list that inprove the nvie/gitflow?

I'm interest in Support multiple concurrent release/hotfix branches

In place release and release candidate

Hello,

I wonder if the in-place release should be merge with the develop branch.

My use case is the following:

git flow release start 1.3
<fix things>
git flow release finish -i -m 'Release candidate 1' 1.3-rc1
<fix things>
git flow release finish -i -m 'Release candidate 2' 1.3-rc2
<nothing to fix>
git flow release finish -m "Release 1.3.0" 1.3.0

Or maybe a subcommande candidate() to tag the rc but do not merge in the develop branch?

Regards.

Suggestion for functionality of 'support' branches

Having read some of the previous (somewhat dated) conversation about support branches it seems like they are not thoroughly developed because it's uncertain as to how they should work and what their purpose is.

Fair warning - I got pretty verbose here - maybe you just want to read the summary below?


I'd like to chip in with a proposal/suggestion as to what I think they should do and how they could be useful in a real world development project:

The use case I see for 'support' branches is to support legacy versions of the project. These legacy versions are still in-use and are still supported but the current 'develop' (and perhaps also the latest 'master' production release) are not backwards compatible with the legacy version. So, in a real-world scenario perhaps the develop branch contains current work towards version 2.1.0 of the project and the latest tagged 'master' release is 2.0.4 - BUT you wish to continue supporting version 1.6.3 of the project for whatever reasons.

If bugs are fixed in 1.6.x or (less likely I guess) features are added to it then they should not be merged into 'develop' by any kind of automated system because changes to this legacy version will not be compatible with the current 'develop' branch.

What this brings me along to is that I think the 'key' to making use of support branches is that they need two branches. For want of a better name, in the above scenario, I would call them 'support/1.6.x' and 'support-develop/1.6.x'.

The 'support/1.6.x' branch would in many ways be the equivalent for the 'master' branch for all legacy releases in the 1.6.x branch. The 'support-develop/1.6.x' branch would be the equivalent of (guess what?) the 'develop' branch for all work on the 1.6.x branch.

So - you receive some new work to complete against a legacy version of the project:

  1. Checkout the support-develop branch for the appropriate legacy version.
  2. Create an ephemeral hotfix branch.
    • Because your current branch is a support-develop branch (or perhaps you specified the support-develop branch as the base for the hotfix explicitly) - git flow knows that this hotfix is to be handled in the context of that support branch.
  3. You do whatever you need to do and then finish the hotfix.
    • When you use 'hotfix finish' git flow merges the hotfix into the appropriate support branch and also merges into the appropriate support-develop branch.
    • The primary 'master' and 'develop' branches are untouched (of course if the work done IS useful then you can always cherry-pick it).

The same procedure would also apply to ephemeral 'feature' and 'release' branches that are based on 'support-develop' branches. Of course, git flow would need to be able to analyse and discover which support branch (if any) any given hotfix/feature/release branch is based upon.


So in summary:

  • Support branches are for support legacy versions of the project
  • To make any meaningful use of them there should be two actual branches for each legacy version, serving the purpose of the 'develop' and 'master' branches for the support of that legacy version
  • The core functionality of a support branch is to modify the functionality of hotfix/feature/release branches.
    • Such an ephemeral branch that is based on a support branch never merges with 'develop' or 'master', instead merging with the counterpart support branch(es).

Over time the support branches for a legacy version will diverge from 'master' & 'develop' but then that's how it should work, if master/develop contain non-backwards compatible work.

Discuss! (and/or, if the functionality can be hammered out and nailed down, perhaps someone could implement it?)

git flow config set --global does not work?

$ git flow config set master production

Summary of actions:

  • Using repository specific configuration file.
  • Branch name for production releases set to production

$ git flow config set --global master production
flags:FATAL unrecognized option ()

1.3.0-dev.15 (AVH Edition)

Display where user is on finish

Hello,

The cmd_start() function display a useful message to the user about on which branch she is.

I think the cmd_finish() should do the same.

Regards.

git-flow-clone

Git-flow-clone does not seem to work with this version of git-flow. Could it be fixed, or the clone functionality added directly to git-flow?
Update: I was able to get it working on a mac, by copying the git-flow-clone script to the directory that contained git-flow. I installed git-flow through homebrew.

"git flow feature track" not working

On my desktop PC I did:

git flow feature start on-server
# coding and committing
git flow feature publish on-server

Then I came to my desktop and wanted to continue with my work:

git flow feature track on-server
Fatal: Branch 'feature/on-server' already exists. Pick another name.

It ends with error.
Do I misunderstand something ?
Is it a bug ?
What is the best way to share my feature branch between PCs/developers ?

gitflow-installer.sh script does not function as expected on Ubuntu 12.04

As I did not feel comforatable blindly running the installer, I pulled it to my system with the name gitinstall Below is a bit of work I did to get it to work. I ended up doing the manual install process.

user@machine:~$ ./gitinstall

git-flow no-make installer

Usage: [environment] gitflow-installer.sh [install|uninstall] [master|develop]
Environment:
PREFIX=/usr/local
REPO_HOME=http://github.com/petervanderdoes/gitflow.git
REPO_NAME=gitflow
user@machine:$ PREFIX=/usr/local
user@machine:
$ REPO_HOME=http://github.com/petervanderdoes/gitflow.git
user@machine:$ REPO_NAME=gitflow
user@machine:
$ ./gitinstall install master

git-flow no-make installer

Installing git-flow to /usr/local/bin
Using existing repo: gitflow
Already up-to-date.
Usage: [environment] gitflow-installer.sh [install|uninstall] [master|develop]
Environment:
PREFIX=/usr/local
REPO_HOME=http://github.com/petervanderdoes/gitflow.git
REPO_NAME=gitflow
user@machine:~$ ls /usr/local/bin/
autospec cap cucumber erubis fog jenkins.war ldiff nokogiri prettify_json.rb rackup rake2thor rlock rspec-puppet-init vagrant
bundle capify edit_json.rb fission htmldiff jpi minitar posix-spawn-benchmark puppet-lint rake repo rspec thor veewee

flags:ERROR short flag required for (showcommands) on this platform

Hey there, starting to use your fork and I am getting this message every time I issue a git flow command:

flags:ERROR short flag required for (showcommands) on this platform

I believe this may be related to the fact that I am on OS X. I can trace this to shFlags but I'm not sure how to resolve this. Can you give me some insight?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.