-
Notifications
You must be signed in to change notification settings - Fork 1.2k
branchflow
A slight alteration to GitFlow
We follow a branching strategy that allows us to always have an up to date branch in sync with the latest release of the ArcGIS Android SDK and a next release branch where new API updates or samples exist in a pre-release state.
-
master There is only one release branch,
master. This branch is the current release standard branch. - v.next This is the next release branch and will include details on which pre-release it is targeting. This branch is not a public development branch as it will use our internal artifactory server repository to build samples against non-released daily builds of the SDK.
- beta This is a branch representing the occasion we should release a pre-release version of the SDK, e.g. beta. This branch is intended for public pre-release use of the SDK and will build from a public distribution of the SDK in pre-release form.
All other branches detailed here are branched off of either the master or v.next branch and merged back into the respective branches when ready for release PR's. The determination of which branch to use depends on what version of the SDK you are targeting with the branch.
- Feature branches are typically a new sample being introduced to the SDK. They should be named representing the sample they are featuring, e.g.
dop/query-related-tableswould represent a new Query Related Tables sample. - Hotfix branches are used for fixes to existing samples. They should be named representing the fix, e.g.
dop/fix-change-basemapsand can include an issue number if one exists, and always include issue number in the PR for tracking.
NOTE: Be aware that we need to keep our v.next branch synced with our master branch as new samples and hotfixes come in to the current release we want to ensure that the v.next branch picks them up as well.
- Backport branches are similar to hotfixes except they are for previous releases so you don't branch off of master or v.next, instead you branch from a tag representing the version you want to provide the fix for and merge back to that tag when ready for a Pull Request.
It is recommended to prefix all branches with your name, initials, or something that represents your branch. This creates a folder hierarchy with a file named for your branch. If you create a branch named john/foo, git will create a file named foo in .git/refs/head/john/. Because of this you can only create one forward slash / in a branch name as you can't create a file in another file.