24

If I ever decided to open source my work in the future, I'm sorry in advance to those that read my commit messages...

Comments
  • 4
    I use a lot unrelated facts or unrelated fake facts for the readers 😁 At the beginning I was very serious in it but later I found out the environment in general doesn't care so 😁
  • 4
    My commit messages look very similar today :) Because I'm adding the GL CI/CD support, so.... kind of a rain of commits with miniature changes :D I'm already running out of unique commit messages
  • 3
    Create a branch.

    Work till it works, tested and verified.

    Cherry Pick and rebase on main branch commits from two.

    While rebasing, edit the commit messages.

    More work, yes. But frustration from not being able to fix stuff like you want to do leads mostly to "" bad documentation "".

    So the cherry picking and rebasing makes sure that you take your time and think.

    More than I'd like I suddenly realised whole rebasing that the commits have consequences I wasn't aware off.
  • 3
    @netikras do random Trump quotes :)
  • 2
    Create a new branch and squash these commits on merge.
  • 2
  • 3
    @webapp actually worse than a ton of random commits
  • 2
    Use git hooks that appends your branch name on your commit so at least you know when and how this shit happened
  • 4
    I just usually append a version number to these kind of commits, some day the commit history may look like:
    Fuck 3
    Fuck 2
    Fuck
  • 1
    @netikras feel you. when I created my first CI/CD configuration my commit messages have been like:
    -removed stage prepare
    -added stage prepare
    -removed stage prepare because it breaks the build
    -build is now succesfully broken without prepare
    -adding prepare
    -changing snapshot because shit doesn't work
Add Comment