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?

Improve this question
4
  • 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
    Commented Aug 30, 2015 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
    Commented Aug 30, 2015 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
    Commented Aug 31, 2015 at 2:43
  • “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).” You can use the Co-authored-by trailer for commits that were made by multiple authors.
    – Guildenstern
    Commented Apr 28, 2023 at 20:26

2 Answers 2

Reset to default
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.

Improve this answer
1
  • 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
    Commented Aug 31, 2015 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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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