Your feature branch is your own perfect garden and you can keep it clean and shiny. But it is separated from the other gardens of your team. The more you work apart, the harder it is to reconcile. ... Your feature branch is a local optimum with high quality code. It may also be so far off the main branch that it is of no use for the upcoming release.
I don't quite understand what's going on here. Ideally, work in small chunks on feature branches that have short lives. Rebase early and often. Never submit a pull request that hasn't been rebased against master. Then rebase (and squash) it again on approval. There shouldn't be a significant span of time where you're off ignoring what's going on in the rest of the project.
Granted, I've been guilty of monster submissions that add 1000s of lines and need a week to review. But that should be a wild exception, and I kept on top of rebasing and conflict resolution every day.
IMO, the problem with committing straight to master and then reviewing it and then cleaning up after is that it causes a mess. While it's on a feature branch, you can edit history, squash, revise, amend - everything's hypothetical until you finally land it. But, once it's landed, it's real and everyone has to deal with it - including the after-hours breakages to build & test systems that might come up.
"work in small chunks on feature branches that have short lives"
Agree on some part: I have updated the title and article to mention short lived branches are OK.
Disagree on the other :): as the name suggests, "feature branch" are supposed to carry a whole feature. Unless you are making a very small change or fixing a bug, this is probably work for 1 week or more. Working on your own that long is a risk.
"But, once it's landed, it's real and everyone has to deal with it"
Agree. And this is true whether you write your code in 15 minutes push and go on vacations, or spend 3 months revising and amending all over until it's perfect. And the more you wait, the bigger the risk. While if you think about "what are the contact points between the existing code and my new code" in a feature toggles kind of way, you will build an abstraction layer around your feature that will make it easier to integrate every step of the way.
What do you think?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't quite understand what's going on here. Ideally, work in small chunks on feature branches that have short lives. Rebase early and often. Never submit a pull request that hasn't been rebased against master. Then rebase (and squash) it again on approval. There shouldn't be a significant span of time where you're off ignoring what's going on in the rest of the project.
Granted, I've been guilty of monster submissions that add 1000s of lines and need a week to review. But that should be a wild exception, and I kept on top of rebasing and conflict resolution every day.
IMO, the problem with committing straight to master and then reviewing it and then cleaning up after is that it causes a mess. While it's on a feature branch, you can edit history, squash, revise, amend - everything's hypothetical until you finally land it. But, once it's landed, it's real and everyone has to deal with it - including the after-hours breakages to build & test systems that might come up.
"work in small chunks on feature branches that have short lives"
Agree on some part: I have updated the title and article to mention short lived branches are OK.
Disagree on the other :): as the name suggests, "feature branch" are supposed to carry a whole feature. Unless you are making a very small change or fixing a bug, this is probably work for 1 week or more. Working on your own that long is a risk.
"But, once it's landed, it's real and everyone has to deal with it"
Agree. And this is true whether you write your code in 15 minutes push and go on vacations, or spend 3 months revising and amending all over until it's perfect. And the more you wait, the bigger the risk. While if you think about "what are the contact points between the existing code and my new code" in a feature toggles kind of way, you will build an abstraction layer around your feature that will make it easier to integrate every step of the way.
What do you think?