My GIT Revision Control Journey

This is not intended to be yet another GIT tutorial or reference manual, there are plenty of those on the web, but if you're in the same position of being a sole developer and having to make up your own rules as you go along this could be helpful.

Using GIT in Microchip MPLAB

The MPLAB IDE is a customized version of the Netbeans IDE, and as such it supports the same plugins including a GIT client

MPLAB's built in GIT client

Using GIT in Gamemaker Studio (One)

Gamemaker Studio Git

Using "rebase" to clean up your mistakes

Rebasing provides a powerful tool to clean up mistakes in the filing of a project's history.

Rewriting project history for fun and profit

Using submodules for library development

The GIT submodule system is a way of nesting GIT projects such that a project can contain a library that has its own separate repository. There are two "competing" systems, subtrees and submodules. Based on what I have read it appears as if:

• Subtree appears suited to importing an established library to a project
• Submodule appears suited to developing a library that will be pushed to a repository

There's substantial overlap between the two systems, but if you add a subtree to your project then the files in the subtree are committed to your project, meaning that if someone else checks out your project they get the complete project, and your project is protected against the subtree's source becoming unavailable.

If you add a submodule to your project then only a reference gets committed to your project, any changes to the submodule need to be committed to the submodule's repository. This is mostly good for development, though the onus is on you to make sure the submodule is up to date before committing your project. For a potential user it means they need to get all your project's submodules before they can use it, though this process is automated so it is no great hardship.