TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

A successful Git branching model (2010)

127 点作者 gandalfar超过 7 年前

13 条评论

mabbo超过 7 年前
I&#x27;ve got a much nicer branching model- try not to have one. Everyone works off master, and you aren&#x27;t allowed to check in code that won&#x27;t run in production. Hide unfinished features behind feature flags, and never merge&#x2F;push a change that won&#x27;t pass tests&#x2F;CI.<p>The chaos of huge feature merges (a key source of bugs I&#x27;ve experienced) is minimized. You deploy fixes hourly, not weekly (or later monthly when it just won&#x27;t seem to pass CI). The time between code being written and a bug being seen can be reduced to minutes and hours, making finding the root cause a breeze.<p>Just my preference, but very open to debate.
评论 #15377313 未加载
评论 #15377207 未加载
评论 #15380289 未加载
评论 #15377222 未加载
评论 #15378640 未加载
评论 #15378198 未加载
评论 #15378054 未加载
评论 #15378892 未加载
评论 #15379035 未加载
评论 #15377451 未加载
评论 #15382067 未加载
评论 #15377819 未加载
评论 #15377226 未加载
评论 #15380014 未加载
评论 #15377516 未加载
评论 #15378013 未加载
watt超过 7 年前
The advice here given to avoid using &quot;master&quot; branch for development, and advice to create non-default branch named &quot;develop&quot; (or variations thereof) is quite harmful.<p>If you must have a &quot;release&quot; branch or &quot;stable&quot; branch, ok, go for it, but leave the &quot;master&quot; for developing. Why? Strive to have sane defaults.<p>Frankly, the idea that somebody must check out some extra special branch after cloning repo in order to start properly developing, is not sane.
评论 #15377118 未加载
评论 #15377094 未加载
评论 #15377050 未加载
评论 #15377247 未加载
activatedgeek超过 7 年前
It is good exercise to actually learn this branching model and then use it in practice. You will soon realize that most projects will suddenly start taking unnecessary toll on you just because now you want to maintain multiple branches and it is a huge PITA.<p>Instead just follow this simple routine - stay as close to the master as possible. If a temporary diversion is needed, create a new branch (and maintain both master and the diversion for a while). Delete the diversion once the job is done.<p>If you are never able to delete the diversion, it is not your git branching model that failed, it is you and your code who failed. Diversions may be long term (and I hope you have the workforce to maintain that branch as well) but still finite time. How to prepare that diversion is a software engineering problem and not git&#x27;s fault.
评论 #15380396 未加载
评论 #15378392 未加载
antoncohen超过 7 年前
Do not use Git Flow for a web application deployed on your own infrastructure (SaaS, microservice, mobile backend, etc.). It will slow down development and make your software less reliable.<p>The entire purpose of Git Flow is saving up changes to release later, e.g., saving up for a weekly release event. Don&#x27;t do that! Deploy your changes as soon as they are ready, if they aren&#x27;t ready don&#x27;t merge them into a shared branch. If you do Continues Delivery you don&#x27;t need &quot;hotfix&quot; branches because every changes goes out as soon as it is ready, so you don&#x27;t need any of the complexity of Git Flow.<p>By saving up changes for a release event it means more things are getting released at once. If there is a problem after deployment it will be harder to narrow down the cause. Git Flow fosters a harmful development mentality where developers merge untested changes to the develop branch, then move on, and expect someone to test and stabilize their changes before release. With trunk-based development (<a href="https:&#x2F;&#x2F;trunkbaseddevelopment.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;trunkbaseddevelopment.com&#x2F;</a>) or GitHub Flow (<a href="https:&#x2F;&#x2F;guides.github.com&#x2F;introduction&#x2F;flow&#x2F;" rel="nofollow">https:&#x2F;&#x2F;guides.github.com&#x2F;introduction&#x2F;flow&#x2F;</a>) developers take ownership of their code, and only merge to master after they have tested it. With a good deployment pipeline they can own their code all the way to production.<p>Git Flow also encourages humans to think about and make up version numbers, like 15.0.5. This is a pointless waste of brain power, web apps don&#x27;t need version numbers. The artifact systems (packages, containers, etc.) may need something, but it can just be an incrementing number that no on thinks about.<p>Git Flow wastes so much time, and makes everything it touches so complex, all to enable the harmful behavior of saving up changes for later, and enabling the pointless use of version numbers.<p>Trunk-based development and Continues Delivery is the default way people develop, it is how you would work if you had a one person company with one customer. It also is how the biggest web companies in the world work. It scales from smallest to largest. Just use trunk-based development. Stay away from Git Flow.<p>Edit: Fixed spelling of incrementing.
评论 #15380458 未加载
评论 #15381343 未加载
评论 #15379269 未加载
mcv超过 7 年前
For a moment I thought: Has someone figured out something better than git-flow? But no, it&#x27;s the original git-flow article again.<p>It&#x27;s good, but now exactly &quot;news&quot;. Every git user should be aware of git-flow, even if you do have a better way of using git.
评论 #15377276 未加载
mkempe超过 7 年前
I&#x27;ve used the git-flow approach successfully with a small team working on a medical product (so, embedded software system) -- every feature branch had to be reviewed before being merged with `develop`, which was submitted to nightly, extensive functional tests (initially one-hour long, eventually kept as a nightly subset of the more than 24-hours complete QA run) before it could be approved as a new (monthly) release and be merged with `master`. Every new feature branch was automatically treated to quick continuous integration tests, and available for manually-triggered full functional tests (on the target devices).<p>This approach ensured that we had a full trace of development work, (signed) code reviews, and software changes -- compatible with FDA audits.<p>We also automated collection of code coverage data during functional tests, to inform analysis and revisions of the battery of functional tests.
评论 #15378621 未加载
xydinesh超过 7 年前
GitLab has a good discussion on Git flow too. <a href="https:&#x2F;&#x2F;about.gitlab.com&#x2F;2014&#x2F;09&#x2F;29&#x2F;gitlab-flow&#x2F;" rel="nofollow">https:&#x2F;&#x2F;about.gitlab.com&#x2F;2014&#x2F;09&#x2F;29&#x2F;gitlab-flow&#x2F;</a>
kuharich超过 7 年前
Prior discussion: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=1966820" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=1966820</a>
stonewhite超过 7 年前
This was very much valid before the docker workflows came to happen.<p>Now maintaining two mainline branches forces you to break &quot;don&#x27;t build a container per environment&quot; cardinal rule. Trunk based development should be the go-to repository strategy for dockerized apps.
评论 #15378241 未加载
评论 #15377324 未加载
Froyoh超过 7 年前
How is this feasible for projects worked on by multiple development teams?
bschwindHN超过 7 年前
Oh I guess no one has posted it this month, let&#x27;s argue about git again.
Sujan超过 7 年前
(2010)
nstj超过 7 年前
@dang this is old
评论 #15377037 未加载