git – Store Locator Plus® Internal Docs

SOP: Code Management

Posted by lcleveland in Development, Internal Use Only, Process, Store Locator Plus®

All development is done on personal forked copies (origin) of the primary Store Locator Plus® repositories (upstream). Upstream is considered the “single source of truth” for the current code state.

Additional Reading

Forks and Pull Requests

To begin work, fork the main Store Locator Plus® repository (upstream) to a personal repo (origin).

When code is ready to be integrated with current ongoing development effort, issue a pull request for your origin:update/<something> (see branch conventions below) branch into the upstream:develop branch. When the pull request is approved and merged, the upstream:develop branch be ready for the rest of the team.

Monitor upstream:develop regularly and be sure to fetch-and-merge (aka “pull”) the upstream:develop branch into origin:develop. Any in-progress origin:update/<something> branches that have not had a pull request issues against upstream should be rebased onto the new origin:develop branch. Make sure all conflicts are resolved.

Dev Standards

Posted by lcleveland in Debugging, Development, Store Locator Plus®, Testing

git Branching Model

Master / Main

The production branch. This branch should always point to production releases – the code released to the public or in use on production systems.

Staging

The release candidate branch. Prerelease plugins or the plugins/components that are published to dashbeta for the SaaS offering.

Test / Develop

The branch being used for testing integration of ongoing development branches.

Version Identifiers

Starting in August 2022 all product versions will follow a YYMMDD.xx standard where YYMMDD is based on the development start date for primary product releases (Store Locator Plus® for WordPress, MySLP Dashboard,etc.) For related product releases (Power, Front-End, etc.) the date should try to match the main product/service it is related to but this is not a strict rule – rather a suggest to help users easily identify related releases.

The YYMMDD should be 2 digits each and xx should always start at 01 for the first revision. For example 220815.01 is the first iteration for an app that started development on 220815.

Code Formatting / Linting

JavaScript

The preferred linting library is ESLint due to the ongoing React support.

Keeping Forks Updated with Upstream

Posted by lcleveland in Development

When forking a repository you are making a new copy of the original source , creating what can become a completely different codebase over time. Often that is not the intention when working on a project ; you typically want your own copy to mess with but need it to be “in alignment” with the main production software, or “upstream”, on a regular basis.

Keeping your fork updated is done by using a secondary remote source on your local git clone of the forked repository. By default git clone creates a single remote with a default name of “origin”. Origin is typically the github or bitbucket copy of the codebase stored via git.

Any git repository can have multiple remotes assigned to them. One of the first things you should do when forking a repo and cloning it to a local box is to setup the “upstream” remote point of reference. I use the graphical git tool Sourcetree to help with this.

After cloning your fork, double-click the repository name in Sourcetree to open the commit browser window. With that window open you can open the Repository | Repository Setting menu. Open the sub-tab for “remotes”, add a new remote, name it “upstream” and put in the git URL that represents the original code repository from where your forked version came.

You can now fetch upstream branches alongside your own. When you want to bring your forked copy “in alignment” with the upstream, checkout the branch you want to have aligned… develop for example… fetch the same branch from upstream, them merge upstream/develop into your origin/develop branch. Push your local develop back to origin/develop and valla — your forked copy is now ‘in alignment” with upstream for that particular branch.