So while waiting for a project to build I like to run gource and see a fun video of my team building the project over time. While I was watching me and my team fly around editing and changing the file tree a coworker who is on our media team loved the visual representation and immediately asked how I could do this for his team's media projects ( documentaries, short videos, poster design projects ) which are worked on as a team and everyone edits files individually and then pushes them up to a central server on the LAN.

I know git would freak every file change because to it the entire file is new every time they say export the video to the LAN or anything like that. But would a quick git repo be possible for a media team? How much overhead vs pay off would they expect?

  • 3
    Version control is definitely valuable for non-programming projects, but the added complexity of git often isn't. I'd recommend trying SVN first, because it's dead simple to even a non-technical person. According to Google, gource supports SVN as well as git. – Ixrec Jun 12 '15 at 19:14
  • 3
    Git isn't hard. The size of a typical pull and a full local history of a media project would make it problematic though. – Karl Bielefeldt Jun 12 '15 at 19:21
  • 2
    @SnowRep github has a max file size of 100MB so if any file is going to be bigger than that, you'll have to run git on your own server GitHub – Patrick Jun 12 '15 at 20:00

Git is not very will suited for this as evidenced by the fact that currently at least three different extensions exist to handle this problem git-fat, git-annex, git-media.

Svn also have the possibility to only check out only a sub folder of the repository which git was explicitly designed to NOT to do.

Since git is distributed all clones must contain all versions of all blobs which will be large for binary files since they don't compress or diff well. Svn is centralized so a checkout can checkout only the recent version.

I recommend using svn or using one of the git extensions.


Pro and Cons:


  • will store different versions over time
  • will still be able to use compression to reduce file size for older versions.
  • will enable different developers to share one code (or asset in this case) base.
  • will make sure any common files stay with 1 version.
  • will track who touches which files.
  • can use the git-fat tool https://github.com/jedbrown/git-fat to not store the files in git but use $ git fat pull when you want to get one
  • will be the same tool that many people will already know form using it for code.


  • different versions of media assets will probably need to be stored in their (compressed) entirety.
  • standard 'git difference' functionality will not work on media which is not code without customization.
  • people will need training in at least a subset of git commands and/or a git gui
  • will require all users to get all files, which for media, can mean a huge amount of data

The last point, also mentioned by Esben Skov Pedersen, is possibly a good reason to use SVN for the media. This would be a judgement call. With SVN you get the huge advantage of being able to get individual files and directories instead of the complete repository as with git. The downside is that its an older technology with some different philosophies and and if folks use git at all (either concurrently or at other times) they will find the different philosophies and different syntax (or, worst, same syntax, different meaning!) confusing.

  • 1
    It is possible to use an extenal diff driver (see git-scm.com/docs/gitattributes §'Defining an external diff driver'). However, the problem becoms finding a good diff driver for the various media formats used by the team. – Kasper van den Berg Jun 13 '15 at 11:38
  • Good info. I didn't know that! Also +1 your answer! – Michael Durrant Jun 13 '15 at 14:23

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.