Paige

My Practices:

1. Create the repo first, then begin the project. It's just easier for me.
2. Use a free online service provider, for offsite backups and to quickly move between machines.
3. Use git-lfs. It's not really necessary with small GB Studio projects, but it's a good habit to get into.
4. 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.
5. 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.
6. 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.
7. Keep the following simple .gitattribute and .gitignore files.

⌗ 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

[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!