• CrypticCoffee@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    10 months ago

    Become a professional, then you’ll commit every time you make a small bit of functionality. If you’re doing massive changes like this, you haven’t broken something after multiple days of code enough. When you do that and you have no idea what you broke it with and when, it conditions you towards small iterable chunks.

    • Awkwardparticle@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      10 months ago

      I learned this the hard way, I forgot to commit for a single day and got burned really bad when my regression tests failed and I could not trace the issue(it is called source control for a reason). I declared it was more efficient to revert back to the last commit than spend time fixing broken code that I had no fucking clue where it was and the only thing I had to go by was that it happened between two commits with a whole work day between.

    • narc0tic_bird@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      10 months ago

      This. Instead of making commits time-based (for example once per hour or once per day), make them purpose-based (say, add a database migration in one commit, and change the color of a button in another one). This also makes it easy to cherry-pick or otherwise backport specific changes to different program versions gor example.