3 ms·
This workflow doesn’t seem weird or unorthodox to me, it just seems like a solo contributor workflow. There aren’t as many reasons to use branches when you aren
by dahart 7y ago
This workflow doesn’t seem weird or unorthodox to me, it just seems like a solo contributor workflow. There aren’t as many reasons to use branches when you aren’t working with other people in those branches. It seems fine to skip some of the overhead when you’re by yourself. The implicit suggestion that everyone else is always using branches does seem a bit strange, if that’s the implication. I use branches when I need them, but I don’t always use them, and usually on small teams we adopt a policy of checking self-contained single-commit features into master, and using branches for multi-person, multi-commit, and multi-day features.
No time spent creating new branches for new features.
No time spent switching between branches to address feedback.
All of my features are guaranteed to be mutually applicable to master, saving me time addressing conflicts.
Any conflicts with upstream are addressed in all of my workstreams at once, without switching between branches or allowing any branch to get stale.
To be honest all 4 of these are unconvincing. Creating branches and switching branches is a non-problem, these operations are faster than committing.
To the third and fourths points - that all “streams” resolve at the same time, that’s an okay point, but isn’t normally a problem in practice with branches. If you’re working on multiple branches than conflict with an incoming commit, it means you’ve touched the same code in multiple branches, and also someone else has too. It tends to indicate bad planning or bad communication or both. And it just doesn’t happen very often.
Here are a few reasons to use branching anyway when you’re alone:
- To do an experiment multiple ways on the same code.
- To avoid use of git stash. Branching is safer and adds no extra difficulty. Stash doesn’t have as good of a safety net (it’s in the manual).
- To write & test your feature without your other in-progress features getting in the way.