TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

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

8 pointsby rufugeeabout 2 years ago
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?

6 comments

sys42590about 2 years ago
My personal recommendation:<p>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.<p>NEVER DO MERGE COMMITS: Always rebase + fast forward merging only.<p>Branches that never reached production and likely never will should be discarded after a while.<p>Branches that reached production e.g. hotfix branches should be converted to tags after a while.
评论 #34963140 未加载
superdeedaabout 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.<p>[1]: <a href="https:&#x2F;&#x2F;githubflow.github.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;githubflow.github.io&#x2F;</a>
paiuteabout 2 years ago
I personally prefer a simplified version of git-tag-flow: <a href="https:&#x2F;&#x2F;github.com&#x2F;vasdee&#x2F;git-tag-flow">https:&#x2F;&#x2F;github.com&#x2F;vasdee&#x2F;git-tag-flow</a><p>I hate git-flow with a passion.
PaulHouleabout 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.
sethammonsabout 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.<p>It is all about reducing feedback cycles.
Daedrenabout 2 years ago
Still on Gitflow.<p>It&#x27;s rather simple for a new employee to understand, meshes in nicely with CI&#x2F;CD systems and the release processes of the places I worked at.
评论 #34969378 未加载