Adam-Kay / Batch-Encoder

Command line batch file encoder using FFmpeg
GNU General Public License v3.0
0 stars 0 forks source link

Revision to how Pull Requests are opened #28

Closed Adam-Kay closed 11 months ago

Adam-Kay commented 11 months ago

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:

  1. Needs multiple commits to complete (in this case, I think more than 2)
  2. Has intermediary steps that could be code-breaking

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.

Adam-Kay commented 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.

Crude graph:

             v1.5.0      v1.5.1                      v1.5.2
                |           |                           |
main         —— ● ————————— ● ————————————————————————— ● ——
               /           /                           /
dev        —— ● ——— ● ——— ● ——— ● ——————————————————— ● ——
                                 \                   /
adding-colors                     ● ——— ● ——— ● ——— ●
Adam-Kay commented 11 months ago

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.