3 ms·

I have been using that in every branch: I commit regularly and end up with 10+ commits. Then I rebase + squash them and at the same time write a summary commit

I have been using that in every branch: I commit regularly and end up with 10+ commits. Then I rebase + squash them and at the same time write a summary commit. Eventually I merge. This has multiple good effects. First, you get a clean, featured-based history. Secondly, although your commit message is the one you wrote when you rebased, you can keep the old commit messages and you get a better summary of what happened during the development process of that branch.

AstralStorm 9y ago
Why have a history then at all? The idea is not to squash history but make it reasonable chunks. Remove chaff so to speak while keeping the general history. A single feature is very rarely a reasonable chunk. (For example, see Linux kernel patch series per feature.) Otherwise you may lose the "why" unless code is extremely well commented and that never happens.
- joshschreuder 9y ago
  Not the OP but with my own personal usage, sometimes I'll end up with multiple related commits where I've had to go back and fix a test or correct an issue I missed with an earlier commit. Therefore I commit and squash that into the earlier commit with related changes. I don't buy that every change should be a separate commit - if changes are related and the commit message covers the changes it makes sense to squash. Not sure if OP is talking about squashing all commits into one. I have seen people do this and I'm always a bit confused why, similar to your point.
- vasilakisfil 9y ago
  ok depends on the size of a feature I guess but usually I sit in a branch for 2-3 days before I finish the feature. Also what's the point of preserving the history of a branch that is used for the development of a requested feature ? For each commit before the final, the feature is incomplete, possibly not working at all.
  - AstralStorm 9y ago
    Not everyone is a believer in shippable increments, but it is a good practice nonetheless. (not necessarily fully working) Splitting per feature is indeed ok if it is small including effects on dependencies. But in my practice there are rarely small enough features - these map to something akin to user stories which have to be further broken down.

AstralStorm 9y ago

Why have a history then at all? The idea is not to squash history but make it reasonable chunks. Remove chaff so to speak while keeping the general history. A single feature is very rarely a reasonable chunk. (For example, see Linux kernel patch series per feature.) Otherwise you may lose the "why" unless code is extremely well commented and that never happens.

joshschreuder 9y ago
Not the OP but with my own personal usage, sometimes I'll end up with multiple related commits where I've had to go back and fix a test or correct an issue I missed with an earlier commit. Therefore I commit and squash that into the earlier commit with related changes. I don't buy that every change should be a separate commit - if changes are related and the commit message covers the changes it makes sense to squash. Not sure if OP is talking about squashing all commits into one. I have seen people do this and I'm always a bit confused why, similar to your point.
vasilakisfil 9y ago
ok depends on the size of a feature I guess but usually I sit in a branch for 2-3 days before I finish the feature. Also what's the point of preserving the history of a branch that is used for the development of a requested feature ? For each commit before the final, the feature is incomplete, possibly not working at all.
- AstralStorm 9y ago
  Not everyone is a believer in shippable increments, but it is a good practice nonetheless. (not necessarily fully working) Splitting per feature is indeed ok if it is small including effects on dependencies. But in my practice there are rarely small enough features - these map to something akin to user stories which have to be further broken down.