4 ms·

This assumes that people work in logical, sequential chunks. I don't. I do a little here, a little there, and then it all starts to form the larger picture.

ricardobeat 4y ago
Not necessarily, I don't think anyone works linearly, but you can still keep your commits organized. I might have 25 dirty files and a bunch of WIP commits; when I'm done I will reset everything, and take the time to stage them one by one (or `git add -p`) into commits that make sense, and will help a reviewer understand what's happening. It's worth the extra few minutes. For a more concrete example, say you're adding a new screen to a mobile app, I'll probably split into chunks like these: - add new `/foo` endpoints to API - add `NewScreen` (can be reviewed as a feature, does the screen contain / do what it's suppose to) - add `NewScreen` to navigation stack - link to `NewScreen` from settings page - add tracking for `NewScreen` Each of these have very different purposes, and I find being able to focus on the different aspects (business logic, infrastructure stuff, analytics) helps a lot. They can also be reverted cleanly if needed without destroying all of the work. You can still review the entire PR at once, with the option to drill down into individual commits if desired.
- masklinn 4y ago
  Assuming your original commits are atomic but not complete (that is each feature / chunk of work is spread over multiple commits as you changed things up or fixed things you’d forgotten) `rebase -i` might be significantly superior to resetting and redoing everything by hand.
  - deleted 4y ago
    [deleted]
Juliate 4y ago
That's why working on a branch, and once ready, taking the time to reorganize your commits into logical steps, is a basic act of kindness towards the people who will review your changes, and towards your own future self.
xboxnolifes 4y ago
You don't need to work in logical, sequential chunks. You just should organize the work after the fact before making the PR. I work the same way.

ricardobeat 4y ago

Not necessarily, I don't think anyone works linearly, but you can still keep your commits organized. I might have 25 dirty files and a bunch of WIP commits; when I'm done I will reset everything, and take the time to stage them one by one (or `git add -p`) into commits that make sense, and will help a reviewer understand what's happening. It's worth the extra few minutes. For a more concrete example, say you're adding a new screen to a mobile app, I'll probably split into chunks like these: - add new `/foo` endpoints to API - add `NewScreen` (can be reviewed as a feature, does the screen contain / do what it's suppose to) - add `NewScreen` to navigation stack - link to `NewScreen` from settings page - add tracking for `NewScreen` Each of these have very different purposes, and I find being able to focus on the different aspects (business logic, infrastructure stuff, analytics) helps a lot. They can also be reverted cleanly if needed without destroying all of the work. You can still review the entire PR at once, with the option to drill down into individual commits if desired.

masklinn 4y ago
Assuming your original commits are atomic but not complete (that is each feature / chunk of work is spread over multiple commits as you changed things up or fixed things you’d forgotten) `rebase -i` might be significantly superior to resetting and redoing everything by hand.
- deleted 4y ago
  [deleted]

Juliate 4y ago

That's why working on a branch, and once ready, taking the time to reorganize your commits into logical steps, is a basic act of kindness towards the people who will review your changes, and towards your own future self.

xboxnolifes 4y ago

You don't need to work in logical, sequential chunks. You just should organize the work after the fact before making the PR. I work the same way.