3 ms·

But a policy of squashing prevents two people from working on the same feature (you shouldn't squash what you've already pushed as this changes history).

newjersey 10y ago
I'll go further: never* rewrite public history *In most cases, I think we should consider invalidating secret keys instead of trying to delete it and hope nobody saw it. Are there secret keys in your app that you can't invalidate without a lot of pain? Maybe it is time to change some things in your app. Maybe if someone accidentally commits secret-evil-plan.txt you might want to rewrite history? I can't think of any other scenarios... I mean even if someone commits a secret key, you're probably better off revoking it and leaving the secret key there. Or should you delete that file anyway to prevent people trying to brute force your old revoked private key?
- eskimobloood 10y ago
  Depends on what is "public" history. Is a branch where you working on alone public, or does it become public after merging in back to master. Squashing a branch before merging back depends a lot of the discipline of the commiter. So for a branch with commits like "add FeatureX", "arg forgot this edge case", "ups another fix", "finally it works" it makes a lot of sense to squash it. While for "add FeatureX", "fix some linter errors during development" it makes then to leave the history as it is.
- JimDabell 10y ago
  > *In most cases, I think we should consider invalidating secret keys instead of trying to delete it and hope nobody saw it. Absolutely. AWS secret keys accidentally pushed to GitHub are abused within a few minutes. There's essentially no window where published keys remain safe.
  - planteen 10y ago
    That's for a public repo. I'd bet the vast majority of companies have private repos.
qertoip 10y ago
Code review is read only. Pair programming is at the same machine. Apart from that the features should be ultra-thin and delivered vertically end-to-end by a single programmer. That is the optimal model.
- fdgdasfadsf 10y ago
  Optimal for what?

newjersey 10y ago

I'll go further: never* rewrite public history *In most cases, I think we should consider invalidating secret keys instead of trying to delete it and hope nobody saw it. Are there secret keys in your app that you can't invalidate without a lot of pain? Maybe it is time to change some things in your app. Maybe if someone accidentally commits secret-evil-plan.txt you might want to rewrite history? I can't think of any other scenarios... I mean even if someone commits a secret key, you're probably better off revoking it and leaving the secret key there. Or should you delete that file anyway to prevent people trying to brute force your old revoked private key?

eskimobloood 10y ago
Depends on what is "public" history. Is a branch where you working on alone public, or does it become public after merging in back to master. Squashing a branch before merging back depends a lot of the discipline of the commiter. So for a branch with commits like "add FeatureX", "arg forgot this edge case", "ups another fix", "finally it works" it makes a lot of sense to squash it. While for "add FeatureX", "fix some linter errors during development" it makes then to leave the history as it is.
JimDabell 10y ago
> *In most cases, I think we should consider invalidating secret keys instead of trying to delete it and hope nobody saw it. Absolutely. AWS secret keys accidentally pushed to GitHub are abused within a few minutes. There's essentially no window where published keys remain safe.
- planteen 10y ago
  That's for a public repo. I'd bet the vast majority of companies have private repos.

qertoip 10y ago

Code review is read only. Pair programming is at the same machine. Apart from that the features should be ultra-thin and delivered vertically end-to-end by a single programmer. That is the optimal model.

fdgdasfadsf 10y ago
Optimal for what?