> > That means it is not in general possible to tell which branch a particular commit belongs to.
>
>That's because commits can belong to multiple branches, which is by design.
I could be wrong, but I think what they mean is the fact that once you merge/rebase your dev branch back into master, all of those commits you made in dev are now commits in master.
You could conceivably have a source control system that still allows commits to belong to multiple branches, but bakes the branches of a commit into the commit. (And I believe many/most other source control systems do just that.)
The fact that the branches of a commit can change later on always struck me as being completely inconsistent with the commonly held idea about git that outside of master it's ok to forego testing. That really only works if you squash into master (and test that squash commit). If you don't squash, and especially if you fast-forward, then all of those commits are now "in" master, and so you've dumped a bunch of untested stuff in master.
I could be wrong, but I think what they mean is the fact that once you merge/rebase your dev branch back into master, all of those commits you made in dev are now commits in master.
You could conceivably have a source control system that still allows commits to belong to multiple branches, but bakes the branches of a commit into the commit. (And I believe many/most other source control systems do just that.)
The fact that the branches of a commit can change later on always struck me as being completely inconsistent with the commonly held idea about git that outside of master it's ok to forego testing. That really only works if you squash into master (and test that squash commit). If you don't squash, and especially if you fast-forward, then all of those commits are now "in" master, and so you've dumped a bunch of untested stuff in master.