Ask HN: What Git branching strategy do you use in 2023, and why?

8 points by rufugee 2 years ago | 16 comments
I'm working with a new small team (less than 8) and converting them to Git. It's been awhile since I started with a green field when it comes to branching strategy. What do you follow in 2023, and why?
  • sys42590 2 years ago
    My personal recommendation:

    Development happens on short lived branches, gets merged to master via pull request after code review if needed, but at least some automated testing should be done.

    NEVER DO MERGE COMMITS: Always rebase + fast forward merging only.

    Branches that never reached production and likely never will should be discarded after a while.

    Branches that reached production e.g. hotfix branches should be converted to tags after a while.

    • l72 2 years ago
      I am the opposite. When it comes to bring short lived branches into the main branch, we only allow MERGE COMMITS, we don't ever do fast forward commits.

      When looking at history on our main branch, we ALWAYS use `git log --first-parent` which ONLY shows merge commits. Then it shows you exactly what was important (the merge) and in the correct order.

      I really wish this was the default view of git log, or really, if git log acted like bzr log that would be even better. It would stop all these arguments about how to have linear history.

      • 1_1xdev1 2 years ago
        Merge commits are annoying IMO because the revert command isn’t always clean or obvious, and you see a lot of noise . But your recommendation of `—first-parent` might alleviate the second concern.

        Personally I’m a `merge —squash` guy but to each their own

        • l72 2 years ago
          `merge --squash` generates a nice linear history in the main branch and other developers don't need to worry about rebasing their feature branches or keeping them super clean. That's great.

          However, `merge --squash` loses its association with that feature branch, which is annoying. You also don't get to see any of the history of what happened in that branch, which can sometimes be really useful if there ends up being a bug that you want to bisect. You don't have any of the original developers individual steps, since it all comes in as a big, unassociated chunk.

          • foobarbaz33 2 years ago
            Do you mean "fast-forward" merges that don't have a merge commit?

            An actual "merge commit" should make it easier to revert/reset. I always use merge --no-ff to ensure a merge commit is created. With a merge commit it's clear where the feature branch starts/ends.

      • superdeeda 2 years ago
        Github flow [1] for me - which is basically what others have mentioned about branching feature branches directly from main and merging as soon as the pull request is approved.

        [1]: https://githubflow.github.io/

        • paiute 2 years ago
          I personally prefer a simplified version of git-tag-flow: https://github.com/vasdee/git-tag-flow

          I hate git-flow with a passion.

          • PaulHoule 2 years ago
            I work in a feature branch, the tech lead does a code review (for real!) then merges to develop, the tester tests the develop branch, if it passes that gets merged to the master branch, the prod system is updated, the tester tests it again.
            • sethammons 2 years ago
              Short lived branches. If tests are green and it passes code review, squash merge, bump the release, and deploy. Never force push anything ever. Rewriting history is bad.

              It is all about reducing feedback cycles.

              • Daedren 2 years ago
                Still on Gitflow.

                It's rather simple for a new employee to understand, meshes in nicely with CI/CD systems and the release processes of the places I worked at.

                • foobarbaz33 2 years ago
                  I think git flow has a lot of merit despite being classified as outdated by many.

                  Many modern workflows literally have has you prematurely deploying experimental code into production. Hidden behind feature flags. Release branches may not be needed when you do that, but that's a transfer of complexity, not an elimination.

                  Also the alternatives usually involve a lot of cherry picking. That's nice, but cherry picking requires good understanding of the code to properly do. Complexity moved away from one area into another again.