meltwaterarchive / gitflow

HubFlow: A Git extension to make it easy to use GitFlow with GitHub. Based on the original gitflow extension for git.

HubFlow

Adds the 'git hf' Git extension to provide high-level repository operations for DataSift's HubFlow branching model, which is based on Vincent Driessen’s original blog post.

Installation

1. git clone [email protected]:datasift/gitflow.git
2. cd gitflow
3. sudo ./install.sh

Windows users will need something like Cygwin in order to use this extension.

Upgrading To The Latest Version

Upgrading to the latest version of the HubFlow tools is very easy:

1. sudo git hf upgrade

Getting Started

See our tutorial website to learn more about the GitFlow branching model and how to use the HubFlow tools.

Changelog

To see what's new in each release, see our Changelog.

License Terms

HubFlow 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.

gitflow's Issues

git hf feature rebase should require develop to be up to date

When you do a rebase, it should ensure that develop, is up to date with origin.

INSTALL_PREFIX is not an install prefix

Name of the INSTALL_PREFIX option of the ./install.sh script, especially it's default value /usr/local/bin is confusing. This is not an installation prefix well-known across Unix systems, but path to installation directory.

If it was a prefix, it would be used this way $INSTALL_PREFIX/bin.

I'd suggest to rename it or change it to behave as real installation prefix.

git hf push critical

I keep this error

root@yoda:/tmp/test# git hf push
/usr/local/bin/hubflow-common: line 296: =origin: command not found
/usr/local/bin/hubflow-common: line 297: =: command not found
fatal: ambiguous argument '': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
fatal: Not a valid object name
fatal: '/' does not point to a commit

There were merge conflicts. To resolve the merge conflict manually, use:

    git mergetool
    git commit

You should then push your changes back up to '', using:

    git push '' ''

After you have pushed back to '', please retry your HubFlow command

$1 value is 'origin'
$2 value is empty

_hubflow_remote_merge_helpe_r is called from git hf push

hubflow_remote_merge_helper "$ORIGIN" "$BRANCH"

Where $ORIGIN value is 'origin' and $BRANCH is empty.

Before only es called hubflow_load_settings

# loading settings that can be overridden using git config
hubflow_load_settings() {
        export DOT_GIT_DIR=$(git rev-parse --git-dir 2>/dev/null)
        export MASTER_BRANCH=$(git config --get hubflow.branch.master)
        export DEVELOP_BRANCH=$(git config --get hubflow.branch.develop)
        export ORIGIN=$(git config --get hubflow.origin || echo origin)
    export CURRENT_BRANCH=$(git_current_branch)

    export FEATURE_PREFIX=$(git config --get hubflow.prefix.feature)
    export RELEASE_PREFIX=$(git config --get hubflow.prefix.release)
    export HOTFIX_PREFIX=$(git config --get hubflow.prefix.hotfix)
    export SUPPORT_PREFIX=$(git config --get hubflow.prefix.support)
    export VERSION_PREFIX=$(git config --get hubflow.prefix.versiontag)
}

BRANCH isn't

In other machine with other version works

# loading settings that can be overridden using git config
hubflow_load_settings() {
        export DOT_GIT_DIR=$(git rev-parse --git-dir 2>/dev/null)
        export MASTER_BRANCH=$(git config --get hubflow.branch.master)
        export DEVELOP_BRANCH=$(git config --get hubflow.branch.develop)
        export ORIGIN=$(git config --get hubflow.origin || echo origin)
    export BRANCH=$(git_current_branch)
}

HubFlow hangs on 'feature start'

This has happened to me several times today and I can't figure out what's going on. We've been using HubFlow successfully on this project for a month or so, but now when I try to start a new feature it hangs on the 2nd step.

git hf feature start my-branch-name

results in:

Fetching origin
Switched to a new branch 'my-branch-name'
_

and then nothing else happens.

If I kill the process I have the local branch but it's not created in GitHub.

COMMIT_MSG file remains in the repository folder after feature submit

When submitting a feature with git feature submit when in a feature branch, there is a COMMIT_MSG which is created I guess for the message of the pull request, but after the command the file remains, and even after git hf feature finish.

Wrong filename for .shFlags file

Installed the latest code from develop branch because I wanted to use the pull request #22. However, there is a typo in git-hf:87 because that line is still looking for gitflow.shFlags, which has presumably been renamed to hubflow.shFlags.

