3 ms·

I prefer to squash away commits that leave the code in a non-working state. Because it makes using git bisect easier later if you need to find a commit that bro

• TeMPOraL 7y ago
  A habit I learned when working with SVN-versioned project is to never commit code in a non-working state. There's rarely ever a reason to, if you're thoughtful about your work. With completely new code, you just keep it disconnected from the main product and then you only have to ensure it compiles. With changes, you make them incrementally. Even large-scale changes can be done without breaking commits this way.
  • detaro 7y ago
    So don't commit code before it's gone through automated CI testing, codereview and QA? Or never make mistakes that require any of those to catch them? (At least before CI, it might not even compile correctly everywhere) Git can easily handle getting rid of or modifying commits, so why not make use of that ability in a controlled manner? I.e. I'd typically not re-build the history of the master or another major branch just to fix a bug introduced a while back at the source (although I guess backporting fixes might be similar). But for work in progress, one or a few commits about to be merged, smaller fixes are better made at the source. Not to talk about entirely irrelevant commits like "it's the end of the day, let's commit and push to a branch so it's not just on my machine".