• glad_cat@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    What do you mean by local? git can hide merges or feature branches, and you have to save your temporary code by pushing it to the server at the end of the day. You can rebase your code or squash it before merging, but TBD is not talking about that IIRC.

    • Jim@programming.dev
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      If the work I’m doing is on a feature branch on remote or locally, why does it matter to the rest of the team? My integration steps can be done on a server instead of locally. TBD forces teams to collaborate synchronously since changes are pushed straight to trunk. Rebase or squashes are irrelevant here.

      Another poster put it great: TBD is trying to solve a culture problem. Feature branches and pull requests into main is much more flexible. The only time TBD make sense is for small teams - like 2 or maybe 3. And even at 2, I’d much rather create feature branches that merge into main.

      • glad_cat@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        1 year ago

        TBD forces teams to collaborate synchronously since changes are pushed straight to trunk

        The main page about TBD says you can still use feature branches, merge requests, or squash/rebase, and that’s how I use it. It only says why and how you should use release branches, and how you should fix bugs in a release. The linked article is not talking about TBD at all, hence my confusion about this whole post.