4 ms·

Agreed. If you like pain, long lived branches are key.

tsak 3y ago
You can have both. Some bigger features can take a while to complete and you can keep the pain to a minimum be rebasing your feature branch on the latest mainline branch often.
- samdjstephens 3y ago
  Sure, if there’s only one long lived large feature branch and everything else is trunk-based style development. If another large feature branch is merged then your regular rebase turns into a horror-merge.
  - hinkley 3y ago
    Development, like construction, is horribly ineffective at accurate projections. So if it's "your turn" to have the (singular) long lived feature branch, you will run over your deadline and into someone else's start date. There will be someone you're blocking who starts pressuring you to finish or for the org to make an exception and allow 2 feature branches. And six months later, what was good for the goose will be good for the gander and then you have 2 feature branches part of the official process. Which of course means you'll occasionally have 3. After that it's like Texas Highways. They just keep getting more lanes and traffic gets worse.
- hinkley 3y ago
  Or you can launch dark code that gets integration tested on every build.
- munk-a 3y ago
  Rebasing regularly is a task that requires diligence, skill and good communication. I've built solo "out-there" feature branches that I've kept alive through careful rebasing for more than a year without issue - but once you're working on a team absolutely everybody must be onboard with the strategy for it to work... as soon as people go off on a garden path doing unnecessary refactoring[1] in a big long-lived feature branch you start into the world of pain - refactors (especially code movement within a file like function reordering) lead to all sorts of unnecessary chaos. If you're going to make a long lived feature branch you absolutely need to KISS[2] - the smaller your change set the better your chances of avoiding having a bad time. 1. IMO refactoring is one of the best things you can do for your codebase but it should NEVER happen in a branch that may be blocked from merging for other reasons - keep refactors in isolated branches if there's any danger of your merge being delayed for any reason other than an issue with the refactor. 2. Keep It Simple, Stupid - i.e. avoid any complexities not absolutely necessary for the feature.
- bunderbunder 3y ago
  Or, if you want to make life more rather than less painful, merge the changes from main instead of rebasing.
rqtwteye 3y ago
Our testers work on a branch often for half a year or more. I always “love” helping them merge their stuff.
- jhoechtl 3y ago
  How come testers work on a branch?
  - rqtwteye 3y ago
    They are writing automated tests. Same workflow as development.
- hinkley 3y ago
  When you finally leave it'll take them six months to a year to realize they should have paid you more money.
