working on sketching a few different git workflows I've seen people use. what am I missing?
(I'm less interested in minor variations on these like how you manage tags or the exact details of how the feature branches work and more interested in completely different workflows)
@b0rk sometimes I am working on a big thing and I want to break it up for easier review/ testing/ sharing so I have feature branch xxxx and then feature branch xxxx+yyyy that depends on xxxx. I want this to work but it inevitably leads to rebase hell
@b0rk The "we all send patches to a single list and the maintainer merges them into the main branch" flow is missing. It probaby wouldn't scale to something as big as the Linux kernel, but most projects never have to worry about "too many contributors".
@b0rk the linux kernel is kinda the first three plus the release branch model, for that reason I tend to call the abstract model the "monotree with multiple repos" approach to git
one that I think you're missing is the multi-repo approach, where you have a pile of git repos (each can work with one of the other models), and then an integration repo that links it all together and picks specific versions of each component. android works like that, and git supports this flow with git submodule
@b0rk that view of Linux development model is simplified too much I think, it is an interesting case of "vendor branches" where someone (a CPU or device manufacturer) will maintain their own version of Linux with patches to support their own hardware, and s%nchronize with upstream Linux (by merde or rebase) from time to time
This exists in other projects as well, for example I worked on several private forks of wireshark adding custom protocols to it this way, gcc branches to add a new CPU, …
@b0rk I'm a little confused, release branches fall behind the dev branch so wouldn't the timeline look like [dev] <- [release 2] <- [release 1]? Hotfixes would be merged into dev and [release X] with feature branches only merging dev back in periodically?
@b0rk Something I've encountered quite a few times: Feature branches + long lived version branches. The version branches get bugfixes and patch releases. Occasionally also new features (🤮). Older versions with fixes might be merged into newer versions.
@b0rk It can lead to difficult merge conflicts, but customers in some industries really hate change, and this is one way to protect them from change as much as possible.
@b0rk gitworkflows(7) is related to panel 4, but unique in that 'next' is discarded after every release. It's a good model when your automated test suite is incomplete so you need a way to get user testing on things before they graduate to main. https://git-scm.com/docs/gitworkflows
@b0rk git.git has a branch it rewrites frequently that merges together all the proposed changes to its main branch, for review & testing ("seen")
It also has a completely unrelated branch (no common ancestor with the main branch) ("todo") with release notes and info about known branches in progress
It has also merged with outside projects and thus has multiple root commits (Git has 7 from the master branch)
@b0rk Just writing in support of including the "all to/from main, tiny project" version. This may be a perversion of the git system but it is by far & away the most common use of it for me, where I am all three users consecutively: on my dev box, testing server, laptop.
@b0rk For most projects I'm on, we do release branches only - e.g., 0.1.x, 1.2.x, 2.3.x. We tag from these, and create a new release branch for next minor or next major when we want to land new features or BC-breaking changes.
This has another benefit: we target security fixes at the oldest supported release branch, and then merge up, tagging as we go. This tends to be easier than backporting patches.
@b0rk The last few cos I worked at were cloud startups whose products you’ve probably used, and they used pretty much the same flow: same as your GitHub-based feature branch workflow, but release branches are cut from the tip of main shortly before deploys to each environment (staging, prod, etc). This is mostly to ensure that you can do hotfix cherry picks if something breaks. Since all environments are cutting from main, the gap between staging and prod is generally pretty limited.
@yorgos@radicle that's really cool! i'm more curious about the social structure of a totally decentralized project than the technical structure though -- like I can't think of any projects that don't have a “main" central distribution
(like I'm sure lots of organizations maintain forks of the linux kernel, but I wouldn't say that they're peers of the official releases)
@b0rk@radicle yes, I think there is always a need for a “canonical” main, so new users don’t have to fully grasp the governance model in order to read the code / contribute.
By “governance model” I basically mean the workflow process by which code gets merged to the canonical main branch.
Technical differences of a p2p network like #radicle aside, I think the same social structure is in projects that request X reviewers (from Y different orgs) to approve before merge.
@b0rk Everybody sends me patches on the mailing list, in "git format-patch" format if they want metadata, and when they do a GitHub pull request instead I add ".patch" to the pull request URL and wget it. Then I "git am" it locally.
I believe my repository has one accidental merge in it something like 8 years ago.
Add comment