My Practices:
- Create the repo first, then begin the project. It's just easier for me.
- Use a free online service provider, for offsite backups and to quickly move between machines.
- Use git-lfs. It's not really necessary with small GB Studio projects, but it's a good habit to get into.
- Make frequent, small commits. Typically this means, every time I change an asset and/or add/alter some code, I immediately stage and commit; this makes it much easier if I need to step backwards later to figure out when I broke something, and also means I don't have to remember what I just did for very long.
- Push occasionally, after a significant amount of work is done, usually about once every 30 to 60 minutes. This means it's easier to back out and remove commits in the rare case when I decide I shouldn't have done something in the first place.
- In general semantic versioning is sensible but it may be too fine-grained for most GB Studio projects. I tend not to assign version numbers at all until I'm sharing the game with testers, when I begin at 0.1-beta. When I release, that's 1.0 and every subsequent release gets a tag.
- Keep the following simple
.gitattributeand.gitignorefiles.
File contents
.gitattribute
⌗ GitHub Language Detection design/* linguist-documentation⌗ Normalize Line Endings to LineFeed
*.md text=auto
*.text text=auto
*.txt text=auto
LICENSE text=auto
⌗ LFS
*.mod filter=lfs diff=lfs merge=lfs -text
*.png filter=lfs diff=lfs merge=lfs -text
*.sav filter=lfs diff=lfs merge=lfs -text
*.uge filter=lfs diff=lfs merge=lfs -text
*.vgm filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text
*.zip filter=lfs diff=lfs merge=lfs -text
.gitignore
[Bb]uild
*.bak
~*I think that frequent, small commits are the most important of these. Here's an example of my commit history:

Confused? Read on for a brief intro & tutorial!
Feedback welcome!
