Live data from Hacker News

My unorthodox, branchless Git workflow

drewdevault.com

1–10 of 48 posts

Re: My unorthodox, branchless Git workflow

#4

    No time spent creating new branches for new features.
    No time spent switching between branches to address feedback.
I'm sorry but these are non-issues with git. The approach you've outlined makes collaboration on features impossible. Cherry-picking and rebasing does not scale for either teams, or lots of parallel workstreams.

Re: My unorthodox, branchless Git workflow

#7

No time spent creating new branches for new features. No time spent switching between branches to address feedback. I'm sorry but these are non-issues with git. The approach you've outlined makes collaboration on features impossible. Cherry-picking and rebasing does not scale for either teams, or lots of parallel workstreams.

Yes, that's very unconvincing.

He may think that he is rebasing later anyway, but sorting all those commits into "need for my feature" vs. "don't need for my feature", followed by the rebasing within the feature certainly takes much longer than the split second of creating a branch and keeping those features separate from the beginning.

It's great if it works for him, but he's certainly not saving time.

Re: My unorthodox, branchless Git workflow

#9

A long time ago I used to use Stacked Git (1) for a similar but different workflow. 1: http://www.procode.org/stgit/ I miss the days when you were expected to use a porcelain on top of raw git.

It may not be _expected_ now, but i'll always take the opportunity to plug magit, which is by far the nicest porcelain i've ever used.

Re: My unorthodox, branchless Git workflow

#10
Local testing would become meaningless as “features” are not being tested in isolation. It’ll lead to the classic “but the tests work on my machine” because half the changed code isn’t in the published changeset.
Post reply on HN