Closed Adam-Kay closed 11 months ago
as pushing a code-breaking commit will lead to the whole repo failing its action
This could also be mitigated by adding a dev branch and merging it in with new features, and doing other branches where necessary.
v1.5.0 v1.5.1 v1.5.2
| | |
main —— ● ————————— ● ————————————————————————— ● ——
/ / /
dev —— ● ——— ● ——— ● ——— ● ——————————————————— ● ——
\ /
adding-colors ● ——— ● ——— ● ——— ●
This comment explains that the idea in the comment above is something akin to Gitflow, which is a legacy workflow and has largely been abandoned in favor of trunk-based development:
that said if it's a personal project it could only really hurt one person. best to just stick to
main
and branch off for larger features or refactors, IMO.
Which is sorta what I was doing already. So essentially, do:
v1.5.0 v1.5.1 v1.5.2
| | |
main —— ● ——— ● ——— ● ——— ● ——————————————————— ● ——
\ /
adding-colors ● ——— ● ——— ● ——— ●
Edit: I'm still doing PRs for feature branches though, like the hypothetical adding-colors
. It lets me put down notes, comments, and ideas about that feature there, and I'm making another branch anyway so it's not that much of a hassle.
Improvement Description
Based on light research, it seems generally agreed upon that PRs are useful to open if there is a feature being implemented that either:
The most recent feature addition for
v1.5.1
(Colors) which had 6 commits in total (from 0763cbc81456b7c3ee98e24acf31b43600b116d2 to 04f1bd4be398e1784a374e65fb0af7e13e76f525) should have qualified for this under these parameters, and should have likely had its own branch + PR for better documentation.This becomes more paramount once Actions (#21) are implemented, as pushing a code-breaking commit will lead to the whole repo failing its action - meanwhile a PR has an opportunity for review with those same actions before branches are merged in.