git hf tag - create per-branch 'build' tags

A request from David Brown

• git hf tag creates a tag called '/', which can be used for building dev / overnight builds from
• is an incrementing integer that is unique to each branch
• when feature, hotfix or release branches are finished or deleted, the branch's build tags are also deleted
• build tags created on develop and support branches will persist
• build tags cannot be created on the master branch

Release tag applied to checked-out branch

Background steps

• On Github, merge pull request for [release-name] into master
• On local, checkout [feature-branch]
• git release finish [release-name]

What happened that I didn't like
Code from [feature-branch] was automatically merged into master (I think)

Possible cause
Was git tag somehow applied to [feature-branch] instead of master?

Better Pull Requests

Hi there, I was wondering if this the gitflow process / PR review could be improved like this:

A feature branch makes changes to X files. PR submitted.
develop branch has N new commits that affect 1 out of those X files in the PR, so a merge conflict shows in the PR.

It'd be really cool if there was an easy command that would merge only conflicting files from "develop" , so the PR still looks nice and clean.
Do yo reckon this is possible?

Thanks

Is the project dead?

Dead or Alive is it?

gh-pages support

Although gh-pages branches aren't really part of the original Gitflow model, they are a special type of branch that we end up dealing with when working with GitHub.

Hubflow needs to support the gh-pages branch:

• Support creating it on request
• Treat it as another 'master' branch
• Support a 'develop-doc' branch for pending doc changes
• Support creating 'feature-doc' branches
• Support creating corresponding 'doc' branches for features
• Support creating corresponding 'doc' branches for releases
• Support creating corresponding 'doc' branches for hotfixes

Main challenge will be to get the right balance between ease of use and how well it works in a multi-team environment.

$ORIGIN is not determined on a per-branch basis

$ORIGIN is a global variable, that is used extensively throughout the code. It is set exactly once, in hubflow_load_settings.

When working exclusively with GitHub, this is never a problem, as all branches use the same remote. But if you want to work in a peer-to-peer basis with your colleagues, this isn't safe, as each branch can legally have different remotes.

The fix is to replace $ORIGIN with $REMOTE, and have $REMOTE calculated on a per-branch basis. Some operations (which currently assume a single remote) might need fixing to work with any number of remotes (ie git hf update).

Branches deleted at origin are not deleted locally during 'git hf update'

When I do git hf update, in the summary of actions it says:

Any branches that have been deleted at origin have also been deleted from your local repository

But I'm still seeing local copies of branches that were definitely deleted on GitHub.

ENH: Copy release merge commit message to git tag message

(Maybe an option to) by default,
copy the release merge commit message to the git tag message.
so that GitHub Releases have the relevant commit message [first lines?]

To publish a tag as a GitHub Release:

• View the releases: https://github.com/datasift/gitflow/releases
• Click the release tag
• Click 'Edit Tag' (e.g. https://github.com/datasift/gitflow/releases/new?tag=0.1.0 )
• Click 'Publish Release'

default branch is develop and broken

If install gitflow on clean system with:
git clone https://github.com/datasift/gitflow
cd gitflow
sudo ./install.sh

gitflow is broken and from develop. git hf update dont work.

git hf update leaves you on the 'develop' branch always

Here's something that got broken in v1.5.1 ... the 'git hf update' command is supposed to end up on the same branch that it started from. Unfortunately, it currently always ends up on 'develop', and you have to checkout your original feature branch by hand afterwards.

Future of this project - tell me what you think!

Hi everyone,

First of all - I didn't realise that so many people use this project. I currently don't have any way of finding that out until issues are posted! It feels like I need to fix that. How would be best? A mailing list? IRC? Something else? Please let me know you'd like to see this done.

Some of you may not be aware that I left DataSift several years ago, and now run my own little company. I haven't been updating the project because v1.5.2 has been stable for me for the work that I do. I'm just about to release v1.5.3, with a much-needed bugfix for empty pathspec errors.

But where do we, as the gitflow/hubflow community, want to see the project go from here? Please let me know in the comments on this issue.

• The number 1 thing for me is to move this out to its own GitHub organisation, so that we can grow the maintainers community beyond just little old me :)

And are there any firms out there that would be interested in sponsoring new features and/or maintenance of this project? Now that I work for myself, this would help me spend more time on the project.

Let me know what you think!

Best regards,
Stu

