Branch trunk has been officially retired, and is replaced by branch master as the default mainline for development.
master
master will be mostly stable. Development for FarCry 7.1 will commence here shortly.
You should not run production environments from this branch, unless you are tracking changes very closely. No guarantees for stability will be made. You have been warned 
trunk
There will be no further commits to this branch. trunk will be left in place for the foreseeable future to help assist those tracking the branch in their transition to master.
p700
Folks looking for a maintenance or patch branch for the 7.0.0 release (formally on trunk) should be tracking p700 and its tags.
We endeavour to keep all maintenance branches production ready at all times. However, only specific tags are tested. It should be mostly safe to track p700 in production environments. Nervous dev-ops might consider sticking to tagged builds only.
1 Like
“Sticking to tagged builds” is not really the Git way of doing things. Checking out a tag is uncommon in git as it puts you on a detached head which leaves you open to losing commits. You can avoid this by creating a new local branch from a tag, but then you’d have to rebase the local branch whenever you want to upgrade the tagged build. This is fine for advanced developers who make local tweaks to their maintenance checkouts but perhaps too complicated for a regular user who just wants a stable upgradable checkout.
If tagged commits represent recommended builds then each maintenance branch should have a corresponding “tested build” branch that lags behind it and gets fast-forwarded after the next maintenance build is tagged. That way anyone who wants to stick to tested builds can checkout that branch and be assured that “git pull” will always give them the latest tested build for that maintenance branch. I’m not sure how we should name these branches. p700_stable? p700_milestone? p700_tested?
It’s easy enough to use a specific tag by doing a reset --hard… e.g:
git checkout p700
git reset --hard 7.0.1
A pull will always result in the HEAD of the maintenance branch if you want it. Or to advance to the next tag when it’s available just do a git fetch followed by another reset to the new tag name.
What I’ll probably do is merge to master when p700 is tagged so that master is always “stable”, and do bleeding edge development elsewhere (p710, p800, etc). Need to keep the branches tidy and simple as possible 
1 Like
