Using branches heavily in your development can make you a better programmer like few other habits can.
It was really hard to keep reading after this line. It's like saying painting your bedroom red will make you better at sex. It's like saying getting a gas-powered golf cart will make you better at golf. It's like saying changing your mouse to be inverted on the Y-axis will make you better at computer games. All of these things change the experience, but they don't make you inherently better at anything. Just like branching during development.
I find it plausible that a golf cart could make somebody better at golf. Without the cart, a non-trivial amount of exertion is spent on a tangentially related task (getting from hole to hole) instead of on the primary task (getting the ball from hole to hole). Something that allows golfers to better focus on golfing could conceivably improve their game.
I really get tired of this sort of response where the one replying ignores the primary point in order to take issue with a single portion of one of several examples that bolstered it.
I am not ignoring the primary point. My point about golf-carts and better golfers maps back onto branching and better programmers.
To spell it out explicitly: I believe that modern version control systems, specifically ones that provide sophisticated branching facilities, reduce mental load on programmers and speed up tedious tasks. This could very well make people who take advantage of them better programmers (where "better" can be described in terms of efficiency). The less time I spend managing branches and doing merges/rebases the old way, the more time and effort I am able to devote to my primary task (actually programming).
I could manage patch files and tarballs with quilt, but I would be wasting my time and my productivity would drop. That would make me a "worse" programmer. If bad tools can hold me back, then better tools can improve me.
I think by "better programmer", he meant you will function better as someone who writes code in the context of a team. And using branches properly can (a) help other people grok the code you write, (b) help you maintain clarity with an influx of change requests.
Of course advice to "just use branches" is not going to make up for core deficits in your programming knowledge. But in my experience a lot of the trouble we get into on software teams is due to workflow problems and misunderstandings rather than "bad programming".
Sure a good chef will be able to cook an amazing meal with just a spoon, a frying pan and a steak knife. But, he will do better with a full kitchen. And if you want him to do it in a way actually capable of handling a restaurant - the full kitchen is needed. He may not be a better cook with the tools, but he certainly will be a better chef. Because you know, just doing cooking things is not the only aspect of the job of chef.
I think local commits are pretty useful, and local branches sometimes are as well. But "using branches heavily" is a pet peeve of mine. Git encourages lots of branching that in most cases is unnecessary (e.g. making feature branches for everything, never committing directly into master). When working with a team, everybody should be working on as close to the same codebase as possible, to prevent difficult merges later on. In my view, merging has a very non-linear cost based on how far apart the branches are, both in terms of time and amount of code changed, because it's more likely that the merge will have more tangled dependencies, and the code will be less fresh in the mind of whoever's merging.
Merge commits can also hide lots of information, like exactly how any merge conflicts were resolved, since they're buried in what is basically a squashed commit of everything in the merged branch since it diverged.
And finally, they make the commit history much harder to understand. I had to bug everyone on my team to run "git config --global pull.rebase true" just to have a somewhat sane, linear history without tons of merges in day-to-day development.
When working with a team, everybody should be working on as close to the same codebase as possible, to prevent difficult merges later on.
I agree with this, but disagree that avoiding branching is a good way to do it. In my experience, the solution is more, smaller, feature-specific branches that get merged back to master quickly (within a couple of days if possible). If you need to maintain a long-running feature branch, it should frequently be rebased on top of master so that at any given point the likelihood of major conflicts is reduced.
I disagree with your analogies. I think git branching is more like a secretary with a very well organized filing system. Does the filing system make her better secretary? Maybe not necessarily - she could work twice as hard and still meet the boss's requirements. But a secretary with a stellar filing system will be more effective than she would be without one. and that does make her 'better'.
If you have git style branching available, you can commit half-finished ideas and save ALL your backup versions. Almost all my directories are littered with files called sourcefile.v1 sourcefile.v2 sourcefile.old etc. etc. With git if your current version hits a dead-end, you can easily switch back to an earlier branch before you went off the deep end.
At least, that's how I code. I generally just jam code in down different paths, often refactoring whatever I'm doing when a new understanding of something comes along, but often this results in another incorrect branch and I need to back up to 'semi-working' code.
It was really hard to keep reading after this line. It's like saying painting your bedroom red will make you better at sex.
I had the experience that having to switch back to SVN made my workflow significantly worse, lowering my productivity a tiny bit and thereby making me a slightly worse programmer overall.
The importance and convenience of cheap local branches is nothing that will be known to someone who hasn't used them. If you are used to them, using a system without them makes you feel you are doing the job that the tool should do.
You seem to regard programming as the act of writing code. I, however, view programming as the act of creating software. And using branches heavily definitely helps me to be better at creating software. Having small feature-specific branches makes it much easier for others to review my code, which increases the quality of the code that gets merged. Improvements in code quality seems like a pretty good definition of getting better as a programmer.
Comments
It was really hard to keep reading after this line. It's like saying painting your bedroom red will make you better at sex. It's like saying getting a gas-powered golf cart will make you better at golf. It's like saying changing your mouse to be inverted on the Y-axis will make you better at computer games. All of these things change the experience, but they don't make you inherently better at anything. Just like branching during development.
I find it plausible that a golf cart could make somebody better at golf. Without the cart, a non-trivial amount of exertion is spent on a tangentially related task (getting from hole to hole) instead of on the primary task (getting the ball from hole to hole). Something that allows golfers to better focus on golfing could conceivably improve their game.
In my experience as a non-participating attendee, very little of non-professional golf is actually about the ball and the holes.
Most of it is about what is discussed when walking between holes; to that end, a golf cart would be detrimental to the 'purpose'.
I really get tired of this sort of response where the one replying ignores the primary point in order to take issue with a single portion of one of several examples that bolstered it.
I am not ignoring the primary point. My point about golf-carts and better golfers maps back onto branching and better programmers.
To spell it out explicitly: I believe that modern version control systems, specifically ones that provide sophisticated branching facilities, reduce mental load on programmers and speed up tedious tasks. This could very well make people who take advantage of them better programmers (where "better" can be described in terms of efficiency). The less time I spend managing branches and doing merges/rebases the old way, the more time and effort I am able to devote to my primary task (actually programming).
I could manage patch files and tarballs with quilt, but I would be wasting my time and my productivity would drop. That would make me a "worse" programmer. If bad tools can hold me back, then better tools can improve me.
ok then: "A paintbrush in hand doesn't make you Monet"
"Using paintbrushes heavily in your painting can make you a better painter like few other habits can."
Still seems to work.
Tell Michaelangelo that he can only carve stone with a sewing needle and he may a sculpt you something nice, but I doubt it would be David.
I think by "better programmer", he meant you will function better as someone who writes code in the context of a team. And using branches properly can (a) help other people grok the code you write, (b) help you maintain clarity with an influx of change requests.
Of course advice to "just use branches" is not going to make up for core deficits in your programming knowledge. But in my experience a lot of the trouble we get into on software teams is due to workflow problems and misunderstandings rather than "bad programming".
Sure a good chef will be able to cook an amazing meal with just a spoon, a frying pan and a steak knife. But, he will do better with a full kitchen. And if you want him to do it in a way actually capable of handling a restaurant - the full kitchen is needed. He may not be a better cook with the tools, but he certainly will be a better chef. Because you know, just doing cooking things is not the only aspect of the job of chef.
I think local commits are pretty useful, and local branches sometimes are as well. But "using branches heavily" is a pet peeve of mine. Git encourages lots of branching that in most cases is unnecessary (e.g. making feature branches for everything, never committing directly into master). When working with a team, everybody should be working on as close to the same codebase as possible, to prevent difficult merges later on. In my view, merging has a very non-linear cost based on how far apart the branches are, both in terms of time and amount of code changed, because it's more likely that the merge will have more tangled dependencies, and the code will be less fresh in the mind of whoever's merging.
Merge commits can also hide lots of information, like exactly how any merge conflicts were resolved, since they're buried in what is basically a squashed commit of everything in the merged branch since it diverged.
And finally, they make the commit history much harder to understand. I had to bug everyone on my team to run "git config --global pull.rebase true" just to have a somewhat sane, linear history without tons of merges in day-to-day development.
I agree with this, but disagree that avoiding branching is a good way to do it. In my experience, the solution is more, smaller, feature-specific branches that get merged back to master quickly (within a couple of days if possible). If you need to maintain a long-running feature branch, it should frequently be rebased on top of master so that at any given point the likelihood of major conflicts is reduced.
I disagree with your analogies. I think git branching is more like a secretary with a very well organized filing system. Does the filing system make her better secretary? Maybe not necessarily - she could work twice as hard and still meet the boss's requirements. But a secretary with a stellar filing system will be more effective than she would be without one. and that does make her 'better'.
If you have git style branching available, you can commit half-finished ideas and save ALL your backup versions. Almost all my directories are littered with files called sourcefile.v1 sourcefile.v2 sourcefile.old etc. etc. With git if your current version hits a dead-end, you can easily switch back to an earlier branch before you went off the deep end.
At least, that's how I code. I generally just jam code in down different paths, often refactoring whatever I'm doing when a new understanding of something comes along, but often this results in another incorrect branch and I need to back up to 'semi-working' code.
I had the experience that having to switch back to SVN made my workflow significantly worse, lowering my productivity a tiny bit and thereby making me a slightly worse programmer overall.
The importance and convenience of cheap local branches is nothing that will be known to someone who hasn't used them. If you are used to them, using a system without them makes you feel you are doing the job that the tool should do.
You seem to regard programming as the act of writing code. I, however, view programming as the act of creating software. And using branches heavily definitely helps me to be better at creating software. Having small feature-specific branches makes it much easier for others to review my code, which increases the quality of the code that gets merged. Improvements in code quality seems like a pretty good definition of getting better as a programmer.
I see branching as a logical infrastructure, somehow related to function, it isolates logic. Easy and frequent branching may help tailor this.