Comment by tankenmate

Comment by tankenmate 11 hours ago

6 replies

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.

jmmv 8 hours ago

You can configure branch protections in GitHub to rebase during PR merges and enforce a linear history.

brabel 9 hours 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!

  • tankenmate 8 hours ago

    They are the same only sometimes; devs work on code on feature / fix / whatever branch, then when they've finished dev testing you do a code review and then it gets fast forwarded onto the dev branch, then when it suits for staging (non dev team stakeholder testing / infra testing) it gets fast forwarded to staging, then when it passes staging testing (if necessary), then it get ff onto prod and deployed. so dev will sometimes point to the same commit as staging but sometimes not, and staging will point to the same commit as prod but sometimes not. It's a funnel, a conveyor belt if you will.

    • brabel 4 hours ago

      Yes I know. That's not how they said they are doing it.

  • jiggunjer 9 hours ago

    Sorry but you building wrong if you need separate builds.

    • skydhash 5 hours 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.