How to collaborate with Glyphs?


I would like to discuss finding a flexible and efficient workflow for managing projects involving multiple designers, particularly in multi-script font design.

  • How do you typically approach this process?
  • Do you split your glyph files, creating one for each collaborator, and then merge everything at the end?
  • Or do you keep everything in the same file and use Git with branching? Is this a completely safe method?
1 Like

Personally, this is what I use. This does, of course, require designers who are at least somewhat competent in git (good luck!), but if they actually listen to your explanations and follow them, it works very well. There should be one person who admins the git, who is competent enough to manage inevitable merge conflicts when people do bad commits and mess up stuff.

I have one suggestion/request for the .glyphspackage file format: the ability to create subfolders in the /glyphs/ directory in which to store the .glyph files. This would make it a bit less error-prone when working with new people, who can be told to only commit one directory (or you can set up a tailored gitignore for them, excluding all but that directory).

I don’t think folders would help. What happens when the assignments change? You need to move around all those files?

Admittedly, it’s a very complex topic to tackle. I do think that using subdirectories would solve at least some basic issues when collaborating, in conjunction with a custom gitignore.

Of course, changing assignments would be a real mess to deal with. This would most certainly necessitate a dedicated git admin who does nothing but deal with file merges all day :wink:

Even with folders, a user can edit other glyphs in the app. If there is a desire to limit users to a subset of glyphs (and/or masters), this would be best handled from inside the app. For example, a reporter that highlights excluded layers (or even temporarily locks layers, although that might turn out a bit to restrictive).

Using the “Master Color” custom parameter might be a solution to visually indicate “Do not touch this master”. Additionally, it could be useful to have a “Lock Master” custom parameter to lock master layers within a glyph, rather than the entire glyph.

But in any case, in a workflow using git, their use is complex during a merge.

And everyone needs a good git client (I’m super happy with Tower).

And it is super important that everyone ready through the full diff and understands enough of it to know when to discard unintended changed. I saw in several projects where collaborators committed stuff in file there had no business with.

In short:

  • git
  • .glyphspackage, not .glyphs
  • look into import master/import font parameters
1 Like

However, I find that the Import Master/Import Font functionality is not sufficient at the moment. When a master/font is imported, it is not recognized as a “real” master. For example, if I use “Show master of next/previous Glyph,” imported masters will not be used.

Additionally, how do I deal with features from imported fonts/masters?

fixed it.