Editing and Contributing

So, you like the Addin. And you want to contribute more. Hurrah!

BLUF:

1. Make Pull Requests (PRs) on the "Dev" branch: it's the in use branch. Stable is not actively worked on, and is used to provide a "stable" base while we work out any kinks in the dev branch.
2. If you can, do not pull directly from your "dev" fork: make a working branch in your repository. This will help ensure reduced conflicts, and to ensure we know what the scope of your PR is more easily.
3. Keep scope of PRs within a single area of focus: if you fixed two bugs, please keep them to separated PRs. Using specific work branches will help. This will ensure we don't get co-mingled issues, and is a lot cleaner to ensure we don't introduce new bugs from fixing others.

Details:

If you directly edit Access Add-ins (such as this one) within the "opening" Access file, changes will not be saved. This is a double edged sword: it allows easy debugging, and trying things out which might otherwise ruin files. Downside is that once you close the session, it will discard any settings.

This is a nice way to load "extras" for users and ensure they don't break things for everyone else.

If you want to make changes to your Addin (and contribute those to others!), do this:

1. Fork this MS Access Repository into your GitHub account repos.
2. Clone your fork to a local repository alongside your other Access dev repos on your machine.
3. Some put theirs alongside some other Access repositories they utilize.

3. Switch to "Dev" Branch: We suggest renaming YOUR "dev" branch to something local to you, especially if you still use some of the legacyVCS tools. I named my local fork of this branch to "dev-addin".
4. Connect a second remote to the joyfullservice/msaccess-vcs-integration (upstream) repository. This way you can track progress on the upstream ( joyfullservice/msaccess-vcs-integration) repository. There may be changes you don't want to pull into yours, or you may want customization not present on the upstream (in some environments, users have specific changes required to ensure proper integration in their security environment and/or configurations that shouldn't be default for everyone).

5. Go into your new local repo, and launch the Addin directly.
6. Make changes, use the add-in to export the add-in code, and commit/push/pull request just like any other repository.

7. See above for PR guidelines.