On Mon, 03 Oct 2011 19:27:16 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
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.
Yep. The push example was for the case you needed to push the branch.
Cheers, Frank