4 ms·
GitHub Protips- Tips, tricks, hacks, and secrets from Sarah Vessels
- osdiab 6y agoI usually do this kind of thing by making a new branch and interactive rebasing. Generally works well for me too!
- mleonard 6y agoIf 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!
- luhn 6y agoAFAICT she’s not using anything besides basic branch management and cherry-pick. I think having a decent grasp of interactive rebase would help with this flow, but not strictly necessary and author doesn’t mention it.
- DerArzt01 6y agoCli aside there are some good tools out there that let you do this with a gui. I personally like GitKraken.
- aurbano 6y agoIn 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.
- luhn 6y agoThe 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.
- perfectstorm 6y agoI 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.