I work in a large software development group and we've recently made the switch from Clearcase to Git. Some predictions have been made with regard to the quality of the mainline in that it would become too noisy and unmanageable with commits from hundreds of developers and that the repo would get too large too quickly.
The current proposal to address this is that when feature teams bring in changes to the mainline (this can happen every week or so, and there are multiple feature teams working in parallel on the product) a single developer would be responsible for squashing multiple commits from multiple developers into a single commit.
The above approach worries me mainly because 'git bisect' and 'git blame' functionality would be compromised (a single developer would now represent the work of multiple developers). I've countered with the following proposals:
- To address the noise in mainline, each developer should squash into a single commit before creating a pull request. This appears to be standard practice.
- To address the size of the repo, devs could do shallow cloning and grafting (both approaches detailed here: http://blogs.atlassian.com/2014/05/handle-big-repositories-git/)
So far I haven't been able to convince anyone that these would be good approaches. FWIW I also proposed using Gitflow as the main development workflow to separate out development and release branches but that also didn't gain any traction. Personally I think so long as developers squash into a single commit before generating a pull request then that's fine... having commits from many different developers in the mainline is pretty much a non-issue after that point, it just shows that a lot of work is being done.
So my question to those of you who work on large projects in Git: is having many commits coming into your mainline actually an issue, thus forcing you to resort to solutions like squashing commits from multiple developers into single commits?