rowbin 8 hours ago

I think they use master for releases only. Development branch is actively worked on and more than 100 commits ahead of master which is totally active. Last full release March 2024 is totally fine. People can always build from develop branch.

  • gouggoug 6 hours ago

    Somewhat related...

    At [company x] someone wrote a starter guide that tells developers to create a "production", "staging" and "dev" branch for any new repo. We have tons of repositories that follow this pattern.

    For many of them, each branch has taken of its own life and could be considered its own completely different codebase. It's a nightmare to manage and it confuses developers on a regular basis.

    Don't do this.

    If you want to deploy different versions of your software in different environments, use SEMVER and git tags. Don't create 1 branch per environment...

    I have since edited that starter guide and crossed out this recommendation.

    • jiggunjer 6 hours ago

      It works fine if you review PRs and only allow STG->PRD promotions. It breaks down when people start making separate builds for each env. Treat env as config as you'll just have to manage a config folder in that repo.

      • tankenmate 5 hours ago

        I concur, it works fine as long as devs follow the procedure. I also prefer to enforce linear history as well so that git bisect works properly; but then this requires devs to understand how to use --ff-only and also if you're using github to use a github action to fast forward as github doesn't natively support fast forward (one of github's many sins).

        But then I also find I need to train devs on how git actually works and how to use git properly because I find that only about 10% of devs actually understand git. But it works out best for everyone once all the devs understand git, so generally most devs appreciate it when someone is willing to teach them the ins and outs (but not all devs appreciate it before they learn it properly though).

        As always though, it's trade offs.

    • ezst 3 hours ago

      > For many of them, each branch has taken of its own life and could be considered its own completely different codebase.

      Seems you have bigger process issues to tackle. There's nothing inherently wrong with having per-env branches (if one thing, it's made harder by git being so terrible at branching in the general/long lived case, but the VCS cannot alone be blamed for developers consistently pushing to inadequate branches).

      • zx8080 an hour ago

        > if one thing, it's made harder by git being so terrible at branching in the general/long lived case

        Interesting. What's wrong with branching in git?

    • kardianos an hour ago

      Generally agree. All changes for me are cherry-picked to master only.

  • repeekad 7 hours ago

    Reminds me of when someone at the company didn’t like the branch master so they unilaterally directed their team to start working on “main”, resulting in a massive merge conflict that took over two weeks of dedicated effort to resolve, ugh…

    • IshKebab 7 hours ago

      That's hilarious. I'd be so pissed if I was their manager (or their manager's manager).

gjvc 6 hours ago

usual passive-aggressive HN comment on someone's effort