Hacker News Reader

I used to be a solid believer in merging and not rebasing, but then I had the chance of working on a project where rebase + fast forward only merges were the norm (with some additional rules), and I have to admit, it worked really well. I don't even remember any serious merge conflicts, and there were some really long lived branches there!

I usually can sell rebase+FF to a team by using rev-parse to revert a range of commits immediately without conflict.

It's a little more effort to get in the habit of, but it pays dividends.

> It always contains 100% of everyone elses code.

It contains no one else's code since everyone works on a branch. This is only holds if a single team uses a brach. That doesn't scale.

> It contains no one else's code since everyone works on a branch.

100% of everyone else's code that has made it to main.

If you need to coordinate more closely (i.e. different people working on related changes, which is likely to be common) then the branch doesn't have to be local and just for you, it can be shared, perhaps with individuals having their own local copy of that for quick check-ins¹ without publishing to others until ready². Whether this scales manageably will depend on the project and your team dynamics.

--

[1] to save work state before experimental changes, or just to have an off-machine last-known-good copy (assuming your “local” repo is covered by off-machine backups or is not actually local)

[2] though this indirection adds extra overhead – someone needs to rebase that from main then everyone may need to rebase to bring local copies in line

I feel it is likely to scale better than the alternatives, as it is a recursively hierarchical model of a recursively hierarchical problem. It would break if people are committing broken things, but then you have a different and more fundamental problem.

No one commits as they write each line of code. There's always code in flux and you are not integrating with everyone else every minute.

Branches vs. on-trunk misses the mark, IMO: the question is what's your practices like for how frequently changes get integrated. There's multiple dimensions of freedom in how you do things.

Branching is a nice tool to have.

Avoiding long-lived feature branches is best (particularly with a big subset of the team working in them). (But, dang, sometimes you need these abilities, too, so having a workflow that supports them well is good).

It contains 100% of everyone’s finished code and 0% of their unfinished code. Whether the amount of unfinished code is 1 hours worth or 1 weeks worth isn’t very interesting to me. It doesn’t matter if Bob was on holiday or if he has done 4/5 days of his big change. I just want a stable main.

The amount of in progress work acceptable will differ if you work on a 20 year old desktop app with quarterly realeases like me vs a startup with 6 weeks of runway left.

I would add code living on separate repos is also not integrated :)

I've had such headaches working across repos and having a "microrepo" organization scheme without thought to how these things are tested against each other.

At Airbnb in 2014 we hand internal NPM and Ruby Gem ecosystems published to internal package servers and integrated via version bumps and installs… so annoying to make a PR on foolib, test it a bunch, publish a alpha version” so I can install it in barlib* and test it there, and then need to make 2 PRs and do an official publish in between them.

Not to mention every repo might have a different dev experience, different ways to test, different everything. Just multiplies dev ex pain times number of repos.

I tend to view it like this too. I'm in control of the new feature on my branch, it's my responsibility to rebase to avoid a nasty merge, I can then run automated tests and I can push my work at a point where I'm ready in a set of logical and atomic commits.

I agree I think both have their pro's and con's. You can do trunk based development badly where your mainline is always broken, and you can do feature branching badly where you sit on a branch for months and then break the world when you merge.

I have not seen a lot of success with pull requests. Usually people just seem to say LGTM, then the original developer merges. That could just be the company I keep. Either way, I don't see them as a significant benefit of feature branches.

I'm not sure of the terminology as I've stepped away from development, but we used to work by the whole team working on a release branch, then merging to main at stable points. Maybe that gives the best of both worlds in terms of stable trunk and keeping continuous integration?

This is how my team does it.

If we have a large feature with multiple people pushing code, we’ll create a “feature branch” that we then branch against. We run our PR flow into the “feature branch” then merge the feature branch into main when ready.

As part of smaller features, people rebase from main and work upstream changes back into the feature branch. Worst case, we spend and hour near the end of the project on a “merge party” where we work out all of the conflicts.

You can do that with squash-merge.

But with squash you lose all of the individual commits.

That's a pros, not a con. Once something is merged, intermediary steps to get that new thing are no longer interesting. In fact, most rebase workflows squash anyway.

In the rare case you have 3 steps in that PR of 23 commits you want to keep, squash it in 3 pieces and merge them.

The catch is, does it have to be functional at every step? It may be hard to find checkpoints inside a PR where the changes still produce a useful (testable) product without breaking anything.

If it doesn't have to be testable in three pieces, then why break it down? For clarity when reviewing the changes perhaps.

The best reason to have it broken up is for posterity to be able to annotate the changes. If there is a 100 line refactor followed by the 10 line actual functional change, then it's a blessing to be able to look at that in isolation when something has gone wrong with it 5 or 10 years later.

Keeping the commit as the unit of change allows you to orchestrate with a single PR. The commit is the change, the PR is the go button.

> In the rare case you have 3 steps in that PR of 23 commits

I'd have 3 commits in this case.

It's not rare at all when you have code, charts, terrform, and scripts housed in a single repo. But even if you're just touching code some changes make sense to go out at the same time.

Personally, I feel that the use case for squash is when there are many WIP commits. Those could be avoided with the use of --amend, or --fixup, or cherry picking without a commit, etc.