I’m interested in using Git as an incremental version control system. I’m not planning on using it to collaborate. I just want to do daily pushes so that I have a good way to backtrack to older versions of my files, and to have that stuff backed up to a remote server. Does this make sense? Is there anything special I should do? Would I be better off just saving incremental files (typeface.xxx) and storing them locally?
1 Like
I have several repositories in GitHub, and yes it makes a lot of sense. Recently they made private repositories free, and you can keep daily or as-needed backups.
Several advantages:
- Track changes - you can add comments to the backup, so it’s easier to keep track of what was changed. This is the best, no more need for filenames such as “final file v2-this”
- Redundancy - If you have another computer, you can pull the latest changes into it.
- Branches - You can create a “branch”, i.e. if you want to explore a different path.
- And all the benefits of keeping all files in one place.
You don’t need anything special to get started.
- Sign up
- Download the Desktop app
- Create an empty repository, select “with a Readme”
- Open the repo in the Desktop app, save to a folder (I like to use myuser/github/projectname)
- Drag files in that folder
- Do a commit
And just keep working from that folder.
You’ll only need to do step 6 from now on.
hope that helps
2 Likes
Also recommend you check out: CommitGlyphs | Glyphs
If you are new to GIT I would recommend using a client like Sourcetree as well: https://www.sourcetreeapp.com/ for more control over branching / committing.
And check this guide out: How to Create a Git Repository | Atlassian Git Tutorial
Couple of other tips:
- Make use of branching - branching costs nothing and allows you to try out alternate design ideas. You can fork from branches recursively too. If you don’t like the work, simply destroy the branch - but if you like it and want to keep it, you can merge your branch into master. (However, you may have to handle the odd merge conflict if your branch diverges significantly from master, so employing git flow is a good idea).
- Stashing your work lets you quickly jump back to last commit, but you can then pop the stash to return to what you’re working on. This is handy if you need to switch branches but don’t want to commit what you’re working on.
Ideally you’ll only ever just need the one .glyphs file in your repo, and let GIT manage the rest. It’s far better than having hundreds of similar looking files on your desktop 
Also, both of those actions are easy to perform in Sourcetree if you don’t want to use the command line.
1 Like
This. And keep your file name the same throughout the git history, otherwise the tracking does not work.
I do keep a backup folder around so I can quickly bring back glyphs if I need them, because you do not want to go digging in git history for small details. In the backup folder I create copies before big changes, and I rename them with a date and time suffix (I have an Automator action for that).
1 Like
nice idea using Automator,
Question: is the backup folder inside Git? @mekkablue?? so you commit that backup folder and delete when/if no longer needed?
I would ignore the backup folder.
1 Like
ah, excellent point!
@DunwichTypeFounders : You can set folders and/or files to ignore! So you can keep them inside the git folder, but they don’t get committed to the repository.
I keep it inside git, to compare with previous iterations, and to have files to cannibalise if you delete too much in your work file, and also to keep original deliveries from clients.
It is not git-puristic, I know, but the .glyphs file format is not 100% git-friendly either.
1 Like
If you a new to git I suggest you make a “playground” repository and first test use it with plain text files to see how it works in action. Make a commit with a file with some text, make another commit with other text, make a branch with changes, merge those to your master, this sort of thing. Go back to some other earlier comment, go back to the latest. So you really see how git allows you to “time travel” and to see how it “combines” things when you merge changes from different branches. Before jumping to 100k lines .glyph files where everything is more complex and hard to understand.
Also keep in mind that all the git magic only works on text files, not binary files. You can still “save” different states of otf/ttf files in your commits, but there is no way to merge or combine different changes in them with git. The magic in git is based on lines of text that git can compare between file versions.
1 Like