`git hf feature submit` errors out if not using Github

We're using Hubflow with Bitbucket being our DVCS. When trying to run the following command

git hf feature submit

we are returned

The remote repo for this branch, 'origin' is not a GitHub repository.

I believe this is due to the following lines.
https://github.com/mborsuk/hubflow/blob/develop/hubflow-common#L199-L206
https://github.com/mborsuk/hubflow/blob/develop/hubflow-common#L535-L541

Our process right now is to manually create feature pull request and submit them...

How to install hubflow in Windows?

How to install hubflow in Windows?

Clone latest hubflow

git clone https://github.com/datasift/gitflow hubflow
cd hubflow

Copy all git-hf prefixed files to bin directory in git installation directory

cp git-hf* <git-install-dir>/bin/
cp hubflow-common <git-install-dir>/bin/

Initialize and Update latest shflags submodule

git submodule update --remote --init --checkout
cp shFlags/src/shflags <git-install-dir>/bin/hubflow-shFlags

Test hubflow

git hf help

NOTE:

• Neither Hubflow or Gitflow workflow support fork and PR workflow for Open Source projects. You'll have to manually do that. Just follow the nvie's gitflow workflow as a bird's eye view for reference.

git 2.0 compatibility

Git's default push behaviour is changing in Git v2.0, and the latest versions of Git have started issuing warnings about this change. (Specifically, the push behaviour is changing from 'current' to 'simple').

Unfortunately, the 'simple' model doesn't like the way that Hubflow sets up tracking branches, and a naked 'git push' from the command-line refuses to do the right thing. 'git hf update' does work just fine, but I'm not happy that 'git push' does not.

Possible fixes to investigate include:

• Setting branch.<name>.remote if we don't do this already
• Setting the repo's push.default to be 'upstream'
• ??

Auth failure when using Github 2-factor Authentication

If you do a git hf init and the Github account you are using is utilizing 2-Factor Authentication it fails with:

remote: Repository not found.
fatal: Authentication failed for 'https://github.com/Worthpoint/cookbooks.git/'

ENH: --verbose adds `set -x` / `set -x -v`

-v|--verbose to set -x or set -x -v would be super helpful for understanding what's going on
because it's too magic.

Cancel branch - make sure force flag is specified

Need to make sure that every cancel method checks for the -f flag. This happens in feature cancel, not sure about hotfix or release.

Negalist of commitids, to make rewind safe

Working in a small team of developers using git hf, I concluded that we needed to rewind (git push -f origin) the master branch to fix a mistake.

Later I discovered that hubflow will merge the old (unwanted) commit with no warning and very little indication of what happened, if not every developer gets the "rewind your local checkout!" email in time. This resulted in the need to git revert, which then caused subsequent merges to have rather more conflicts than necessary. Sure, I would not have taken that route if I had known, but sometimes a rewind looks like the best of a set of bad choices.

Therefore I propose a feature,

1. if, after git fetch -p, there is a remote branch called negalist, the local negalist branch should created or fast-forwarded along it. Otherwise, or if the local exists when the remote doesn't - bail out.
2. the local negalist branch is consulted for the file badcommit. If branch or file are absent, it is empty.
3. any commitid listed should be rejected. If any tags or local or remote branches contain any of them, bail out.
4. the negalist branch is probably maintained manually and linearly, and probably doesn't share any history with master.
5. to remove the negalist branch (for why? not sure), remove origin/negalist and clean up each working copy when it bails out.

Bailing out consists of telling the branch or tag names, the offending commitid, and advising the caller to "consult your email inbox or local Git guru before proceeding".

I think the algorithm above will work. The basic plan is to put the brakes on everything until the offending commits are properly forgotten.

Thanks, m

Can't run install.sh on Cygwin

Cygwin has no 'sudo' command, yet when I execute ./install.sh, I get:

*** error: must run as root (use sudo!)

...even when I run Cygwin as administrator.

I see that on the original Gitflow project, they appear to have a separate installation process for Windows: https://github.com/nvie/gitflow/wiki/Windows

Is there such a thing for your fork?

removed ‘/usr/bin/gitflow-shFlags’ gitflow already exists

If I have gitflow-shFlags installed in my system, hubflow installer silently overwrites it:

