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

      Precisely. In practice, trunk based development just means your branch is local instead of on remote.

      • 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.

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

      I’m actually confused by the whole post.

      In contrast, the branching model

      TBD is a branching model which works fine with DVCS. I’ve used it successfully with git and it was better than the other “git/github flows.”

      The point of TBD is to have well-defined branches for certain tasks or topics. Nothing is forced for how you achieve this. For example you won’t get conflicts if you have a rule to merge the master/develop/main branch, or squash or rebase your commits on your feature branch before your merge request is ready.

      Also, I disagree with the person who says it’s a “developer culture problem.” IMHO it’s a branching model that should be respected in the same way we have rules for code formatting or using linters before a commit whether it’s a tool, a hook, or a check in the CI.

      Overall I prefer TBD because it has fewer branches than the other methods.