Talk:Branching and Version Control

[CodeHD][26-08-31] First round of commenting:

• Preliminary considerations look good to me. Not sure the aspects about PyPI will/should really matter in the end, but no harm done in writing them down.
• In terms of the suggested branching: Previously we had talked about different concepts.
  • what remains identical/similar is having branches like feature/*, etc. In terms of actual branch names, I don't personally care. "Chore" I did not see in guides before, we should add some descriptions of purposes.
  • Different is that we previously talked about separate release preparation branches. I think release processes are still missing as a general category.
  • I am fine with the desciption of main. Essentially, it would remain as-is, i.e. the default branch on GitHub protected against force-push.
• On long lived branches, your speak of "merging main regularly". I suppose this is supposed to say "rebase"? Otherwise I would expect extra trouble when we work on multiple long-lived branches in parallel which will be merged at different times.

[Howetuft][26-09-01]

Building the Proposal

Since you rightly point out that some points from our preliminary discussions may not have been included verbatim here, just a quick note on the method:

To arrive at this proposal, I conducted as comprehensive a review as possible of the various standard strategies that exist, so as not to reinvent the wheel (here, for instance: https://dev.to/karmpatel/git-branching-strategies-a-comprehensive-guide-24kh).

I tried to take into account the points we discussed, and I also consulted an AI. After all that, what seems to best fit our parameters—particularly team size, the emphasis on bug fixing over long-term features, etc.—is Trunk-Based Development: https://trunkbaseddevelopment.com/.

The strategy is very similar to what we do, as evidenced by the many points of agreement you've pointed out. However, it has an overall coherence that may cause it to differ slightly in certain details from what we had discussed.

The choice of the underlying strategy may be the first point of discussion.

Detailing

Once I’ve adopted this approach, I've highlighted a few key points, though not all of them (since the specification is quite extensive). You’re right, though — the release process is missing, and it’s crucial. I’ll add it.

Typos

Finally, you're right, “merging main regularly” in working branches is incorrect; of course, we need to rebase the working branch onto main.