Skip to content
This repository has been archived by the owner on Jan 26, 2023. It is now read-only.

branchflow

Jump to bottom
TADraeseke edited this page Aug 28, 2020 · 2 revisions

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.

Branches

  • 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.

Other branches

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-tables would 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-basemaps and 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.

Branch format

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.

Wiki Home

General

Process

Clone this wiki locally