4 ms·

Does anyone here seriously work like that? Sure, why not? I create a branch for nearly every series of edits (aside from tyop-fixing bugfixes) that I do, usua

by maw 18y ago

Does anyone here seriously work like that? Sure, why not? I create a branch for nearly every series of edits (aside from tyop-fixing bugfixes) that I do, usually to fix a bigger bug or to create a new feature. If it works out, great: I merge it into the master. If it turns out to be a dead end, or is taking too long, I can delete the branch, or just put it aside with the intention of rebasing it later. ...but I don't think branching too much is particularly healthy. Again, why not? Ignoring for the moment problems which are social at their root and not a dvcs' fault, most likely either you're creating lots of dead ends in those branches, which isn't such a bad thing because it also means that you're also trying out lots of ideas and exploring the problem space; or you're merging those branches, so you're doing good work and getting it integrated into the project.

nihilocrat 18y ago
I think it's considered unhealthy because it's another layer of complexity you have to deal with, and a many-branched environment without any system-enforced meta-structure can result in huge amounts of confusion when things don't go right. You have to train your team and trust everyone to avoid all human error. Example: "whoops, I just merged a bad branch into the master one, but I just left work for the day and I don't find this out until tomorrow morning, let's hope no one checked it out in the interim or we're boned!" With a centralized VCS (or more specifically a single- or few-branched repo), you just tell people to checkout code, commit their changes, and you're done. There are less places to screw up because you don't have a bunch of branches you have to manage. You are less flexible, but this lack of flexibility only becomes a huge burden in a truly distributed (i.e. open source) environment. It's sort of like arguing static vs. dynamic typing. There are many cases where dynamic typing resulted in very painful errors because some variable along the line didn't follow the "gentleman's agreement" that it should be a list and not a string. Though dynamic typing is more flexible and powerful, sometimes you just succumb to human error because the computer trusts you.
- arockwell 18y ago
  SVN doesn't do anything to stop people from committing a bunch of boneheaded changes to the repository either. Maybe its a harder to do by accident, but in practice I don't see that as much of a problem. Also, if if someone does commit a bad branch to the repository in git it can easily be rolled back.

by maw 18y ago

nihilocrat 18y ago

I think it's considered unhealthy because it's another layer of complexity you have to deal with, and a many-branched environment without any system-enforced meta-structure can result in huge amounts of confusion when things don't go right. You have to train your team and trust everyone to avoid all human error. Example: "whoops, I just merged a bad branch into the master one, but I just left work for the day and I don't find this out until tomorrow morning, let's hope no one checked it out in the interim or we're boned!" With a centralized VCS (or more specifically a single- or few-branched repo), you just tell people to checkout code, commit their changes, and you're done. There are less places to screw up because you don't have a bunch of branches you have to manage. You are less flexible, but this lack of flexibility only becomes a huge burden in a truly distributed (i.e. open source) environment. It's sort of like arguing static vs. dynamic typing. There are many cases where dynamic typing resulted in very painful errors because some variable along the line didn't follow the "gentleman's agreement" that it should be a list and not a string. Though dynamic typing is more flexible and powerful, sometimes you just succumb to human error because the computer trusts you.

arockwell 18y ago
SVN doesn't do anything to stop people from committing a bunch of boneheaded changes to the repository either. Maybe its a harder to do by accident, but in practice I don't see that as much of a problem. Also, if if someone does commit a bad branch to the repository in git it can easily be rolled back.