hinkley 3y ago
If you want to foment resentment and infighting, few things work as well as long lived branches.
- munk-a 3y ago
  Personally I love the feeling of pushing up a PR and realizing that the branch I thought was done actually has several weeks of merge conflict resolution to do. Nothing quite like it to make one feel alive.
  - hinkley 3y ago
    I love the people standing outside my cube or saying "hey hinkley" in chat because even though I'm "good at merges" by developer standards I still have maybe a 90% success rate. And so I've either broken their shit, or they broke someone else's and they know I'm the closest we have to a git surgeon so they've come for a consult.
    - munk-a 3y ago
      Yup ditto (and I'd assume most participants in this thread are also local VCS gurus) - and I've still had two occurrences in my professional life where I looked at the git conflict and just bailed - reading the original branch for inspiration but essentially just rewriting the change over a new and completely different system. Thankfully those were pretty early on and I think solid unit tests can really shine when it comes to trying to resolve merge conflicts. My biggest fear in rebasing/merging is that there's a function "doStuff(foo, bar, baz)" which still presents the same function signature but which had its effective code contract completely wrecked by some concurrent changes. Git is wonderful - but git can't do anything if it looks like everything in the files you're touching didn't change... but they secretly did change because there's a mess of interwoven logic between your file and another file.
      - hinkley 3y ago
        Yeah if someone has as many merges in their branch as they have commits, I might allocate ten minutes to trying to cherry-pick their changes out, and if that doesn't work I tell them to paraphrase their code onto a new branch. Probably about the same number of times that you have.

tsak 3y ago

You can have both. Some bigger features can take a while to complete and you can keep the pain to a minimum be rebasing your feature branch on the latest mainline branch often.

samdjstephens 3y ago
Sure, if there’s only one long lived large feature branch and everything else is trunk-based style development. If another large feature branch is merged then your regular rebase turns into a horror-merge.
- hinkley 3y ago
  Development, like construction, is horribly ineffective at accurate projections. So if it's "your turn" to have the (singular) long lived feature branch, you will run over your deadline and into someone else's start date. There will be someone you're blocking who starts pressuring you to finish or for the org to make an exception and allow 2 feature branches. And six months later, what was good for the goose will be good for the gander and then you have 2 feature branches part of the official process. Which of course means you'll occasionally have 3. After that it's like Texas Highways. They just keep getting more lanes and traffic gets worse.
hinkley 3y ago
Or you can launch dark code that gets integration tested on every build.
munk-a 3y ago
Rebasing regularly is a task that requires diligence, skill and good communication. I've built solo "out-there" feature branches that I've kept alive through careful rebasing for more than a year without issue - but once you're working on a team absolutely everybody must be onboard with the strategy for it to work... as soon as people go off on a garden path doing unnecessary refactoring[1] in a big long-lived feature branch you start into the world of pain - refactors (especially code movement within a file like function reordering) lead to all sorts of unnecessary chaos. If you're going to make a long lived feature branch you absolutely need to KISS[2] - the smaller your change set the better your chances of avoiding having a bad time. 1. IMO refactoring is one of the best things you can do for your codebase but it should NEVER happen in a branch that may be blocked from merging for other reasons - keep refactors in isolated branches if there's any danger of your merge being delayed for any reason other than an issue with the refactor. 2. Keep It Simple, Stupid - i.e. avoid any complexities not absolutely necessary for the feature.
bunderbunder 3y ago
Or, if you want to make life more rather than less painful, merge the changes from main instead of rebasing.

rqtwteye 3y ago

Our testers work on a branch often for half a year or more. I always “love” helping them merge their stuff.

jhoechtl 3y ago
How come testers work on a branch?
- rqtwteye 3y ago
  They are writing automated tests. Same workflow as development.
hinkley 3y ago
When you finally leave it'll take them six months to a year to realize they should have paid you more money.

hinkley 3y ago

If you want to foment resentment and infighting, few things work as well as long lived branches.

munk-a 3y ago
Personally I love the feeling of pushing up a PR and realizing that the branch I thought was done actually has several weeks of merge conflict resolution to do. Nothing quite like it to make one feel alive.
- hinkley 3y ago
  I love the people standing outside my cube or saying "hey hinkley" in chat because even though I'm "good at merges" by developer standards I still have maybe a 90% success rate. And so I've either broken their shit, or they broke someone else's and they know I'm the closest we have to a git surgeon so they've come for a consult.
  - munk-a 3y ago
    Yup ditto (and I'd assume most participants in this thread are also local VCS gurus) - and I've still had two occurrences in my professional life where I looked at the git conflict and just bailed - reading the original branch for inspiration but essentially just rewriting the change over a new and completely different system. Thankfully those were pretty early on and I think solid unit tests can really shine when it comes to trying to resolve merge conflicts. My biggest fear in rebasing/merging is that there's a function "doStuff(foo, bar, baz)" which still presents the same function signature but which had its effective code contract completely wrecked by some concurrent changes. Git is wonderful - but git can't do anything if it looks like everything in the files you're touching didn't change... but they secretly did change because there's a mess of interwoven logic between your file and another file.
    - hinkley 3y ago
      Yeah if someone has as many merges in their branch as they have commits, I might allocate ten minutes to trying to cherry-pick their changes out, and if that doesn't work I tell them to paraphrase their code onto a new branch. Probably about the same number of times that you have.