-
Notifications
You must be signed in to change notification settings - Fork 44
Git Practices
CORE relies heavily on git and github for not only development but also managing releases and upgrades.
The upstream project maintains a couple standard branches.
- master is where development happens. It's the bleeding edge version with newest features and least stability.
- version-x.x branch(es) are created for each release. Version branches are expected to be stable. Only bug fix commits should occur on version branches after release.
- gh-pages maintains an online copy of the doxygen-generated documentation on github.io.
Pull requests are welcome! How you manage & name branches downstream is entirely up to you. Most pull requests should target the upstream master branch. Any pull requests targeting version branches should contain a single commit. Stability expectations require more cautious changes post-release.
Currently there's a code freeze on master. One store (WFC) puts the master code into production for a couple days and monitors for errors. Once production use is stable, the last two updates are rebuilding the doxygen-generated documentation and incrementing the VERSION file. This commit is then tagged with a version number and a new version branch is created starting at that particular revision.
Devs tracking master directly are pretty much going to have to fend for themselves. Noting the current commit hash before a merge is recommended. That's the rollback point in history if everything goes haywire.
For stores doing local development but looking for more stability, merging version branches is the recommended route. For example, to upgrade to 1.3:
git branch test-1.3 master
git checkout test-1.3
git merge upstream/version-1.3
This assumes local development is happening on master and upstream is the main CORE-POS repo. Creating a new branch before merging means you can revert to the pre-upgrade environment via git checkout master. When the testing branch has been sufficiently validated the final steps to upgrade master will be:
git checkout master
git merge test-1.3
Note that it's virtually impossible to ensure this process will be free from merge conflicts. It's the developers responsibility to understand what they've changed. It's really, really important to follow Coding Standards for tabs (4 spaces) and newlines (UNIX-style) in your own development to avoid conflicts based on whitespace.
For stores tracking versions without any local code changes, upgrading should be as simple as checking out the next version. For example, to upgrade to 1.3:
git fetch upstream
git checkout version-1.3 upstream/version-1.3
To get minor bugfix updates during the life of the version branch, run git pull upstream/version-1.3.
Downgrading should be a matter of checking out the previous branch. Continuing the example:
git checkout version-1.2