6 ms·

Some people love working with branches. I don't. It's down to how you work, who you're working with, and the processes you have in place. My personal motto is

by mibbit 15y ago

Some people love working with branches. I don't. It's down to how you work, who you're working with, and the processes you have in place. My personal motto is just "don't break the build". It seems messy to me to create a ton of branches with broken stuff on them, having to remember the state of everything, what's been merged, what hasn't. I'd rather just write code to a single trunk. If I need to do big arch changes, I do them in bits that don't break the build. Time is linear. So is my trunk. I develop linearly. I don't think in branches. I can totally understand that other people see things a different way, and prefer to work like that. But I cannot. I tried. It was awful, painful and a waste of time. So enough with the "This is better than this" mentality :)

rpearl 15y ago
Well, first, one of the points of branches is "don't break the build" since you always know that master is an appropriately tested version of the code. Branches give you feature isolation. Suppose that while developing a feature, you realize that a piece of code is buggy. In your view of the world, where everything is linear, either you drop everything you're doing and fix that bug, or file a bug with the tracker, deferring it until someone has time to fix it. But morally, the second one is just a branch--time in this case isn't linear. You (or someone else) will have to change contexts at some point and fix the bug. If it's after your feature has been committed, then you have to do it on code which may have churned quite a bit since you filed the bug. So if you used branches, you would just create branch for the fix. If it gets committed into master before your feature, you could obtain upstream changes. If it gets committed after your feature, you can use rebasing to replay that work on top of the significantly changed code. If you need to do big arch changes, you still do them in bits such that every build isn't broken. You just do them in a branch, so that nobody else sees them until they are completely ready. Note also that, with git's powerful tools, you have the option (which is usually taken, these days) to rebase your branches into master, not merge them. So, when you published your changes to the world (git branches are local, nobody else can see them) you could still show the world a linear line of development if you so pleased. So it may not be a "this is better than this" mentality, but you definitely do lose a significant amount of expressiveness and flexibility for no reason. Branches are painless (in git) and certainly not a waste of time (in that they actually streamline the development process). Can you describe the situation in which you thought that was the case?
- mibbit 15y ago
  As I say, I've worked in a team where branching was tried. It was a hinderance and slowed down development. I've never seen the point of branching for my own personal use. Others may have different experiences, especially if they work on large teams. The only reason I can see to "branch" is when you deploy code, make a copy of it in the repos, so that you can fix any bugs off it quickly.
  - rpearl 15y ago
    As I say, branching is not something that a "team" does. Branches in git are not something that are published, in nearly every case. Branches are not something like "the dev branch" and "the stable branch". If you are referring to that, in your vague and nonspecifc way, then we are talking about different things. Branches are feature isolation. For every different feature you add or bug you fix, you, personally and locally, create a branch to do so. If you think that is a lot of branches, you simply don't have the appropriate mental model. If you continue to think of a branch as "making a copy of it in the repos" (what does that even mean??) then, it's... just not the appropriate way to think about it. Anyway, I'm not going to continue to have this conversation, since it's just not worth it. I just hope I don't have to work for a company that thinks that "branching is bad", but at least if I do they will never know that I am actually using features of my version control system (gasp!).
    - mibbit 15y ago
      It sounds like filling out TPS reports to me I'm afraid. Some authors probably have tons of concurrent drafts of a novel they're writing. But I'll bet most have a single draft. I'm afraid (to a fault), I am primarily a lone developer so this is the angle I come at these things from...
tytso 15y ago
Time may be linear for you. But if you have a several people working together on a project, branches make life so much better.
spacemanaki 15y ago
I think there are some features where SVN is superior to Git (dealing with large binary files?) but I think you could basically use Git in the fashion you describe, and it would be a better experience than SVN. Just being able to quickly checkout old versions without touching the network is awesome. On the other hand, as soon as you bring a bunch of people working on a project together, isn't the development inherently non-linear, and there's the possibility that you will need to deal with (implicit) branches? I guess if every person committed to the trunk frequently you wouldn't need to. > So enough with the "This is better than this" mentality I understand the sentiment, and the desire to avoid flamewars and endless bitching about tools, but no thanks. If I never have to deal with CVS telling me that every single file in my tree has a conflict in it again, I will be very pleased. If no one had a "This is better than this" mentality, we might not even have the choice of Git (or even SVN for that matter).
- to3m 15y ago
  SVN is better than git for ANY binary files, really, because with no centralized repository it's rather hard for git to implement any kind of locking. Locking is pretty much essential for binary files, since most are not mergeable in any meaningful way. It's literally NO USE AT ALL to be forced to make somebody redo their recent work when there's a conflict :) SVN's locking ain't so amazing, it must be said, because it's clearly not the way it's intended to work. But it's better than nothing, certainly, and TortoiseSVN on Windows has some nice features that make it work fairly well. Another issue is the filling of your hard drive with crap - obviously git keeps the entire repository locally, and SVN keeps a previous revision (I think?), which is a bit useless for enormous hundreds-of-gigabytes repositories mostly filled with stuff that's not significantly further compressible. To add insult to injury, git then spits in your face by not letting you retrieve only part of the repository! - well, obviously the problem is that git just isn't designed for this kind of thing, not that its decisions are unreasonable. Shame, though... some kind of binaries-and-locking support would be nice. It would be great to be able to use git for everything.
  - wladimir 15y ago
    I'm pretty sure that git does allow working with only part of the repository. You need to provide some specific options when cloning...
