`git push -f` and solipsistic shared reality; when you `push -f` everyone gets to vote on what chain of commit hashes is the real ${orgname}/${reponame}//${branch}
There is no formal consensus mechanism beyond push permission in git itself; and so what would be regressive centralization of technically decentralized [git] in order to enforce directory-level permissions like e.g. CODEOWNERS is actually necessary for quality control.
Eventually, Github and Gitlab integrated code review like ReviewBoard and Gerrit (instead of mailing list patchbombs and quilt); and code review approval from zero one or more authorized reviewers is now an optional necessary precondition for merging to a git branch as a social construct.
DevSecOps says,
Pull Requests (or Merge Requests) are merged only when (1) all of the automated tests pass; and (2) enough necessary reviewers have indicated approval.
Git doesn't tell you when it's necessary to have full test coverage and manual infosec review in development cycles that produce releases, and neither do Pull Requests.
It looks like datasift's gitflow/hubflow docs are 404'ing, but the original nvie blog post [1] has the Git branching workflow diagrams; which the wpsharks/hubflow fork [3] of datasift/gitflow fork [2] of gitflow [1]has a copy of in the README:
There is no formal consensus mechanism beyond push permission in git itself; and so what would be regressive centralization of technically decentralized [git] in order to enforce directory-level permissions like e.g. CODEOWNERS is actually necessary for quality control.
Eventually, Github and Gitlab integrated code review like ReviewBoard and Gerrit (instead of mailing list patchbombs and quilt); and code review approval from zero one or more authorized reviewers is now an optional necessary precondition for merging to a git branch as a social construct.
DevSecOps says, Pull Requests (or Merge Requests) are merged only when (1) all of the automated tests pass; and (2) enough necessary reviewers have indicated approval.
Git doesn't tell you when it's necessary to have full test coverage and manual infosec review in development cycles that produce releases, and neither do Pull Requests.
https://westurner.github.io/hnlog/#comment-19552164 ctrl-f hubflow
It looks like datasift's gitflow/hubflow docs are 404'ing, but the original nvie blog post [1] has the Git branching workflow diagrams; which the wpsharks/hubflow fork [3] of datasift/gitflow fork [2] of gitflow [1]has a copy of in the README:
[1] https://github.com/nvie/gitflow
[2] https://github.com/datasift/gitflow
[3] https://github.com/wpsharks/hubflow?tab=readme-ov-file
https://learngitbranching.js.org/ is still a great resource, and it could work on mobile devices.
The math of VCS deltas and mutable and immutable content-addressed DAG nodes identified by 2^n bits describing repo/$((2*inf)) bits ;
>> "ugit – Learn Git Internals by Building Git in Python" https://www.leshenko.net/p/ugit/
SLSA.dev is a social construct atop e.g. git, which is really a low-level purpose-built tool and Perl and now Python porcelain.
jj (jujutsu) is a git-compatible VCS CLI: https://github.com/martinvonz/jj
"Ask HN: Best Git workflow for small teams" (2016) https://news.ycombinator.com/item?id=12941997
How much social construct atop git is necessary for e.g. the CPython project?
Python Devguide > Getting Started > [ Git bootcamp and cheat sheet , Lifecycle of a pull request ] https://devguide.python.org/getting-started/
Python Devguide > Development workflow > Development cycle > Branches: https://devguide.python.org/developer-workflow/development-c... :
> [ In-development (main) branch, Maintenance branches, Security branches, End-of-life branches ]
Git branches have lifecycles.