Hacker News Reader

Comment by lars | Hacker News Reader

I think this practice tends to encourage merging code later rather than sooner, which has caused more problems in code I've worked on than anything else. With N developers, you may end up with N or more increasingly diverging branches. If feature A and feature B subtly breaks one another, neither developer A or B will catch this problem until both branches are merged into master, at which point both developers are probably convinced their code works, and may have moved on. If they had worked on the same branch, the problem would have been apparent from the moment the code was written.

View on HN

Nope, it encourages merging in your own playground, incrementally. You can (and arguably should) still merge mainline into your branch with some regularity, say once a day.

With the issue you're talking about, that's why we have staging environments. If you're going to release A and then B, you should be staging A, and then staging A+B. It's true that if they had ZERO idea on what the other were doing, they could step on each other's toes. But it will get caught before release. And hopefully there's enough communication to at least have a vague idea of who's working on the same parts of the code as you. If you're designing things that span large parts of the codebase without consulting or warning teammates, you have bigger problems.

Without distinct feature branches, you end up in abysmal horror situations where you push something, realize you have a bug in production, but can't roll it back without rolling N other features back. Then you start hacking in code to turn the feature off temporarily, etc, which rapidly turns into a mess.

So in this model, what is the right way to merge mainline into your branch? Is it "git pull upstream mainline" while in your branch or something else?

Create A+B integration branch, then merge in both directions, A -> A+B then A+B -> A (to pick up changes from B). Integration branch can be tested and merged to master later instead of individual branches A and B. It's not that complex as it sounds.

Probably too late to get another reply, but I'll ask anyway..

I'm thinking about the scenario where you create a branch to do some dev work. It takes a week or so, during which, other commits are happening on master. Probably at multiple points during your week of dev work, you are going to want to pull in updates from master to make sure you don't hit conflicts or run into issues that weren't found until the day you try to merge your final work.

It sounds like you are saying that every time you want to update, you'd create a new integration branch of your work + master and then switch to that for further work until you are finally ready to commit to master? That feels a bit unwieldy..

Branch A and B can merge in from mainline every hour, but you wont catch problems with A+B until either is merged _into_ master.

Yes, you can catch the problem in staging, but you might have caught it before that if you had merged earlier.

> Without distinct feature branches, you end up in abysmal horror situations where you push something, realize you have a bug in production, but can't roll it back without rolling N other features back.

I don't think having a dev branch in an unshippable state is an abysmal horror situation. And even if you use feature branches for everything, that does not mean you can necessarily roll back the commits easily.

As someone new to large-scale DCVS usage, what do the remote repositories look like in a scenario like this?

Do the developers of feature A and B push their respective feature branches to a repo in the staging environment where they are merged in some local integration branch there? Logistically, who does the merging? Is it this integration branch that is then merged into mainline?

But you can't actually 'work on the same code'. You have to have a copy. And some projects are significant, not committed in a day or two. SO merging is a fact of life.

And in an open-source community, as you rightly point out, nobody wants to do the dirty work. And merging is as dirty as it gets.

> But you can't actually 'work on the same code'. You have to have a copy.

Surely this is a little overly pedantic? The point is that you want developers A and B to work on code bases that are as close to each other as possible, so that any problem in the interaction between these developers' work is caught early. Your project doesn't need to be completed in a day or two, you just need to accept that you have a dev branch which isn't always in a shippable state (which I think is usually unproblematic).

Which begs the question: which branch? How do you know what all the others are working on, and if you'll conflict.

If they work on the same branch, what happens if A finishes early and B is late, or abandoned as a bad idea?

Instead, A and B should be on separate branches. Maintain integration environments where the feature branches are regularly merged together when each gets to the level of doneness that environment represents. The final step is to get promoted to master-candidate, where you are going to launch tomorrow unless we find a problem. If things break there, blow that away and recreate it from master, and fix your problems one integration environment lower.

> what happens if A finishes early and B is late, or abandoned as a bad idea?

In those cases, you have to fix the code base, and git wont help you. In my experience, it is much less common to have code that needs to be removed than to have bugs that were introduced because the code bases were synced too late. How much of a problem this is depends on how flexible your release cycle is.

Reply on news.ycombinator.com