The master branch contains the development code, currently 5.7-SNAPSHOT.
When that code is passing all advanced CI tests (performed by nightly builds starting from IT-nuxeo-master-build), then the artifacts are deployed (by deploy-nuxeo-master) and the 5.7-SNAPSHOT branch is automatically updated (by join-IT-nuxeo-master_tests calling the Rebase current version on master batch task).

It's a forced reset, here's the script:

. $WORKSPACE/release.log
cd nuxeo
. scripts/gitfunctions.sh
gitfa checkout $BRANCH
gitfa branch -f $NEXT_SNAPSHOT 
gitfa push origin $NEXT_SNAPSHOT

The idea is: if you want to work with the (CI validated) 5.7-SNAPSHOT artifacts, then you can get a branch pointing at the exact code corresponding to those artifacts.

The maintenance branch is created by the release.py script. Depending on the parameters (especially the kind of release), that branch is then deleted or kept. Here is the script for preparing a release:

if [ $FINAL = true ]; then
  ./scripts/release.py prepare -b $BRANCH -t $TAG -n $NEXT_SNAPSHOT -m $MAINTENANCE -d -f
else
  ./scripts/release.py prepare -b $BRANCH -t $TAG -n $NEXT_SNAPSHOT -m $MAINTENANCE -d
fi

Then, if the release candidate is satisfying, the release is “confirmed” and published with:

./scripts/release.py perform

The jobs' sources are not available for now because I didn't had time to work on that, even if it's effectively planned. Note however, they will not contain anything really important since I hardly recommend to only call scripts from the Jenkins jobs and write the logic in those scripts, which are of course publicly available. See clone.py, release.py and other tools such as tools-nuxeo-ftest and nuxeo-integration-release (that later one is mostly deprecated).