JoeAltmaier 15y ago
Works when its just you and friends, and you talk a lot, and are working on the same project and release schedule. Change any of that, and you need a better technique. There are lots of different ones, and switching between them is a mind-bend, so folks gripe a lot. But you'll likely have to learn one sometime, probably sooner than you'd like. Please don't be the guy that gripes and drags his heels. There are legitimate reasons to need source control. Your personal convenience is one of the decision factors, but a very minor one.

by mibbit 15y ago

rpearl 15y ago

Well, first, one of the points of branches is "don't break the build" since you always know that master is an appropriately tested version of the code. Branches give you feature isolation. Suppose that while developing a feature, you realize that a piece of code is buggy. In your view of the world, where everything is linear, either you drop everything you're doing and fix that bug, or file a bug with the tracker, deferring it until someone has time to fix it. But morally, the second one is just a branch--time in this case isn't linear. You (or someone else) will have to change contexts at some point and fix the bug. If it's after your feature has been committed, then you have to do it on code which may have churned quite a bit since you filed the bug. So if you used branches, you would just create branch for the fix. If it gets committed into master before your feature, you could obtain upstream changes. If it gets committed after your feature, you can use rebasing to replay that work on top of the significantly changed code. If you need to do big arch changes, you still do them in bits such that every build isn't broken. You just do them in a branch, so that nobody else sees them until they are completely ready. Note also that, with git's powerful tools, you have the option (which is usually taken, these days) to rebase your branches into master, not merge them. So, when you published your changes to the world (git branches are local, nobody else can see them) you could still show the world a linear line of development if you so pleased. So it may not be a "this is better than this" mentality, but you definitely do lose a significant amount of expressiveness and flexibility for no reason. Branches are painless (in git) and certainly not a waste of time (in that they actually streamline the development process). Can you describe the situation in which you thought that was the case?

mibbit 15y ago
As I say, I've worked in a team where branching was tried. It was a hinderance and slowed down development. I've never seen the point of branching for my own personal use. Others may have different experiences, especially if they work on large teams. The only reason I can see to "branch" is when you deploy code, make a copy of it in the repos, so that you can fix any bugs off it quickly.
- rpearl 15y ago
  As I say, branching is not something that a "team" does. Branches in git are not something that are published, in nearly every case. Branches are not something like "the dev branch" and "the stable branch". If you are referring to that, in your vague and nonspecifc way, then we are talking about different things. Branches are feature isolation. For every different feature you add or bug you fix, you, personally and locally, create a branch to do so. If you think that is a lot of branches, you simply don't have the appropriate mental model. If you continue to think of a branch as "making a copy of it in the repos" (what does that even mean??) then, it's... just not the appropriate way to think about it. Anyway, I'm not going to continue to have this conversation, since it's just not worth it. I just hope I don't have to work for a company that thinks that "branching is bad", but at least if I do they will never know that I am actually using features of my version control system (gasp!).
  - mibbit 15y ago
    It sounds like filling out TPS reports to me I'm afraid. Some authors probably have tons of concurrent drafts of a novel they're writing. But I'll bet most have a single draft. I'm afraid (to a fault), I am primarily a lone developer so this is the angle I come at these things from...

tytso 15y ago

Time may be linear for you. But if you have a several people working together on a project, branches make life so much better.

spacemanaki 15y ago

I think there are some features where SVN is superior to Git (dealing with large binary files?) but I think you could basically use Git in the fashion you describe, and it would be a better experience than SVN. Just being able to quickly checkout old versions without touching the network is awesome. On the other hand, as soon as you bring a bunch of people working on a project together, isn't the development inherently non-linear, and there's the possibility that you will need to deal with (implicit) branches? I guess if every person committed to the trunk frequently you wouldn't need to. > So enough with the "This is better than this" mentality I understand the sentiment, and the desire to avoid flamewars and endless bitching about tools, but no thanks. If I never have to deal with CVS telling me that every single file in my tree has a conflict in it again, I will be very pleased. If no one had a "This is better than this" mentality, we might not even have the choice of Git (or even SVN for that matter).

to3m 15y ago
SVN is better than git for ANY binary files, really, because with no centralized repository it's rather hard for git to implement any kind of locking. Locking is pretty much essential for binary files, since most are not mergeable in any meaningful way. It's literally NO USE AT ALL to be forced to make somebody redo their recent work when there's a conflict :) SVN's locking ain't so amazing, it must be said, because it's clearly not the way it's intended to work. But it's better than nothing, certainly, and TortoiseSVN on Windows has some nice features that make it work fairly well. Another issue is the filling of your hard drive with crap - obviously git keeps the entire repository locally, and SVN keeps a previous revision (I think?), which is a bit useless for enormous hundreds-of-gigabytes repositories mostly filled with stuff that's not significantly further compressible. To add insult to injury, git then spits in your face by not letting you retrieve only part of the repository! - well, obviously the problem is that git just isn't designed for this kind of thing, not that its decisions are unreasonable. Shame, though... some kind of binaries-and-locking support would be nice. It would be great to be able to use git for everything.
- wladimir 15y ago
  I'm pretty sure that git does allow working with only part of the repository. You need to provide some specific options when cloning...

JoeAltmaier 15y ago

Works when its just you and friends, and you talk a lot, and are working on the same project and release schedule. Change any of that, and you need a better technique. There are lots of different ones, and switching between them is a mind-bend, so folks gripe a lot. But you'll likely have to learn one sometime, probably sooner than you'd like. Please don't be the guy that gripes and drags his heels. There are legitimate reasons to need source control. Your personal convenience is one of the decision factors, but a very minor one.