$ sudo INSTALL_PREFIX=/usr/bin ./install.sh
### gitflow / hubflow no-make installer ###
Installing hubflow to /usr/bin
Using existing repo: .
Submodules look up to date
‘./git-hf’ -> ‘/usr/bin/git-hf’
‘./git-hf-init’ -> ‘/usr/bin/git-hf-init’
‘./git-hf-feature’ -> ‘/usr/bin/git-hf-feature’
‘./git-hf-hotfix’ -> ‘/usr/bin/git-hf-hotfix’
‘./git-hf-push’ -> ‘/usr/bin/git-hf-push’
‘./git-hf-pull’ -> ‘/usr/bin/git-hf-pull’
‘./git-hf-release’ -> ‘/usr/bin/git-hf-release’
‘./git-hf-support’ -> ‘/usr/bin/git-hf-support’
‘./git-hf-update’ -> ‘/usr/bin/git-hf-update’
‘./git-hf-upgrade’ -> ‘/usr/bin/git-hf-upgrade’
‘./git-hf-version’ -> ‘/usr/bin/git-hf-version’
‘./hubflow-common’ -> ‘/usr/bin/hubflow-common’
removed ‘/usr/bin/gitflow-shFlags’
‘./gitflow-shFlags’ -> ‘/usr/bin/gitflow-shFlags’

I don't think it's safe, is it?
What if gitflow-shFlags required by gitflow is different that the one installed by hubflow?

At least, there should be warning and user prompt for decision.

Here are versions of gitflow and hubflow I have installed:

$ git flow version
init: must be superuser.
0.4.2-pre
mloskot ~ $ git hf version
1.5.0 - upgrade available

Brew formula

It would be nice if there was a Hombebrew formula for hub flow.

Releases cannot be installed

I downloaded a release recently due to a bug in the current version from the git repo. These cannot be installed.

$ sudo sh install.sh
Installing hubflow to /usr/local/bin
Updating submodules
fatal: Not a git repository (or any of the parent directories): .git
fatal: Not a git repository (or any of the parent directories): .git
install: ./git-hf -> /usr/local/bin/git-hf
install: ./git-hf-init -> /usr/local/bin/git-hf-init
install: ./git-hf-feature -> /usr/local/bin/git-hf-feature
install: ./git-hf-hotfix -> /usr/local/bin/git-hf-hotfix
install: ./git-hf-push -> /usr/local/bin/git-hf-push
install: ./git-hf-pull -> /usr/local/bin/git-hf-pull
install: ./git-hf-release -> /usr/local/bin/git-hf-release
install: ./git-hf-support -> /usr/local/bin/git-hf-support
install: ./git-hf-update -> /usr/local/bin/git-hf-update
install: ./git-hf-upgrade -> /usr/local/bin/git-hf-upgrade
install: ./git-hf-version -> /usr/local/bin/git-hf-version
install: ./hubflow-common -> /usr/local/bin/hubflow-common
install: ./hubflow-shFlags: No such file or directory

This then leaves with a broken version of hubflow installed.

hf update does not pull other features down from github.

This is a problem that has been reported by a few people in comments at http://datasift.github.com/gitflow/index.html

The problem is that someone reviewing a feature for you cannot use hf feature checkout to retrieve a feature. Currently the only way is to fall back to the standard git methods and deal with the merging yourself.

Stuart mentioned he'd fix this in the next release here: http://datasift.github.com/gitflow/GitFlowForGitHub.html#6_collaborate_with_others

Is this still the case and when will this next version be?

Thanks.

unable to init the hub flow for a new project ( cloned from github )

$ git hf init -af

Which branch should be used for tracking production releases?

• master
  Branch name for production releases: [master]
  Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? [] v
fatal: No path specified. See 'man git-pull' for valid url syntax
Push to '' failed

GitHub auth failure not handled

Affected commands (so far that I have seen):
git hf init
git hf feature start

To reproduce:

1. Fork/Clone github repo with write access. cd into repo dir.
2. Failure in any of the following commands, such as failed authentication,
   (i) git hf init
   (ii) git hf feature start feature_name
3. Retry command, such as with correct authentication.

Logged output:
tcsh# git hf feature start feature_name
Fetching origin
Switched to a new branch 'feature/feature_name'
Username for 'https://github.com': user
Password for 'https://[email protected]':
fatal: Authentication failed
Push to 'origin' failed
Exit 1

