Le 03/10/2011 19:20, Frank Lanitz a écrit :
On Mon, 3 Oct 2011 19:16:09 +0200 Jiří Techet techet@gmail.com wrote:
- I agree with non-fast-forward merges of feature branches. These
branches however have to be real feature branches where work concentrates on implementing a single feature (e.g. GTK 3 support). For instance I have a branch for_review with random bugfixes and minor features which shouldn't be treated as a feature branch and which can even be rebased on top of master (If you have a look at GTK, you see only a small number of merges - with bugfix-like commits there's very small danger that someone else bases work on them.)
Yeah, agreed too. What I like in the blog post's workflow is that *every* single feature gets its own incubation branch, not only "big" ones. This cleans up "master" state, and makes reading the history easier.
Even in the case of single-commit features? I completely agree with more-than-one-commit features because otherwise you don't know where the feature implementation starts and ends but having it for minor one-commit features seems like overkill to me.
Its hard to say. I would say if its really, really, really only just one commit, there is no need to build up a branch. But if there is a chance of a second one ... might be useful. and git checkout -b // git push origin :<branch> is a fast thing
Agreed, not much to add. And the push isn't even necessary (or recommended for small ones?), one can create a release branch and only push post-merge.
I'm not against this idea completely, I just don't feel Geany needs it. If you branch before release it adds some overhead because many commits will go both to the release branch and to master. Anyway, new release is far away so there's plenty of time to decide what's best for Geany meanwhile.
;) I agree.
True, and agreed too, it's not necessarily important to decide yet -- and if we don't, we're most likely to not have a pre-release release branch ^^
Cheers, Colomban