Hacker News Reader

Comment by qertoip | Hacker News Reader

Continuous integration AKA trunk based development is the workflow you want to have. Ensure you meet the prerequisites first though (reliable automated tests, solid code reviews, feature flags, etc).

To be precise, small feature branches are perfectly fine. They are meant to be reviewed and squashed into master ("trunk") in a few hours to a few days maximum.

Squashing instead of merging has a big advantage of being able to quickly revert the changes if things go awry despite all best practices in place.

PS Avoid gitflow and similar workflows as they introduce leaps and thus risk. As everything in software engineering, you want your workflow to be as incremental as possible.

View on HN

> Squashing instead of merging has a big advantage of being able to quickly revert the changes if things go awry despite all best practices in place.

Merge with --no-ff. You can revert easily, but you don't throw away the feature branch history.

> but you don't throw away the feature branch history

Once a feature is merged, how is the history of a feature branch helpful?

Since I do not see/understand the benefits of retaining feature branch history, my preference is to squash commit and merge. Perhaps, this is a result of my habits that I carry from the ClearCase days, but would love to hear the downsides of this approach.

Well given that we're talking specifically about reverting the merge when something goes awry, firstly you want that history preserved so that you can re-start work on it, potentially without pulling in all of the changes in one go; and secondly so that you can determine the precise point at which the problem happened.

Consider the difference between:

* Well we need to revert this because it's causing problems, but now we've got one massive chunk of several day's work to pick through.

…vs:

* Well we need to revert this, but we can see that the problem was specifically commit xzy, so let's yank that, do it a different way, and merge the result.

Aside from that, it can be very useful to see the individual steps in implementing a feature for a variety of reasons. Given that a --no-ff merge achieves everything you are aiming for with the squash, why wouldn't you pick the more flexible approach?

`git blame` and `git biscet`

No, reverting a merge commit does not do what most developers think it does. Correctly reverting the merge is a know source of pain.

But a policy of squashing prevents two people from working on the same feature (you shouldn't squash what you've already pushed as this changes history).

I'll go further: never* rewrite public history

*In most cases, I think we should consider invalidating secret keys instead of trying to delete it and hope nobody saw it.

Are there secret keys in your app that you can't invalidate without a lot of pain? Maybe it is time to change some things in your app.

Maybe if someone accidentally commits secret-evil-plan.txt you might want to rewrite history? I can't think of any other scenarios... I mean even if someone commits a secret key, you're probably better off revoking it and leaving the secret key there. Or should you delete that file anyway to prevent people trying to brute force your old revoked private key?

Depends on what is "public" history. Is a branch where you working on alone public, or does it become public after merging in back to master. Squashing a branch before merging back depends a lot of the discipline of the commiter. So for a branch with commits like "add FeatureX", "arg forgot this edge case", "ups another fix", "finally it works" it makes a lot of sense to squash it. While for "add FeatureX", "fix some linter errors during development" it makes then to leave the history as it is.

> *In most cases, I think we should consider invalidating secret keys instead of trying to delete it and hope nobody saw it.

Absolutely. AWS secret keys accidentally pushed to GitHub are abused within a few minutes. There's essentially no window where published keys remain safe.

That's for a public repo. I'd bet the vast majority of companies have private repos.

Code review is read only. Pair programming is at the same machine. Apart from that the features should be ultra-thin and delivered vertically end-to-end by a single programmer. That is the optimal model.

Optimal for what?

Reply on news.ycombinator.com