11–20 of 48 posts
Seems like all the time you'd ostensibly save on not branching you instead spend doing very careful munging later and crafting very careful commits with git add -p and rebase and other equally time consuming tools. I don't see the value-add at all.
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.
I am excited about the promise of patch-based VCs. In theory they are clearly a better, more flexible model, that is a closer match to how we actually think of changes.
As an example, the branch-free model of this post just falls out naturally, w/o the need to rebase at the end.
However, we're still missing a great implementation to make this promise a practical reality (perhaps the upcoming version of Pijul will be that implementation?).
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.
https://trunkbaseddevelopment.com/
And this is also my experience, I absolutely hate spending time to merge things and resolve the conflicts and bugs.
I think this should be the default behavior for small/medium teams.
Branching should only be used when trunk-based dev is no longer possible.
I really liked this article from the Our Machinery guys, who created the Bitsquid engine.
https://ourmachinery.com/post/moving-away-from-git-flow/
This other article is also interesting: https://medium.com/@mattia.battiston/why-i-love-trunk-based-...
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.
if you're going through the trouble of carefully rebasing to change the order of commits, and remembering exactly how many commits behind HEAD you should push, and remembering what state the remote is in (what is master is actually pointing at HEAD~4?)... why not just go through the comparatively minor trouble of using branches?
also it's not like working on branches excludes the possibility of sometimes committing directly to master. that's what I do for most of my personal projects: small cleanup and fixes happen on master, larger things happen in a branch on a PR until I'm happy with it. ~30% of the time I'm actually not happy with how it turns out, and then I'd rather just close the PR and delete the branch than carefully revert work in progress.
[1]http://www.procode.org/stgit/ [2]https://en.wikipedia.org/wiki/Quilt_(software)
People are quick to dismiss this, but I think it's a fish-in-water kind of thing, where they are so used to the normal git flow, they can't see any way that it might be non-ideal. I am excited about the promise of patch-based VCs. In theory they are clearly a better, more flexible model, that is a closer match to how we actually think of changes. As an example, the branch-free model of this post just falls out natura…