tcsh# git hf feature start feature_name
Fetching origin
fatal: A branch named 'feature/feature_name' already exists.
Could not create feature branch 'feature/feature_name''
Exit 1

Desired fix:
Handle error to at least undo and remove previous work.

Better yet, if there is an authentication problem, go into an offline mode. This might be useful for contributing to OSS projects on GitHubs by removing the Fork step in the Fork/Clone/Pull Request model.

`hf update` pushes to master and develop

This was extremely surprising behavior for us: https://github.com/datasift/gitflow/blob/master/hubflow-common#L369-L387

The help string for hf update only mentions pulling changes from remote to local, so we did not expect a developer's local master to get pushed to origin. Although it was a mistake that originally led the developer to having changes in their master branch, it still should not have made it back to origin as a result of hf update - in our opinion, changes to master (as well as to develop) should always be an explicit action, not a side effect of something else.

brew package

Brew on a mac takes over /usr/local -- can we get a brew package for gitflow?

hubflow doesn't prompt on `git hf init` like gitflow does.

I've just installed hubflow and, contrary to git flow which correctly stop to prompt for options on git flow init, it goes straight assuming the defaults never prompting for input.

My main issue is not being able to set release tag prefix.

I'm running Ubuntu 13.04 and git flow does not present this problem.

ENH: set versiontag=v by default?

I always set hubflow.prefix.versiontag v by default so that release versions are all tagged like v0.1.0.

I'll append the script I wrote in a subsequent commit.

Is there a better way to do this? e.g. to specify a global versiontag default for git-hf init

Why do I think that I don't want to set a global default in my ~/.gitconfig even if that would actually work?

Can we not use vim?

Great work with HF... only now beginning to discover it.

Is there any chance HF can skip the vim part on git hf release finish? I’ve no idea how to use vim — something I just never got into.

OS X support

We were previously using gitflow, but with some modifications and plan on making more. With our workflow including github, we'll be switching over to using hubflow shortly. Our shop uses OS X for development machines pretty exclusively, so I'm going through and fixes issues I run across, so there will be a myriad of pull requests coming in focusing on cross-platform support.

Incomplete detection of github URLs

The detection for github URLs is missing the following cases:

git+ssh://[email protected]/user/repo.git
https://user:[email protected]/user/repo.git

The latter is needed for integration with Xcode CI as Xcode ships off your current git URL to the server, which won't have your SSH keys, etc. So it would be nice if the detection understood URLs a little better (a more expansive grep regex would do it).

Is there a matching set of shell completions?

Do the standard git-flow-completions work, or do you have a fork of those also?

why not update code before finish action?

I begin a release usinggit hf release start 2.4
and someone else in my team merged his change to release/2.4 using github pull request.
I finish this release on local without executing a git hf update

Finally, my teammates' change is lost!

It is harmful!

Unexpected end of command stream during 'feature start'

I'm getting the following error when I do a feature start:

fatal: Couldn't find remote ref develop
Unexpected end of command stream

Before then all i'm doing is cloning a repo and initializing hubflow via init. Am I doing something wrong?

Git pathspec issue

When running git hf update I get a warning about git no longer supporting relative pathspecs. I keep up to date with the latest version of git via homebrew so I assume when git decides to remove the ability hubflow will stop working.

warning: empty strings as pathspecs will be made invalid in upcoming releases. please use . instead if you meant to match all paths
error: pathspec '' did not match any file(s) known to git.
Unable to checkout branch ''

I haven't taken the time to look to see if this is a simple fix or not, but wanted to report it as a bug at least.

Issues installing hubflow on Mac OS X

Hey I am having some issue with installing. I've tried uninstalling and then reinstalling and no luck. I even tried just "Clone into Mac" and it would have a clone error
So I tried using the instructions on DataSift and received this

$ git clone https://github.com/datasift/gitflow
Cloning into 'gitflow'...
remote: Counting objects: 2082, done.
remote: Compressing objects: 100% (1219/1219), done.
remote: Total 2082 (delta 1089), reused 1812 (delta 838)
Receiving objects: 100% (2082/2082), 3.28 MiB | 2.54 MiB/s, done.
Resolving deltas: 100% (1089/1089), done.
cchiu$ cd gitflow
:gitflow cchiu$ sudo ./install.sh
Installing hubflow to /usr/local/bin
Updating submodules
fatal: unable to connect to github.com:
github.com[0: 204.232.175.90]: errno=Operation timed out

