GitHub Protips- Tips, tricks, hacks, and secrets from Sarah Vessels

The crux of this is that PRs should be small. The larger a PR is, the harder it is to work with: more difficult to review, riskier to merge, and more likely to conflict with somebody else’s work. Making PRs as small as possible (but no smaller!) helps avoid this. The author gives a good example of taking a large task and breaking it into small but fully formed units.

I usually do this kind of thing by making a new branch and interactive rebasing. Generally works well for me too!

I like this approach but I&#x27;m not entirely sold on it. In her example, the `category-validations` is branched off from `category-db` and there will be two separate PRs. If you start receiving reviews for `category-db` PR and you make those changes then you&#x27;ll have to rebase it onto the `category-validations` and resolve any conflicts. This will be many times harder if a different developer works on `category-validations` branch.<p>That being said, I can&#x27;t think of any elegant ways to solve this.

If anyone has the time and git skills to post the detailed git commands necessary for this type of workflow I (and I think others) would appreciate it!

In a way I like the approach, and I guess I’d have to try it to actually fet a feel for it because it seems to introduce a ton of additional work figuring out sane ways to split the code in branches...<p>Although it has a great side effect of forcing atomic commits.