3 ms·
> having everything squashed into one commit can be annoying if the commit is too large, because it can be hard to identify why a specific change was made via g
by someweirdperson 4y ago
> having everything squashed into one commit can be annoying if the commit is too large, because it can be hard to identify why a specific change was made via git blame.
Maybe it should be split into individual PRs. If there's dependencies between the changes there's tools to support stacked changes.
- chrsig 4y agoas with all issues, it depends :) I've been struggling with finding the sweet spot between number of pull requests and size of pull requests. The pipeline on my primary project takes an annoying amount of time to complete, ~30 mins or so if things go smoothly. It sounds like a lot, but it's got a very comprehensive set of tests. When PRs are too granular, the merge/rebase/test pipeline/merge cycles can be quite time consuming. Admittedly, I don't use stacked changes. They're something I only learned about somewhat recently, and haven't yet incorporated into my development cycles. Can you recommend any resources?