...

We aren’t going to do anything component wise on the server side at this time. We currently get the PHP version from the client side, allowing us to lookup modules based on the PHP version they were published for (at this time this is mostly for Zended modules).

The Why

Image RemovedImage Added

The repository setup that we use and that works well with this branching model, is that with a central “truth” repo. The central "truth" repo for github.com/FreePBX is http://FreePBX.org is http://git.freepbx.orggithub.com/FreePBX .

...

Such terminology can also be used when dealing with github, we normally refer to github as one of our remotes. Everything from http://git.freepbx.orggithub.com/FreePBX mirrors directly to github but pull requests are managed through http://git.freepbx.orggithub.com/FreePBX by assigning a remote to the github remote that wants to do said pull request and applying it on http://git.freepbx.orggithub.com/FreePBX first, which then replicates back to github. This way we are applying patches and fixes directly to our "truth" repo.

...

By no means are these branches “special” from a technical perspective. The branch types are categorized by how we use them. They are of course plain old Git branches.

Feature branches

...

• May branch off from: release/*

...

When starting work on a new feature, branch off from the release branch you want to start from

$ git checkout -b myfeature release/13.0
Switched to a new branch "myfeature"

Release branches

May branch off from: release/*
Must merge back into: master
Branch naming convention: release/*

...

Release branches are created from the develop branch. For example, say version 1.1.5 is the current production release and we have a big release coming up. The state of develop is ready for the “next release” and we have decided that this will become version 1.2 (rather than 1.1.6 or 2.0). So we branch off and give the release branch a name reflecting the new version number:

$ git checkout -b release/14.0 release/13.0 
Switched to a new branch "release/13.0" 

This new branch may exist there for a while, until the release may be rolled out definitely. During that time, bug fixes may be applied in this branch (rather than on the develop branch). Adding large new features here is strictly prohibited. They must be merged into develop, and therefore, wait for the next big release.

...

The first two steps in Git:

$ git checkout master 
Switched to branch 'master' 
$ git merge --no-ff release/1.2 
Merge made by recursive. (Summary of changes) 
$ git tag -a release/1.2 -m 'release/1.2'

The release is now done, and tagged for future reference.

To keep the changes made in the release branch, we need to merge those back into develop, though. In Git:

$ git checkout develop 
Switched to branch 'develop' 
$ git merge --no-ff release/1.2 
Merge made by recursive. (Summary of changes)

This step may well lead to a merge conflict (probably even, since we have changed the version number). If so, fix it and commit.

...

Hotfix branches are created from the master branch. For example, say version 1.2 is the current production release running live and causing troubles due to a severe bug. But changes on develop are yet unstable. We may then branch off a hotfix branch and start fixing the problem:

$ git checkout -b hotfix/1.2.1 master 
Switched to a new branch "hotfix/1.2.1" 
$ ./bump-version.sh 1.2.1 
Files modified successfully, version bumped to 1.2.1. 
$ git commit -a -m "Bumped version number to 1.2.1" 
[hotfix/1.2.1 41e61bb] Bumped version number to 1.2.1 1 files changed, 1 insertions(+), 1 deletions(-)

Don’t forget to bump the version number after branching off!

Then, fix the bug and commit the fix in one or more separate commits.

$ git commit -m "Fixed severe production problem" 
[hotfix/1.2.1 abbe5d6] Fixed severe production problem 5 files changed, 32 insertions(+), 17 deletions(-)

Finishing a hotfix branch

...

First, update master and tag the release.

$ git checkout master 
Switched to branch 'master' 
$ git merge --no-ff hotfix/1.2.1 
Merge made by recursive. (Summary of changes) 
$ git tag -a release/1.2.1 -m 'release/1.2.1'

Next, include the bugfix in develop, too:

$ git checkout develop 
Switched to branch 'develop' 
$ git merge --no-ff hotfix/1.2.1 
Merge made by recursive. (Summary of changes)

The one exception to the rule here is that, when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop. Back-merging the bugfix into the release branch will eventually result in the bugfix being merged into develop too, when the release branch is finished. (If work in develop immediately requires this bugfix and cannot wait for the release branch to be finished, you may safely merge the bugfix into develop now already as well.)

Finally, remove the temporary branch:

$ git branch -d hotfix/1.2.1 
Deleted branch hotfix/1.2.1 (was abbe5d6).