4
Comments
  • 3
    This is nothing...

    It becomes fun when two main branches have merged and deleted but overwritten all frontend stuff by 4 months old code.

    And you find out a week later after several branches have been created from that merge fuckup and you have to revert an manually cherry pick what commits you need and which you dont.

    We have once worked with a kenyan who couldnt admit he didnt know git and thus merged a four months old branch into develop.
    Took me a day to figure out what happened and another day to solve it with two other people.
    (this was at t end of my internship)
  • 1
    @Codex404 wow. No words for that haha

    Edit: also note that that picture was made purely to see how branches work.
  • 3
    Thanks for PTSD attack.

    A few years ago I had a questionable privilege of maintaining the most atrocious codebase I have seen in my life (in regards to git management). When I joined the project, there was master branch that nobody merged to any commit from develop for like 2+ years. Production was based on master and we were developing new features on develop. Of course, there was active development going on both develop and master (cause you know, production can't stand still for over 2y). This project was 3-4 years old back then. Basically at this point it were two separate codebases sharing something like 40% of code while still working roughly 90% the same. The thing is, most of the team responsible for this mess was gone before I joined and I had to synchronise those branches.

    LSS: after utter failure with merging/patching (60% of codebase was one big conflict), I had to cherry-pick 600+ commits (while omitting some) one by one and resolve conflicts on the fly.
Add Comment