I think trying to avoid talking about SHA1s of content makes everything blurrier, not clearer. Because them people say things like this, which really don't make sense and instead seem like speculative SF:
> A commit is its entire worldline
Honestly, most Git problems I see stem from long-lived branches. Git flow is a common culprit.
It's not the same thing but Git Flow reminds me of Conway's Law. Just that the branches end up representing the dev-test-release workflow.
Another variation is that you reify branches according to whatever team that is working on it, like dev and qa and release. As in they have these literal branches and they need to follow a workflow diagram in order to remember what to merge into what and in what order. Then they mess something up and they go to StackOverflow to ask such easily inteligble questions like:
> We are using a standard branching model. But sometimes we find a bug in release/5613248 and need to deploy a hotfix. So naturally we branch hotfix/5613248 from release/5613248, fix the bug, do a PR against release/5613248/joe-the-gatekeeper, then Joe merges that into release/5613248 and also into pre-release/5613248, qa, and finally into develop. But sometimes we get weird merge conflicts when merging into for example qa or develop. How do we avoid that?
Well that clears it up! /s
I think trying to avoid talking about SHA1s of content makes everything blurrier, not clearer. Because them people say things like this, which really don't make sense and instead seem like speculative SF:
> A commit is its entire worldline
Honestly, most Git problems I see stem from long-lived branches. Git flow is a common culprit.