1120
Rebase Supremacy (programming.dev)
submitted 2 years ago by to c/programmer_humor@programming.dev
235 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 9 points 2 years ago (4 children)

How others are keeping their branches up to date is their problem. If you use Gitlab you can set up squash policy for merge requests. All the abomination they’ve caused in their branch will turn into one nice commit to the main branch.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 13 points 2 years ago (2 children)

    In a small team at a small company it becomes my problem pretty quickly, since I'm the only one that actually has some clue about what git does.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago

    Heaven forbid my teammates read any documentation or make any attempt to understand the tooling necessary to do their job.

    That being said, I taught my dumbass git-illiterate team members a rebase workflow, with the help of the git UI in Pycharm. Haven't had any issues with merge conflicts yet, but that might just be because they're too scared to ask me for help any more

  • permalink
  • fedilink
  • source
  • parent
  • [–] 8 points 2 years ago

    I don't want squashed commits. It makes git tools worse (git bisect, git cherry-pick, etc.) and I work very hard to craft a meaningful set of commits for my work and I don't want to throw all of that away.

    But yeah, I don't actually give a shit what they are doing on their branches. I regularly rebase onto master anyway.

  • permalink
  • fedilink
  • source
  • parent