Cloning a repo to build the source code isn’t even remotely hard.
When you manage the repo of an entire team who work together on different release versions of a product using a very specific workflow with squash commits and cherry-picking? And when team members fuck up the repo’s history with a bad git pull/push? Yeah, it gets more complicated.
Even with merge policies, if someone doesn’t understand what they’re doing or how it works, it won’t help.
Last project I worked on, we asked our developers to rebase on the parent branch and squash on their pull requests. But, they often encountered conflicts because they never updated their branch. They would pull the parent branch into their feature breach, or do a regular merge, or merge different other branches together and you’d end up with commit duplication everywhere. They didn’t have any discipline.
Cloning a repo to build the source code isn’t even remotely hard.
When you manage the repo of an entire team who work together on different release versions of a product using a very specific workflow with squash commits and cherry-picking? And when team members fuck up the repo’s history with a bad git pull/push? Yeah, it gets more complicated.
If a team member can fuck up the history you probably should look into your merge policies.
Even with merge policies, if someone doesn’t understand what they’re doing or how it works, it won’t help.
Last project I worked on, we asked our developers to rebase on the parent branch and squash on their pull requests. But, they often encountered conflicts because they never updated their branch. They would pull the parent branch into their feature breach, or do a regular merge, or merge different other branches together and you’d end up with commit duplication everywhere. They didn’t have any discipline.