
GitHub Protips- Tips, tricks, hacks, and secrets from Sarah Vessels - joeyespo
https://github.blog/2020-05-21-github-protips-tips-tricks-hacks-and-secrets-from-sarah-vessels/
======
luhn
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.

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

------
perfectstorm
I like this approach but I'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'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.

That being said, I can't think of any elegant ways to solve this.

------
mleonard
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!

~~~
DerArzt01
Cli aside there are some good tools out there that let you do this with a gui.
I personally like GitKraken.

------
aurbano
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...

Although it has a great side effect of forcing atomic commits.

