Comment by autarch | Hacker News Reader

Comment by autarch | Hacker News Reader

The author says:

> While I hesitate to say “Worrying about merge conflicts” is a valid reason not to pursue a branching strategy like gitflow

I do not hesitate! This is _very good_ reason to avoid gitflow.

Merge conflicts by definition require human intervention. And human intervention means an opportunity for human error. Resolving merge conflicts properly ranges from trivial to nearly impossible, depending on the specific changes you're trying to merge.

Often none of the authors involved in the conflict are in a good position to understand why it happened. One person makes a small bug fix change to a few lines of code. But that fix required hours of research and a solid understanding of the problem. Meanwhile, someone else is doing a refactoring of that same code in another branch, unaware of the bug.

Neither of these two people may be in a good position resolve the conflict. The bug fixer doesn't understand the refactoring, so they don't know how to apply the bug fix in the new code. The refactorer doesn't understand the subtleties of the bug fix and the code being fixed is just gone in the refactor. It's going to require the two of them working together to fix this, and it may took several more hours and they still may not get it right. And that's the best case! Realistically, one person will muddle through the merge and hope that things still work properly.

Of course, merge conflicts are a fact of life in _any_ version control scheme without exclusive locks (remember RCS?), but minimizing them is a very valid goal.

I don't just worry about merge conflicts. I worry about merges that generate no merge conflicts, but still create bugs because of the way changes on two different branches end up interacting with each other at run time.

In general, I feel a lot more confident with using feature flags and the like to keep work in progress from prematurely going live than I do using branches to do the job.

Or, if I could take a stab at saying it pithily: Having your code be continuously integrated is a prerequisite of doing continuous integration.

I think of those as "logical" merge conflicts, as opposed to "literal" merge conflicts, the kind detected by git. Having good integration tests is crucial!

I'm not sure feature flags fully solve this either since someone doing work on another feature is just going to ignore the path of a not ready flag.

No, it's certainly not perfect. But, not being aware of a solution that's perfect, I've had to content myself with something that's merely better than anything else I've tried.

At least they can see it, instead of the code being in an entirely different branch.

I generally like to have feature flags default to true in tests. It helps avoid this sort of situation, because if they ignore the flag, they’ve probably broken some tests. And if they only put it in the flagged path, their code won’t work in prod, but it probably won’t break anything either.

This is definitely my biggest worry, too, especially since we rarely have merge conflicts on our 6 person team.

Merge conflicts are rare for two major reasons:

1. We plan our changes to avoid the likelihood of merge conflicts. Specifically, we try to avoid two people working on similar areas of code at the same time. 2. We have functionality split into a fair number of different repos (though I probably wouldn’t call them microservices), which not only makes 1. easier, but simply reduces the chance of two people pushing commits to the same repo.

Part of 1. also involves giving slightly bigger pieces of work to a single developer, so that person can see it all the way through from the start. That way, there may not be as many short PRs that are quickly merged, but that developer can really wrap their mind around the complexity of the problem and hopefully have a higher quality functioning product at the end.

Of course, we also have our use cases reasonably solidified when we start building, since our company is over 8 years old and we take the time to know our customers’ desires fairly well (and are always learning more, or course!).

This is also a argument (among many) against rebase. There are a lot of automatic merges peppered in the history and you can track down the bug to an automatic merge (using eg git bisect) only if the history is preserved.

I don't see thus as an argument against rebase. In fact, rebasing your branch interactively allows you to examine the conflicts, if any, in the context of the feature branch and fix them. If you merge the base branch into your branch, you get a mix of changes that are hard to reason about in the context of your feature branch and the automatically generated commit message doesn't provide much information about what was done to resolve any conflicts.

On the other hand, its a lot easier to see if a conflict resolution attempt didn't work during a rebase because the individual commit diffs and the overall diff would make obvious (e.g., unrelated code in the master branch was changed out removed).

perhaps people do gitflow incorrectly? I've been using it for several years and, on teams of about 10-15 people, have rarely had merge conflicts. Feature branches should be short-lived and therefore avoid conflicts. Hotfixes pose a risk to conflicts, but that's their nature. Say you have bug in production code and you fix it via a hotfix and some other developer stepped on that code on the develop branch, you should have a human reviewing the bug fix's merge with the new feature in development.

I really didn't understand this post. To me, it seemed like someone writing a critical perspective of a process they don't fully understand. I know it's not because of a lack of documentation, git flow has been blogged about ad nauseam.

I have friends who use different branching strategies who complain constantly about the same pain points the author brought up. The only thing I agreed with the author with is to find a strategy that works.

Merge conflicts can be minimized, if not eliminated, by only merging branches back into develop via a fast-forward merge (and preserving the merge commit with the no-ff flag for the git merge command). The same thing should apply to merging develop into master.

That way, merge conflicts, if any, are limited to merges that involve porting bug fixes back to earlier released versions.

I find most merge conflicts are easy to understand if both authors work together to resolve it.

When I work together with people on projects, I make them to agree that nobody other than the author of commits is allowed to resolve merge conflicts, and conflicts must be resolved in the feature/pr branch that is going to be merged into the main branch(es)

I would agree that _most_ are easy. But the upper bound for difficulty to understand is quite high. And even if they are easy when both authors work together it'd be even better to _not_ spend two people's time on that. So why adopt a workflow that's guaranteed to maximize merge conflicts?

Reply on news.ycombinator.com