101

My lead keeps pushing commits to master. His commit messages vary from: no message, yeah, and yup.
and yea, some of the build break master.
Makes me just wanna die sometimes when digging through our commit history to figure out when a bug was introduced.

Comments
  • 19
    I am so sorry.
  • 6
    They are leading the way to code smell.
  • 2
    yeah.
  • 5
    Oh, what a frigging dilettante. It must be a pain to fix their own incompetence.
  • 0
    Autism
  • 22
    Block pushing to master. Allow only pull requests that have been reviewed.
  • 5
    Tell him what's wrong and create a VCS guideline, so there are written requirements for correct usage.

    If possible, enforce the technically checkable requirements on the server with commit-hooks.

    If someone here would commit this way, he would be lynched immediately, and justifiably so.
  • 3
    One of my pull requests was once blocked because CI pipeline failed. Why? Linter issue. What? Linter throws no errors on my machine.

    Turns out some twat pushed to master on an entirely unrelated part of the codebase. Likely someone forgot to prevent master pushes on that particular repository.
    I pushed the lint fix straight to master with the message "If you push shit to master, I push shit to master as well" (this is a quote).

    Rebased local branch on master, pushed to rerun CI and voila, runs through fine and gets merged to master after peer review.
  • 4
    Two thoughts:
    1. Does he own his fuckup?
    That's really the key here. If they're capable of acknowledging their failure and remedying it, that's a positive.

    2. Is the rest of the team capable of reviewing his code?
    This is a spot I've been in a few times, assigned a team that was underskilled to such a degree none of them could review my code, so issuing the pull request to trunk would be ceremony.

    Either way, conversations should be had. Tests should be written.
  • 6
    @SortOfTested

    I use PRs even in my solo private repos.

    Mostly because having the merge history and "revert PR" button is much more convenient than finding all the commits you want to revert by hand if one feature deployment goes wrong.
  • 2
    @bittersweet
    I do single feature squash commits and use git revert. Merge commits are just noise to me.
  • 2
    git blame to the rescue
  • 5
  • 1
    @Flygger you have made my day
  • 2
    roll them back every time with no commit message
  • 0
    I too have a teammate which does that.
  • 0
    We have one person who will put various things like this including 'lulz' 'broke shit'
    Even more infuriating when their is no ticket number.
  • 0
    In the name of Bad practice, this is bad practice!
  • 0
    Wait what? How do you guys cherry pick these commits? Like 'Oh', 'yeah' cherry pick me ! 😂
  • 0
    Just squash all the commits and force push !
  • 0
  • 0
    Decline his PRs until he cherry pick amends every last one of his bullshit messages
  • 0
    @nitwhiz what do you even mean by this comment "Autism" wtf dude? Ableist much? Kind of offensive to people that are doing a really good job that have the condition?
  • 1
    Kill the bastard, he/she/it/whatever deserve it.
  • 2
    Even i didn't commit to master when i wasn't using version control. I used to copy the master and make changes into the copy (cuz too scared to fuck up)

    P.S. I was just getting started with coding in middle school and we didn't know about version control.
  • 1
    @mentions That actually seems like a sensible approach to rudimentary version control.
  • 0
    I genuinely feel sorry for you.
Add Comment