3 ms·

I think http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ is simpler and more robust.

scoot 13y ago
Yes, git-flow is excellent, but like any branch / commit scheme takes dicipline to follow. I often find myself (on personal projects) fiddling with bits on the 'wrong' branch, as I tend to jump ad-hoc from place to place in the code. Probably itself a discipline problem. :-)
- news_to_me 13y ago
  I have a similar problem; this is what I do: I keep a dev branch to merge to/from whenever I switch focus. For example, when I'm on branch Feat-A, but I want to make a change related to Feat-B (or I already have but haven't committed), I'll stash my changes, merge Feat-A into dev, merge dev into Feat-B, pop my changes off the stash, and commit. The whole switch goes: - "Oops, these changes don't go on this branch" - git stash - git checkout dev - git merge Feat-A - git checkout Feat-B - git merge dev - git stash pop It takes half a minute, but it keeps my branches clean, and lets me move from feature to feature at will. I may add a 'git oops' alias just for this process.
  - scoot 13y ago
    Thank you - I've been meaning to think that process through. I'll be doing this from now on if I'm in the same situation rather than 'ah feck it, commit it'!
  - easy_rider 13y ago
    yepyep, this is also how i roll; stashing and popping!
seanalltogether 13y ago
I think these hosting providers are trying to get people into the habit of doing pull requests, which is something base git and git flow doesn't cover. A lot of small teams seem to rely on blind merges with, but as you grow you need better ways to comment/approve/deny changes that random team members might throw into a codebase.
- encoderer 13y ago
  Pull requests are built into Git. (Just a piece of trivia for you).
lmm 13y ago
To my mind git-flow is overcomplicated; I prefer http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html
- thatthatis 13y ago
  I like that. It seems that git-flow is a good match for weekly/monthly releases and github-flow is a good match for daily/multiple times a day releases. As far as I can tell the only real difference is the existence of a develop branch in git-flow that allows integration testing before a batch release.
e12e 13y ago
Thanks for this -- looks very nice. Now, has anyone any experience with hg-flow (a mercurial extension that helps following a git-flow like model with mercurial)? https://bitbucket.org/yujiewu/hgflow/wiki/Home https://bitbucket.org/yujiewu/hgflow/wiki/Home
easy_rider 13y ago
feature branches are awesome. My problem is usually in early protoyping, where I want to push my stuff somewhere, but often switch paradigms. I.e. I just started learning Rails, building a new app from scratch, and you can imagine it becoming messsy. Before I get confident in a certain architecture, I would just push to master all the time with "some more blah" messages. I think rebasing can be valuable in this sense, since it will destroy crappy history. I'm more found of the git flow workflow in a team development effort, expecially if your thingy is already in a production pipeline. I've found rebasing to be often very confusing and destructive, while merges are clear and easy to manage.

scoot 13y ago

Yes, git-flow is excellent, but like any branch / commit scheme takes dicipline to follow. I often find myself (on personal projects) fiddling with bits on the 'wrong' branch, as I tend to jump ad-hoc from place to place in the code. Probably itself a discipline problem. :-)

news_to_me 13y ago
I have a similar problem; this is what I do: I keep a dev branch to merge to/from whenever I switch focus. For example, when I'm on branch Feat-A, but I want to make a change related to Feat-B (or I already have but haven't committed), I'll stash my changes, merge Feat-A into dev, merge dev into Feat-B, pop my changes off the stash, and commit. The whole switch goes: - "Oops, these changes don't go on this branch" - git stash - git checkout dev - git merge Feat-A - git checkout Feat-B - git merge dev - git stash pop It takes half a minute, but it keeps my branches clean, and lets me move from feature to feature at will. I may add a 'git oops' alias just for this process.
- scoot 13y ago
  Thank you - I've been meaning to think that process through. I'll be doing this from now on if I'm in the same situation rather than 'ah feck it, commit it'!
- easy_rider 13y ago
  yepyep, this is also how i roll; stashing and popping!

seanalltogether 13y ago

I think these hosting providers are trying to get people into the habit of doing pull requests, which is something base git and git flow doesn't cover. A lot of small teams seem to rely on blind merges with, but as you grow you need better ways to comment/approve/deny changes that random team members might throw into a codebase.

encoderer 13y ago
Pull requests are built into Git. (Just a piece of trivia for you).

lmm 13y ago

To my mind git-flow is overcomplicated; I prefer http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html

thatthatis 13y ago
I like that. It seems that git-flow is a good match for weekly/monthly releases and github-flow is a good match for daily/multiple times a day releases. As far as I can tell the only real difference is the existence of a develop branch in git-flow that allows integration testing before a batch release.

e12e 13y ago

Thanks for this -- looks very nice. Now, has anyone any experience with hg-flow (a mercurial extension that helps following a git-flow like model with mercurial)? https://bitbucket.org/yujiewu/hgflow/wiki/Home https://bitbucket.org/yujiewu/hgflow/wiki/Home

easy_rider 13y ago

feature branches are awesome. My problem is usually in early protoyping, where I want to push my stuff somewhere, but often switch paradigms. I.e. I just started learning Rails, building a new app from scratch, and you can imagine it becoming messsy. Before I get confident in a certain architecture, I would just push to master all the time with "some more blah" messages. I think rebasing can be valuable in this sense, since it will destroy crappy history. I'm more found of the git flow workflow in a team development effort, expecially if your thingy is already in a production pipeline. I've found rebasing to be often very confusing and destructive, while merges are clear and easy to manage.