Clone of 'git://github.com/nvie/shFlags.git' into submodule path 'shFlags' failed
install: ./git-hf -> /usr/local/bin/git-hf
install: ./git-hf-init -> /usr/local/bin/git-hf-init
install: ./git-hf-feature -> /usr/local/bin/git-hf-feature
install: ./git-hf-hotfix -> /usr/local/bin/git-hf-hotfix
install: ./git-hf-push -> /usr/local/bin/git-hf-push
install: ./git-hf-pull -> /usr/local/bin/git-hf-pull
install: ./git-hf-release -> /usr/local/bin/git-hf-release
install: ./git-hf-support -> /usr/local/bin/git-hf-support
install: ./git-hf-update -> /usr/local/bin/git-hf-update
install: ./git-hf-upgrade -> /usr/local/bin/git-hf-upgrade
install: ./git-hf-version -> /usr/local/bin/git-hf-version
install: ./hubflow-common -> /usr/local/bin/hubflow-common
install: ./hubflow-shFlags: No such file or directory

feature finish after github review/merge

Currently to use hf feature finish after the branch has been merged via github's review & merge pull request system it requires you to checkout develop, pull and then recheckout your feature branch.

It would be much nicer if it could check that the only change if that merge and so update develop itself, or at least give the option to run a develop branch pull if that is the only problem during finish.

Finishing a feature always ends up in having to use force-mode

Always when we try to finish a feature we end up in these two lines:
https://github.com/proteste/hubflow/blob/master/git-hf-feature#L366-L367

The only option is to force, which closes the PR, merges the stuff locally but does not seem to set the "merge state" of the PR to done...

Steps to reproduce:

1. Create feature: "git hf feature start foo-feature"
2. Commit something "git commit -am 'bar'"
3. Create PR
4. Let someone "git hf feature checkout foo-feature"
5. Let that person "git hf feature finish foo-feature"
6. Fail

Misleading error when ssh config permissions are incorrect

When trying to finish a feature branch, I received the following error:

± git hf feature finish branch-name                                                 
fatal: remote repository  is unavailable; are you offline?
mike ~/test

I checked my remote and it was fine, so I tried to run a command without hubflow:

± git fetch                                                                                
Bad owner or permissions on /home/michael/.ssh/config
fatal: The remote end hung up unexpectedly

I fixed my permissions:

± chmod 0600 ~/.ssh/config                                                                

Then it all started working again.

± git hf feature finish branch-name 
Fetching origin

It'd be nice if Hubflow pointed us in the correct direction, rather than pointing us at our connection when it's working fine

Can't uninstall original Gitflow

As a long time Gitflow user I"m not looking to move over to your actively developed Hubflow model.

However I'm struggling to uninstall the original Gitflow in order to install your Hubflow version.

The error I get is:

sudo brew uninstall gitflow
Error: No such keg: /usr/local/Cellar/gitflow

Worth noting that if I simply try and install Hubflow I get the following:

git clone https://github.com/datasift/gitflow
fatal: destination path 'gitflow' already exists and is not an empty directory.

So I think I do need to remove the old gitflow before I can install the Hubflow version. Any advice much appreciated.

Doesn't detect `develop` branch rename

The basic problem is that poor choices of the develop branch name are hard to fix.

• History: We started out calling the branch to which features are merged dev instead of develop.
• The immediate problem: git hf init fails to recognise dev as the develop branch. Instead it chooses master and then breaks because develop and release are the same (fair enough), and leaves a partial configuration.
• In trying to make this easier: if we rename the branch on GitHub (git push origin dev:develop, change the default branch, git push origin :dev) then git hf update doesn't detect this and will no longer see development updates in that clone.

We could insist everyone re-clones, and leave the old clones broken. Hopefully this would eventually become obvious in each case.

Or we could cook up a set of commands to rectify the problem.

The tricky bit is making sure we catch all clones for all developers across all the projects where we chose the unfortunate name. I think we would first have to fix hubflow so it detects that remotes/origin/dev has gone away, and then prompt for remedial action of some sort.

Any suggestions please?

Is Hubflow being maintained?

It seems maintenance stopped in November 2014, with no progress being made toward the 1.6.0 release since then. Is @stuartherbert still working on hubflow? is anyone else at @datasift?

git hf init does not push 'develop' branch back to GitHub

Needs fixing for 1.5.0 release