Is it rude to create a sub-branch off of someone else's branch?

Question

I'm new to coding and collaborating in git so I thought this would be a relatively normal thing.

We're a small team of three working on a project. One of the team members is working on a problem branch and we were going back and forth over one functionality. They said I could take a shot at optimizing it so I created a sub branch and started working on it (without explicitly stating that I was making a sub). They then submitted a PR to main while I was doing that, so I fetched their changes into my and approved the PR. After I was finished, I submitted a PR for my sub into their branch and asked them to review.

They're now mad and saying that I shouldn't touch someone's code after they're done or ever branch off of someone else's work. I don't understand how this would make sense for a large scale project, but is that different in smaller groups? Or am I just completely off base here and should have clearly stated I was making a sub.

Really hoping to understand best practices because git is already enough of a nightmare for me without also being rude to others!

Sorry this isn't a pure programming question. If it breaks any rules I'll take it down!

Answer 1

It's not rude at all to branch off of other people's work! In fact, generally it might lean towards being more of a compliment than rude, since it implies it's useful to you and important enough that you wish to use it before it makes its way into the shared codebase. I think in most environments if you're trying to improve someone else's code, most people would thank you for it. (There could be exceptions, for example if the person thought you weren't helping and perhaps making it worse, or maybe if you added comments like "Fix some awful code")

Perhaps most importantly though, it doesn't really make sense for someone to be mad about this, since any commit you branch off of is someone's code. Consider:

1. Bob creates a Pull Request to merge feature/bob into main. Let's call the tip of feature/bob commit X.
2. Now suppose Bob completes the PR with a fast-forward merge. (GitHub doesn't support this directly in the UI but you can actually complete a GH PR with fast-forward from a client.)
3. Now both main and feature/bob are pointing to commit X. Had you branched off of X before Bob's PR was completed, your branch would have been the same, and indistinguishable from a branch that started from main after the PR was completed, since both are starting from commit X. Even if you didn't use a fast-forward merge in #2, you could just rebase your branch onto main after the PR is completed and it will look like you started from main.

The takeaway here is that it doesn't matter whether you branched off of someone's branch before the PR was completed, or from main after the PR was completed. Depending on the timing it's possible you won't even be able to tell the difference.

One thing I do find odd though, is that you created a PR of your branch into their branch, instead of main. In fact, the norm is to delete feature branches after they are merged into a shared branch like main since as shown in step #2 the branch (usually) has no value anymore once it's fully reachable by main. But even this shouldn't have been a cause for annoyance. The person you asked to review it probably should have suggested you change the target to be main instead of an old feature branch. (And perhaps been flattered that you were interested in working on their code.)