Recommend me a version control system for design assets (primarily Photoshop & Illustrator)
I'm a software developer working with a small team, and our Google Drive folder tree of UI assets/illustrations/app icons/etc. is becoming increasingly difficult to deal with. Aside from proper versioning, symlinks would be a major plus. Both are kinda-sorta possible with GDrive, but not in a reliable way.
I'm happy to take on a reasonable amount of management myself, although the easier it is for the designers themselves to work with the software, the better. Paid solutions are fine, although open source would be preferable (even as a hosted service) to avoid vendor lock-in down the line.
My instinct is to go with git/GitHub on the basis that we're already deeply familiar with it from the dev side, the GitHub desktop app isn't too onerous for non-techies, and we're already paying for it. That said, I'd be very interested in anyone's real-world experience of git for multiple gigs of 10-200MB binary files. I've heard that it's not especially well suited, although that might be out of date knowledge?
Beyond that, I'm open to almost anything. I'm kind of surprised that I haven't been able to find a single "gold standard" piece of software here, in the way that git is for developers, but maybe I haven't been searching well enough? Any pointers in the right direction or stories of what has/hasn't worked for your teams would be a huge help!
That looks extremely promising, thank you! I'll do some digging and see how we could set that up for the team.
Very interesting, thank you - if we go down the git route I'll be sure to compare all three.
This will be an unpopular opinion, but it's coming from a place of wanting to minimize other people's pain. Feel free to ignore if you strongly disagree.
I strongly recommend against using git for people who don't already love git. It seems like a terrible fit for your situation. I use git at work along with git-lfs because we have very large media files and it's a pain in the ass. It makes git's already incomprehensible error messages even worse. Most GUI apps don't work properly with git-lfs. While there are a few that do, it doesn't really help all that much anyway. (And I've found that the GUI apps for git are barely any better at making git itself usable than using it from the command line.) Also, git requires a lot of extra knowledge and mental overhead if your project doesn't need a distributed repository (and most don't).
Are the people who will be using this developers, or at least power users who are used to the command line? If not, it might be better to use something like svn with a GUI app like Cornerstone. (Cornerstone is not my favorite app, and their licensing system is kind of shitty, but once it's set up, it's pretty simple, relative to anything git-related.) svn takes a lot less work on the part of the user to use correctly. (I can get into this more if you're interested, but I don't want to start a flame war if at all possible.)
The other issue with git is that if you attempt to look up how to do anything with git on the Internet, you'll end up with dozens of conflicting answers, all of which are correct for the assumptions the author made, and which are likely different from the assumptions you've made about your setup. I've seen tutorials that say "always rebase", tutorials that say "never rebase", and tutorials that say "only rebase in situation x, y, and z". Codifying all of this for your users and passing it on to new users is a mess, and since you can't auto-enforce a lot of it, it's easy for users to get it wrong.
That said, if you're mostly dealing with developers who already know and love git, then git-lfs makes large files less of a problem for git.
Firstly, I appreciate the input and I'm coming here for help, so it's incredibly useful to hear multiple viewpoints! I haven't even had a chance to read beyond the very basics of git-lfs yet either way.
To put your mind at rest a little: I've been at this long enough to know that trying to get anyone other than devs working with a CLI is a non-starter. I may or may not be speaking from some foolish decisions earlier in my career on that one...
It'll be used by both devs and designers, so user-friendliness and shallow learning curve are definite goals, with an absolute worst case fallback of the designers dropping completed work into a temp GDrive folder and one of the devs checking it in to whatever version control we settle on; far from ideal, obviously, but perhaps not as totally wasteful as it initially sounds given that we (the devs) are generally the ones consuming those completed versions anyway.
My go-to with a git solution would be GitHub Desktop and I'd expect no more complexity (mental or technical) than "Create a branch here, that's like a clean workspace for the project. When you finish a piece of work, tick the boxes by those files and write a message saying what's changed. When it's ready for the team to look at, click 'Create pull request'". It's allegedly fully compatible with git-lfs, albeit with a one-time breach of my no-CLI rule for setup (I would literally consider making an executable for them to run to avoid that step!). I'm in total agreement that git itself is overkill for something that simple, but on the other hand I wonder if the wider range of existing tooling and ecosystem around git makes up for that? Honest question, I don't know yet.
Cornerstone looks great, but I'd be less confident of our (i.e. the devs') ability to help out with svn issues simply because it's not what we're using day-to-day. Given that we'd 100% be going GUI whether it's git or svn, does that change your opinion there at all, or do you still think the svn architecture brings enough to the table to be preferable?
Finally, on the last point, I think (hope) we'd be saved by our own simplicity. I'm not expecting anyone on the design team to even hear the word "rebase", for example, and if they somehow do manage to do one in the GUI then all they can do is force-push it to their own working branch where it'll later get checked as a PR just the same as any other. I know you were just using it as an example, but I think the same pattern applies to most things: the workflow for the non-tech users will be basic enough to avoid the questions, and if/when the devs need to step in we already have the workflows agreed.
So, very much not just for devs who already love git, but perhaps not the workflow you were envisaging for the designers either. Very interested to know how, or if, that affects your suggestions!
So to give you an idea of issues we've hit with git-lfs, we have a set of instructions for setting up a new machine, and it involves either ensuring that you're using a Full-Tunnel VPN (which is not the default for our VPN software) or that you've modified /etc/hosts to have the git-lfs server hardcoded to a specific IP address. That's the type of thing that even as a dev, I would not have been able to figure out on my own. Once it's set up, it usually just works, but whoever on our team figured out that step was necessary is way better at this stuff than me. I don't have time to deal with those sorts of issues and it would have stopped me dead in my tracks if someone else hadn't already written it up.
Beyond that, sometimes git-lfs has a hiccup and causes git to get confused and you get meaningless errors like "merge failed: ref abce023984 is not an object". And if it would actually display the file name, you might be able to figure it out, but it doesn't, and it also doesn't mention git-lfs, even though that turns out to be the problem. Again, even as a dev with decades of experience dealing with these sorts of things, I had no idea what this meant or how to debug what the problem was. Luckily I had people I could ask about it and they knew what it was.
We use GitHub as well, though I don't use the Desktop client. (And I think it's just an Electron app anyway, so I'm not sure how different it is from just using the web interface directly.) I find GitHub very confusing and difficult to use, personally. I have constant problems with it, like in the various combo boxes where you're supposed to type in branch names for pull requests, I'll have typed in half the name I want, when it suddenly finishes populating the list of remote branches, erases what I typed, and if I don't notice and hit enter too quickly, it selects main and suddenly my changes are going to main instead of a feature branch. It's full of little gotchas like that. But again, if it's something people there are already comfortable with, then maybe it's no big deal for you.
That's totally fair. If you haven't worked with svn, it takes some time to learn it, like any version control system. I found it far easier to understand than git, personally, but I didn't have a choice. No need to complicate things for yourself.
VPN trickery and cryptic errors are definitely the kind of things I'd like to avoid, so it's helpful to know things might not be as seamless as I'd hoped there. It sounds like whatever option I do settle on will be worth trialling myself for a decent bit of time (parallel check ins as if I were the designer, for example) to shake out the kind of bugs we're likely to see and figure out if they're dealbreakers.
It is Electron, but quite different to the web interface - the key benefit for this specific task is that it handles all the local git commands through a unified GUI as well.
I broadly like the GitHub interface, as it happens, but I know that's a matter of personal taste and familiarity. Again, something I'll be mindful of given that we'll need to teach at least the basics of using whatever we settle on to people with no real familiarity.
More thinking to be done, for sure!
I'm familiar with the horrible ui_design_mainmenu_v8_final_final_reviewed.psd antipattern, it's really intolerable especially on a team of any size greater than 0.
In the last year I've become familiar with a version control system called Perforce (https://www.perforce.com/). We're using it to manage several Unreal Engine projects, which involves handling a large number of binary files (3d models, textures, etc) that don't diff like text files. Take a glance at their home page to get a feel for how much it's used by some very well-known companies.
Pros
Cons
Perforce confuses the living shit out of me… maybe it’s how my company implements it (many different servers at different ports, with different content on each), maybe is that I don’t have to use it frequently (and thus, forget most of what I learned about how to connect and navigate), but I can’t stand it in comparison to git.
But hey, if it works for you, more power to you
I think that's probably true for any VCS system. They can be very frustrating, because VCS is never going to be a tool that directly helps you accomplish your work, it's always a tool that creates an extra step that you have to do in order to do your "real" work.
It definitely took awhile to learn the ins and outs of P4, probably a month or two of daily use. I also happen to be the person in charge of our server and hosting, so I had extra incentive to learn how it works. Then again we were (are) a small team starting from scratch, so there wasn't anyone who could help us out aside from the documentation.
For anything I do infrequently that's complex, I find it really helpful to write myself a checklist as I figure it out. I write it as if the person who's reading it (future me) is a drooling moron. I've found it very helpful, and on occasion new employees have too.
Yeah I totally buy that. It also doesn’t help that it’s used solely to host our hardware docs, which… well let’s just say it’s a pretty serious negative reinforcement 😂
I have used Perforce before and really liked it. It was what I used when I ran my own company. That’s interesting that they now support git on their servers! That sounds ideal to me.
As it happens I did use Perforce back in the day! Admittedly I wasn't a great fan, but that was a job I had a good ten years ago, and they were still using a version they'd licensed probably eight years prior to that and was laughably outdated even at the time, so I'm very willing to assume ~20 years of progress makes for a substantially different product.
From their website it seems like they've focused in on design assets as one of their core use cases, which is good, and the nice set of ostensibly beginner-friendly UI apps is very appealing for what we need. I'm always wary of being locked in with a single vendor, but it's not a total dealbreaker - do you happen to know if the Helix TeamHub licensing includes the software licenses as well, or is that separate?
[Edit] Hmm, looking at the options further it seems like TeamHub is their GitHub competitor. Will need to email them on Monday to get more info on the actual Helix Core/Helix Sync pricing.
No opinions on their TeamHub unfortunately. We looked at it too see if it would be useful, but decided against it. Our team is quite small (2 full time developers, 0-4 students that change every semester) and it didn't seem worth it.
All good - I actually only ended up there because it's the top result for "Perforce pricing", and I posted before I realised it was separate from their core product!
Totally fair - my experience is that it's tough to keep conventions as more people have hands on a project, as people leave and join, and and as assets fork for different purposes (final for one app or distributor, not final for another, oh shit did I want the update to cascade down to a third and fourth distributor or not?) and that's where we're finding ourselves now.
All that said, it's good to have a reminder that the tech solution isn't necessarily the only solution! Perhaps some new, better guidelines on naming and structure could go a long way. Very much worth keeping the basics in mind before I start overcomplicating things.