Hacker News Reader

Comment by jcon321 | Hacker News Reader

Every time I see some type of branching strategy it's always about main/master. Don't people have multiple environments, such as dev, test, pre-prod, prod? These strategies always apply merge/pull requests or changes directly to master. I protect every remote branch and require merge/pull requests to start on dev (unless of a hotfix.)

View on HN

Maintaining a branch for every environment is extremely complex and error prone. All the branching strategies you see are always about main because it's simpler. Ensure the code merged into the main branch is always in a working state and you don't need to have a complex branching strategy.

This requires stricter testing practices in the PRs, and usually also involves either requiring PRs to be up to date with master prior to merge, or re-testing of master after merge, prior to the SHA being deployable.

I generally setup CI to build from master and push to the test environment, then I manually promote the same artifact to prod when ready. This way there's no big "merge dev to prod" PRs, and the binary that runs in prod is 100% the same one tested in pre-prod.

git flow, arguably the only branching strategy people talk about by name, is all about maintaining multiple environments [1]

test environment is where PRs are deployed (or just tested) before being merged

pre-prod is for the release branch and prod is for the master branch

[1] https://nvie.com/posts/a-successful-git-branching-model/

Git Flow is not the only game in town! Take a look at GitLab Flow (and its variants), this intro does a good job of comparing related options (including git flow) --

https://docs.gitlab.com/ee/topics/gitlab_flow.html

My thinking is that you have one or more dev environments and the engineers are free to deploy whatever branch they want to these places whenever. If you have manual qa or some other team doing pre release qa, then merging your change to main can deploy to a stage env, and once the qa team okays it, the release propagates to prod. The stage env is thus optional.

But are you using a different branch for stage evn. As in, I wouldn't want to merge a release into master that gets deployed to a stage env. Because, if a critical hotfix is needed on master (for prod env) then I can't deploy prod again because master now has a new release in it (because of the stage env.)

Master doesn't have to be the only branch that deploys to prod, you could create a hotfix branch (starting from an earlier commit) and set it to push to prod in your CI to get an emergency release out.

Environments are generally handled via deployment configuration.

Reply on news.ycombinator.com