Hello everyone,
I've just started out in type design seriously a couple of months ago and I want to improve and adapt a certain workflow when it comes to designing type.
I'm already using Git(Github/Bitbucket) but I can't seem to keep a certain workflow and a certain number of branches.
My questions are these:
1. On what premise do you give a version name to your file(1.0,1.01)?
2. Do you only stay in the Master Branch on GIT? Or do you branch out and I don't know, have something like a Branch for each master or style?
3. How do you work when you collaborate with someone else or do remote work? Do you use a UFO file?
Thank you so much everyone!
0
Comments
I can’t imagine why one would need a branch for each master or style.
What file format to use and how to collaborate depends a bit on your tools, and what part of the work you are each doing. If you are doing work on separate glyphs, then using UFO files and only checking out the specific glyphs you need might be best.
The version 0.1.200229 method sounds really good! I will definitely start using that from now on!
For a new version, let's say version 0.2 when you say a new build, are you referring to a new export to OTF/TTF of the file you're working on? At this point, I'm using only Glyphs App to edit and export, no other scripts.
Regarding the file format, that was spot on the case I had, working on specific glyphs remotely, thank you for the advice!
The fonts and source contain version strings, but generally I only rev those when there are changes to the glyph set or other significant functional differences. Out of habit, all my beta fonts are 'Version 0.80', and the first release version is 'Version 1.00'. Typically, I stick the build number in the version string when I generate a font, so I know from what source it was made, e.g. 'Version 0.80 b064'.
___
* Personally, I like to keep build numbers in the release font file names, but some customers want the font file name to always be the same regardless of changes or updates.
Release is usually an ID that's given by the author. A good way for naming releases is using numbers like 1.2.3, or better 1.02.03. which mean major.minor.maintenance. For small projects not releasing often major.minor is good enough. The term release implies giving it free for others. This allows to use the release ID in communication with others for diagnostics or whatever. Sometimes it's useful to append a tag like alpha, beta, devel, trial, nightly_build_20191031 to the release number to signal the quality level.
Usually a release has a build, i. e. one or more deliverables like myFontName-v1.02.zip or ...-v1.02.free.zip, ...-v1.02.commercial.zip etc. Github supports it, to have the deliveries in the download area of your project. A good and usual way is to tag a certain commit state of your repository by the version ID, e. g. tag=v1.02.
It depends on your toolchain, how you handle builds and releases. In software I usually begin with version 0.01, commit often in logical units with comments, push to github or my private git server. Before release I build locally testing the build process with many automatic quality checks. Then I release a TRIAL release. My toolchain forces me to use a higher release number, checks the changelog, license, builds docs, checks if everything is committed, pushes to github, releases the deliveries to the targeted software repositories. After some days or weeks of testing by third parties I build a new "official" release with a new release number.
Branches make sense if you have a larger project, many contributors, working on a production version e. g. 4.x and a new version e. g. 5.x in parallel, or working on experimental features, massive refactoring, or maybe adding e. g. cursive to a font family.
1. I don't version my source files. I versioned them before GitHub, but now I find that can cause conflicts when syncing (especially when collaborating). With each commit I try to be precise about what's been changed, so in case I have to go back, it's actually easier to read a summary than to guess which number has the data I'd want.
2. I stay in the Master branch when working on a project alone. I would use branches when working with others, especially if the size of the project is pretty big. I wouldn't put each style in its own branch.
3. Yes, always UFO, but that's just what I know best. We make use of branches then. Collaborating remotely can be challenging. Then it's not as much about workflow as it is about communication and being clear with everyone's expectations. Video meetings with screenshare are important, not just for talking about the work, but also for conveying tone and emotion that is otherwise lost in text/email. A lot of people don't understand how absolutely crucial that is for a project to go well.
99% of the time I don't have problems. When I do, it is usually a bug on my computer or with RoboFont, so I can't blame git. Sometimes a collaborator will have an issue and then it can be any number of things, but I don't think it's the UFO's fault, necessarily, but honestly, at that point I get our tech support person to figure it out.