Branching from origin/master vs branching from local master

Question

Assuming we have a remote repository and we clone it locally.

We checkout a master branch so now we have the local master and a remote remotes/origin/master.

I then have to create a new topic branch that will be merged into the remote master once reviewed:

What are the pros and cons of branching from the local master vs the remote equivalent (if there is any difference)?

Do the same arguments apply to long running branches?

EDIT:

I have been trying to track origin/master for my local branches and I noticed a big downside: on TFS it doesn't let you create a pull request. If you want one, you need to push your branch to origin and this will detach it from master and it will track the new remote branch and then create a pull request; is there anything wrong in what I stated? If not, then this is a big reason not to branch from origin/master.

Answer 1

Assuming that master is up to date with its remote tracking branch origin/master, there is no actual difference at all.

Branches are just pointers to commits in the history, so when branching off one branch, you are just creating another pointer that points at the same target. That pointer has no relation to the “original pointer/branch”; it only points to a commit. So when you continue working on that new branch, new commits will only reference the base using the parent relationship of commits. The branches itself are completely irrelevant to the history.

Git has a way to add some kind of metadata to branches. However, the standard branching mechanisms, e.g. using git branch or git checkout -b, will not make Git append any additional metadata to the branch.

The only relevant metadata would be the remote tracking branch. But usually, you wouldn’t want to have more than a single branch track the same upstream branch.

So in your case, when you are creating a feature branch or something, just branch off master, or origin/master. It doesn’t really matter.