3 ms·
Ask HN: Tangible drawbacks of per-developer Git branches
I happen to be debating an issue at work and I find myself a little bit starved for opinion diversity.
The main question : why should I organize my git workflow based on a feature-branch model instead of a developer-branch model?
I've been making feature-based branches for as long as I've been using Git, so I never put too much thought into having a different model for my workflow. Moreover, all popular workflows always start from a feature-branch model. So when I got put in the hot seat to provide a tangible, deal-breaking issue against organizing a Git repo with per-developer branches where every developer would have their personal branch coming out of the main branch and they would regularly pull and pull request to the main branch, I was at a loss to come up with something impromptu. I know that this sounds very weird, intrinsically, feature-based branches make much more sense, but I still have to defend the more common approach.
What concrete issues would we encounter if we were to move to a per-developer branching system?
Since the initial incident, I feel pretty firmly that not being able to put features on-hold is a major drawback. But I would feel much more confident if I had the input of other developers.
- eindiran 8y agoIf I understand your question correctly, this seems like a case where per-feature branches are superior: Developer A is working on feature 1 and feature 2 concurrently. Developer B is working on feature 3 most of the time, but wants to make a change for feature 1 that isn't worth merging with master until feature 1 is ready. Using the per-developer branches model, that would be annoying to deal with. Using the per-feature model, its as simple as A committing to branch-1 and branch-2, and B commiting to branch-1 and branch-3. The main issue here is, if you are using Git why does it matter how each developer organizes their branches? Everyone can use whatever branching model they want on their own, then use whatever merging/rebasing strategy is agreed on into the main branch. If you absolutely must use the per-developer branching model, but want to still have per-feature branches: just use feature branches coming off your personal branch, then rebase the feature branches into your personal branch as needed before merging with the master branch.
- PunkPuffin 8y agoI feel like if we were to switch to a per-developer system we would end up with something similar to what you described in your last paragraph. But it would develop organically after the system is setup. So by the time we notice that we're back to a per-feature system it'll be too late to change back..... We ARE using Git, the main reason why I'm dealing with this issue is that someone was tasked to merge different branches and they almost merged incorrect branches because of the similarities in their names. Management was quite displeased after that incident
- cristobal23 8y agoi am new to the per-developer branching model. for those that practice this; my question is, why don’t developers just fork the repo?