5 ms·

If you got a long-lived branch is extremely cumbersome to rebase that everytime you need something from master, especially if you are not the only developper on

If you got a long-lived branch is extremely cumbersome to rebase that everytime you need something from master, especially if you are not the only developper on it. Maybe our stories are too big, but a feature branch in our company lives at least 3-4 weeks with 4 developers working on it. The only time I use rebase is when I got local commits, and I want to pull changes from my team mates also working on the same branch.

de_watcher 8y ago
More everyone rebases - less cumbersome it gets. People start structuring their code across time, not just using the commits as dumps.
- ShinTakuya 8y ago
  Yep exactly, also makes the code easier to test, understand, and less susceptible to loss of time due to context switching (since you can read those 20 lines of code you wrote and remember where you were up to in a shorter time).
ShinTakuya 8y ago
It's okay to have a long lived branch. But you should be cherry picking commits from it to master regularly and rebasing on master even more regularly. It's always possible to do so, and I'm happy to explain how it can be done if you think I'm wrong. If you cherry pick to master regularly, rebases on master are never cumbersome.
- pjc50 8y ago
  > cherry picking commits from it to master regularly Surely the whole point of a long-lived branch is to contain stuff that's not in master - ie things that are being deliberately kept out of it?
  - ShinTakuya 8y ago
    Sure, and that's what you can do. For instance, for a website the long lived branch can contain a commit adding a link to a new feature on the homepage, only cherry picking that aspect at the very end of development so that you can work on the feature in shadow. The point is that you merge anything that is safe to merge, which is usually most of the code if you find a way to hide it or otherwise incrementally change things.
    - djajshgsjja 8y ago
      Huh, I’ve used this development pattern before, but never re-used the same branch after merging code into master. I’d keep the new feature behind a configurable flag so it could be enabled in local or dev environments. Multiple branches might get created and merged to master over time. The feature would be tested in the dev environment (and maybe on a subset of users in prod), before the flag is flipped to enable the feature in prod.
      - ShinTakuya 8y ago
        That's actually my preferred way of doing it too, I was more explaining how a long lived branch can be useful while still not having to deal with merge conflicts when using cherry picking.

de_watcher 8y ago

More everyone rebases - less cumbersome it gets. People start structuring their code across time, not just using the commits as dumps.

ShinTakuya 8y ago
Yep exactly, also makes the code easier to test, understand, and less susceptible to loss of time due to context switching (since you can read those 20 lines of code you wrote and remember where you were up to in a shorter time).

ShinTakuya 8y ago

It's okay to have a long lived branch. But you should be cherry picking commits from it to master regularly and rebasing on master even more regularly. It's always possible to do so, and I'm happy to explain how it can be done if you think I'm wrong. If you cherry pick to master regularly, rebases on master are never cumbersome.

pjc50 8y ago
> cherry picking commits from it to master regularly Surely the whole point of a long-lived branch is to contain stuff that's not in master - ie things that are being deliberately kept out of it?
- ShinTakuya 8y ago
  Sure, and that's what you can do. For instance, for a website the long lived branch can contain a commit adding a link to a new feature on the homepage, only cherry picking that aspect at the very end of development so that you can work on the feature in shadow. The point is that you merge anything that is safe to merge, which is usually most of the code if you find a way to hide it or otherwise incrementally change things.
  - djajshgsjja 8y ago
    Huh, I’ve used this development pattern before, but never re-used the same branch after merging code into master. I’d keep the new feature behind a configurable flag so it could be enabled in local or dev environments. Multiple branches might get created and merged to master over time. The feature would be tested in the dev environment (and maybe on a subset of users in prod), before the flag is flipped to enable the feature in prod.
    - ShinTakuya 8y ago
      That's actually my preferred way of doing it too, I was more explaining how a long lived branch can be useful while still not having to deal with merge conflicts when using cherry picking.