5 ms·

The last commit for the dev branch was 3 days ago, so there is some development still happening. The last merge to main was March 2024, though.

rowbin 1y 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.
- repeekad 1y 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 1y ago
    That's hilarious. I'd be so pissed if I was their manager (or their manager's manager).
  - DagsEoress 1y ago
    Brainless politics ruined coding
- gouggoug 1y 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 1y 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 1y 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.
      - brabel 1y ago
        Sorry but you are just using source control very wrong if you keep 2 parallel environments in the exact same code base but different branches. The build itself should know whether to build for one environment or another!
        jiggunjer 1y ago
        Sorry but you building wrong if you need separate builds.
        skydhash 1y ago
        Mobile apps release process will disagree with you. there’s a gap of around 4 days between what you consider as a release and what can be on prod. If you got rebutted by review, you need to edit the code. If you want to rollback, you need to edit the code. You can only be linear if you control releases.
gjvc 1y ago
usual passive-aggressive HN comment on someone's effort

rowbin 1y 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.

repeekad 1y 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 1y ago
  That's hilarious. I'd be so pissed if I was their manager (or their manager's manager).
- DagsEoress 1y ago
  Brainless politics ruined coding
gouggoug 1y 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 1y 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 1y 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.
    - brabel 1y ago
      Sorry but you are just using source control very wrong if you keep 2 parallel environments in the exact same code base but different branches. The build itself should know whether to build for one environment or another!
      - jiggunjer 1y ago
        Sorry but you building wrong if you need separate builds.
        skydhash 1y ago
        Mobile apps release process will disagree with you. there’s a gap of around 4 days between what you consider as a release and what can be on prod. If you got rebutted by review, you need to edit the code. If you want to rollback, you need to edit the code. You can only be linear if you control releases.

gjvc 1y ago

usual passive-aggressive HN comment on someone's effort