I agree, that this approach has its place into the world as well as rebasing. In the previous company we had a huge repository with a lot of projects in it(yeah - "brilliant" idea, because the DevOps guys and gals couldn't fix their Jenkins jobs) and for the sake of easier traversing the history if needed we have agreed that a single commit should be for resolving a single story or fixing a single bug. And actually the whole process was build around - you are working on a single thing. Then in our case squashing multiple commits(rebasing doesn't byte too hars when you play with it several times) into a single one was the choice.
Oh, another neat command is pull --rebase which can get the latest state from the branch you want and push your commits infront of it. If done before merging - you will see(and hopefully properly resolve) all collisions and your changes will be on top of the main/dev/smthg else branch.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree, that this approach has its place into the world as well as rebasing. In the previous company we had a huge repository with a lot of projects in it(yeah - "brilliant" idea, because the DevOps guys and gals couldn't fix their Jenkins jobs) and for the sake of easier traversing the history if needed we have agreed that a single commit should be for resolving a single story or fixing a single bug. And actually the whole process was build around - you are working on a single thing. Then in our case squashing multiple commits(rebasing doesn't byte too hars when you play with it several times) into a single one was the choice.
Oh, another neat command is pull --rebase which can get the latest state from the branch you want and push your commits infront of it. If done before merging - you will see(and hopefully properly resolve) all collisions and your changes will be on top of the main/dev/smthg else branch.