Talk:Branching and Version Control: Difference between revisions
| Line 10: | Line 10: | ||
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: | 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) | 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’ve adopted this approach | 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/. That may be the first point of discussion. | |||
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. | |||
Finally, “merging main regularly” is incorrect; of course, you need to rebase the working branch onto main. | Finally, “merging main regularly” is incorrect; of course, you need to rebase the working branch onto main. | ||
Revision as of 06:31, 1 September 2026
[CodeHD] 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]
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/. That may be the first point of discussion.
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.
Finally, “merging main regularly” is incorrect; of course, you need to rebase the working branch onto main.