Comment by kubanczyk | Hacker News Reader

Comment by kubanczyk | Hacker News Reader

Parent Full thread

A year after you release v1.0.0 (which you say is a tag), a customer reports a bug in it. They don't want a breaking upgrade to v9.13.0. They want to pay for v1.0.1 (aka "hotfix").

But you can't open a PR against a tag v1.0.0. Hence you discover that v1.0 should be a branch, and both v1.0.0 and v1.0.1 tags. This way you can open a PR against v1.0 and easily create v1.0.1, v1.0.2, etc.

Another problem. You are at "master" and approach v13.0.0. But there are numerous bugs to fix before you release. Testing takes >24 hours. You choose to work on bugs on a branch (v13.0) this way master can proceed with new features and not be feature-frozen for days or weeks.

Another problem. Your CI is deficient in that it allows merging and cloning before it makes sure that previous merge produced good product. Puny as it is, it is the current industry standard. Thus your main branch becomes broken now and then. So you call it "develop" and only merge it to "master" what you are sure is a good product.

If these common situations don't apply to you - proceed as you are. Do the simplest thing possible, but not simpler. What you've described doesn't create any roadblock or dead end street for the project.

> A year after you release v1.0.0 (which you say is a tag), a customer reports a bug in it. They don't want a breaking upgrade to v9.13.0. They want to pay for v1.0.1 (aka "hotfix").

> But you can't open a PR against a tag v1.0.0. Hence you discover that v1.0 should be a branch, and both v1.0.0 and v1.0.1 tags. This way you can open a PR against v1.0 and easily create v1.0.1, v1.0.2, etc.

So you could just `git checkout v1.0.0; git checkout -b v1.0`, commit your hotfix and deploy v1.0.1.

> Another problem. You are at "master" and approach v13.0.0. But there are numerous bugs to fix before you release. Testing takes >24 hours. You choose to work on bugs on a branch (v13.0) this way master can proceed with new features and not be feature-frozen for days or weeks.

Or you could use topic branches for new features, and fix bugs on master at the same time.

> Another problem. Your CI is deficient in that it allows merging and cloning before it makes sure that previous merge produced good product. Puny as it is, it is the current industry standard. Thus your main branch becomes broken now and then. So you call it "develop" and only merge it to "master" what you are sure is a good product.

I don't understand your point here. Usually your CI builds a branch, runs some tests on the compiled product and makes sure the `master` branch is ok before deploying to staging or production.

> If these common situations don't apply to you - proceed as you are. Do the simplest thing possible, but not simpler. What you've described doesn't create any roadblock or dead end street for the project.

I think there are a lot of branching strategies for a reason. Your use cases can be covered with other branching strategies as well.

> Or you could use topic branches for new features, and fix bugs on master at the same time.

One could but it's often very desirable to integrate branches fast. If merging is delayed by a release there will be stale branches to merge. The experience of merging long branches scares people off of refactoring, because a refactoring creates more conflicts the longer it stays unmerged.

> I don't understand your point here. Usually your CI builds a branch, runs some tests on the compiled product and makes sure the `master` branch is ok before deploying to staging or production.

As long as you have sequential merges there is no problem. But when you merge into the main branch and it is ahead of you (due to another merge) the build may become broken. You can merge the other way first, sure. But if you want to enforce this you need support from your infrastructure.

The only way to be sure: CI checks out master, merges the feature branch, and tests that version. If successful, push to origin. If the push fails (because a parallel pushed happened in between) start from the beginning.

The challenge here is that pull request might be tested again and again. It increases the CI load by some factor for large projects.

> `git checkout -b v1.0`, commit your hotfix and deploy v1.0.1

And the code review happens where? You need to:

  git checkout -b v1.0
  git push
  ask your colleague for a code review of branch v1.0

Parent asked if they can only live with feature branches and master. Branch v1.0 is neither.

> I don't understand your point here. Usually your CI builds a branch, runs some tests on the compiled product and makes sure the `master` branch is ok.

Gasp... You are right, you don't understand my point. You show master to everyone before making sure it isn't broken?

The original post was describing "Administrator is in charge of merging, maintains a linear history. Releases are just tags on master", you seem to discuss the various branching strategy while it seems to me the explanation was about the fact that we need a branching strategy in the first place. Do I miss something?

The reply to the original post was describing branching off at a historic place without merging back into trunk. You can't have a branch without a branch ;-) I think the person replying did not understand that you can easily branch from a commit with a tag (and in fact a branch is really just a special kind of tag on a commit in git).

> So you could just `git checkout v1.0.0; git checkout -b v1.0`,

git checkout can take an optional tag/branch argument so

`git checkout -b v1.0 v1.0.0` works just as well for creating branch `v1.0` off of tag `v1.0.0`

Yes, in those situations you will need additional branches beyond just master (and short-lived/personal feature branches). But,

1. You can implement the necessary branching with much less complexity than git-flow. Just have master, plus possibly some stable development branches created when you need it. Tag v1.0.0 off master, then make the v1.x branch and tag v1.0.1 on it. Or branch v13.x off master and tag v13.0.0 once it's stable. No "develop" branch, no long-running feature branches, nothing.

2. Importantly, you can implement the necessary branching when you need it. If you never run into these situations, you can keep having just a single master branch and not worry about it. You do not need to future-proof yourself for fear that you might run into a complicated situation. If you do, then you can make release branches at that point.

You don't need a separate "develop" / "master" branch to cover up weakness es in your CI. If your CI is good enough that you can automatically merge "develop" into "master" when tests pass, it's good enough that you can actually implement the Not Rocket Science Rule and automatically merge everything into master when tests pass. If it's not good enough, then just keep track of the last-known good commit on master, and fix build/test failures on master urgently, don't shove them off onto another branch so you can ignore then. The industry standard is the idea that "who broke the build" is a well-defined question - but it means the right step is to fix the build.

Parent. I totally agree, especially with the CI remark.

I hate "develop" and I wish I could stop pointing out how crappy idea it is.

Reply on news.ycombinator.com