• @[email protected]
    link
    fedilink
    37
    edit-2
    6 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.

    • @[email protected]
      link
      fedilink
      76 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.

    • @Awkwardparticle
      link
      36 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.

      • @wulrus
        link
        16 months ago

        I work a lot with the local history of the IDE, where I can also set labels to a current state. In addition, it creates its own labels like last time all tests were green etc.

        Still, in one of my last project that really lived TDD, they made a good point that I should just push as often as I label, since that also triggers all sorts of other tests which I usually don’t run locally, or not as often.

        I had “rearrange code” checked once for a commit, and fortunately, it had automatically saved the exact state before that.

  • Miku Luna \ she/it
    link
    fedilink
    136 months ago

    Me when I don’t know at how many changes I should commit (the previous commit changed 2 characters):

    • @[email protected]
      link
      fedilink
      36 months ago

      For real, or when you should make the first and second commit.
      Or worse, when you’re too focused and start making a ton of changes, then you realize you haven’t committed anything. Discovering I can stage ranges has made me fall for this way too many times, because I think I’ll easily just go back and extract one atomic change at a time later (spoiler: it won’t be easy ( ; ´ Д `))

    • @pkill
      link
      26 months ago

      as soon as you realize you can’t easily contain your commit message within a 50-character conventional message (or slightly more if you wand to be more specific about the scope)

  • Murdo Maclachlan
    link
    fedilink
    76 months ago

    Image Transcription: Screenshot


    [The screenshot is from a GitHub commit summary. It is zoomed in to show just the tab headers for the “Checks” tab and the “Files changed” tab. The “Checks” tab has a number 1 next to it, and the “Files changed” tab has an infinity sign next to it.]


    I am a human who transcribes posts to improve accessibility on Lemmy. Transcriptions help people who use screen readers or other assistive technology to use the site. For more information, see here.

  • @xoggy
    link
    16 months ago

    When you go to merge master into your feature branch but accidentally squash master in.