Rethinking of `feature publish`, should it be a partial feature release?

[weynhamz]

Currenttly, git feature publish is accturaly an alias to git push which I do not think it is a correct behavior of publish. I think publish should mean that the work in feature branch has reached a state of workable but not yet been finished and is ready to be published into develop, but the original feature branch should still be keeped for further development.

Under this concept, the git flow feature publish should be a combination of the follwing comands.

git co develop
git merge --no-ff feature/feature-1
git co feature/feature-1
git merge --no-ff develop

[ermshiperete]

A better name for the current behavior of "publish" might be "share", i.e. git flow feature share pushes the current feature branch to origin so that others can join in the development of the feature.

[merwok]

I think of git flow publish as a nicer git push that doesn’t make me write the set-upstream-to option manually! However, it refuses to do what I want most of the time because I always have work in progress that’s not committed yet. In the age of pull requests and continuous integration, I would argue that we don’t need a command that means «all my commits are ready, share it with the world after days», but rather «ok, I have some commits, push to central repo or fork to see CI and feedback».