4

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?

  • 1
    In my eyes, you are totally right. Squashing everything together is pointless. One of the reasons to use a vcs is that you have finegrained control about what enters the codebase when. – Thomas Junk Aug 30 '15 at 19:14
  • 1
    Why do your coworkers think switching to git will create these problems? I'm not familiar with Clearcase, but git provides loads of ways to control what commits end up where, so I don't understand the implication that switching to it would automatically lead to more/messier commits on master. – Ixrec Aug 30 '15 at 20:40
  • @Ixrec I'm still not sure, actually! I think because it's still relatively new to us that there may be a "fear of the unknown", in which case I'd prefer going with a well established workflow as our default and then using data from usage of that to guide future decisions if that doesn't quite suit our needs. I hate the thought of destroying potentially useful information. The git tools 'bisect' and 'blame'... we never had anything as useful as that in Clearcase, it'd be a shame to reduce their effectiveness from the get-go. – daecks Aug 31 '15 at 2:43
5

At my company, we have never really had problems with too many commits. The key to organizing is to create well named branches and do your work in them. That helps to organize not only commits, but the developing group as a whole.

Yes, without branching, it could become a huge mess, but with them, your management can just browse the commits using them without needing to squash commits together.

Squashing multiple commits into single does not really make sense, as using that way it is more difficult to retrieve single edits.

  • 1
    "...it is more difficult to retrieve single edits." This is the truth. Squashing is for when in retrospect you want make a bunch of your commits share the same commit message. The bigger the commit, the harder it is to review the history. And if you are reviewing the history at 2AM, trying to figure out why it is broken, smaller commits are easier to digest. And whether you have 5 commits or 500, the number of lines of code changing would be about the same (assuming you don't have a lot of rework or iterative work in that 500). – Greg Aug 31 '15 at 1:00
2

Instead of a single repository with a ton of branches and all code funneling into one place, consider many distinct repositories. And, use a CI build server to build from the repos. Last, output the build artifacts like WARs or MSIs or whatever to a company wide Nexus or Nuget server. This way, you can manage the life cycles of each little module separately. Any interdependencies between modules can be loaded from your Nexus/Nuget server during your build using dependency management build-software like Maven or MSBuild.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.