There is a set of code changes locally and those changes are bundled off to the test server to run the full test suite? That's a branch.

Now let's say I break a project sharing this code and because I'm not an expert in all 2 billion LoC and 3000 projects google is running I need to enlist some help in fixing what I broke. Presumably there is a way for the developers on that downstream project to pull in my change set? That's a shared branch.

Now assuming I can get all of these planets aligned correctly I'm going to need to take this set of changes and put it into the master version aren't I? That's merging my branch into trunk.

Your mental model of how this works within Google is completely foreign to me. I think you've made an unfounded assumption somewhere.

Yeah that second thing doesn't exist. That first thing doesn't really exist the way you conceptualize either, I don't think.

Can anyone articulate how it does work and where I'm going wrong then? The conversations feeling pretty one sided here.

You said the first thing doesn't exist? Do you not have local changes or are these changes not shared with the test/build server? Having a set of patches, code changes, whatever sounds like a branch to me, are you being too literal with the word branch?

For the second part what doesn't exist? Do you not make changes that breaks other peoples code? Do you not get them to help fix it? Can you not share your work in progress changes with others? Can you goes collaborate on changes at all?

I can try. I think people are averse to doing this because it can sort of require a deep dive into how Piper and Citc work, and the linked article does a good job of explaining that, and beyond what the article says, its not clear what you can discuss.

[Everything I'm about to explain is for the average user's workflow, like others have mentioned, "real" branches do exist, but most engineers will never use them, and my current workflow works differently than what I'm explaining, but I used to do it this way.]

Piper generally speaking doesn't have the concept of commits or "sets of patches". You have clients. A client trunk@time + some local changes. You could maybe call this a branch, but you can't stack multiple commits[1], so its a branch of length exactly one. It can only be merged back into trunk. Then you delete the client and start a new one. You can patch changes from one client into another, but this isn't generally done or super useful because again, you can't stack changes.

A given client has an owner, and the owner has write access. Everyone else has read access.

So to answer your questions:

>Do you not have local changes or are these changes not shared with the test/build server?

There are local (sort of) changes. And you can test/build them, but they lack many of the concept one would expect of a branch, so I'm not sure that's a good name for them.

>Do you not make changes that breaks other peoples code?

Sure you do. But you're responsible for fixing it (as I said elsewhere).

>Do you not get them to help fix it?

Yeah, but normally this is done by having them review the change, or talking in person. There's nothing like multiple commits by multiple people which are then squashed and merged.

>Can you not share your work in progress changes with others?

Sure, but they can't edit them.

>Can you goes collaborate on changes at all?

Kind of, but not with multiple authors.

[1]: There's a hack that allows chained CLs, but its a hack, a leaky abstraction, and still doesn't provide multiple authors squashing and merging.

Google internally has many concepts of branches. What you describe is not any of them.