EXL

Посмотрите такой вариант. Кросс-платформенный.

Я вижу несколько способов разрешения зависимостей.
Во-первых, можно собрать libcurl и libjansson статически и прилинковать к вашему приложению.
Во-вторых, помимо статических libcurl и libjansson можно собрать сам Qt тоже в статику и прилинковать к вашему приложению. На выходе вы получите исполнительный файл большого размера (размер можно урезать с помощью утилиты upx), который будет запускаться во всех современных дистрибутивах GNU/Linux, где есть иксы.
В-третьих, самый рациональный способ - собрать DEB- или RPM-пакет, в котором в зависимостях прописать пакеты libcurl3(4), libjansson4, и необходимые модули с qt4(5).

Ну а запустить сам бинарь просто. У вас в Qt Creator'е есть переменная окружения LD_LIBRARY_PATH. Просто скопируйте в терминал её значение перед запуском программы:

LD_LIBRARY_PATH="/opt/QtSDKs/Qt5.3.1/5.3/gcc_64/lib:/opt/QtSDKs/Qt5.3.1/5.3/gcc_64/lib:/home/user/projects/jansson/lib:$LD_LIBRARY_PATH" ./my_cool_app

Curl у вас, похоже, собран статически. Попробуйте собрать jansson тоже в статику. Тогда ошибки error while loading shared libraries: libjansson.so.4: cannot open shared object file: No such file or directory вы не получите.

git commit --amend исправляет (перезаписывает) только последний коммит. Если вам требуется изменить всю историю проекта - воспользуйтесь командой git rebase -i --root, про которую можно прочитать тут. Естественно коммиты не должны быть публичными.

Вы неправильно развертываете плагины, они должны располагаться в каталоге с программой в поддиректориях.

Структура проекта, который будет запускаться на других компьютерах должна быть такой:

Current Directory/
	|
	+-platforms/
	|	|
	|	+-qwindows.dll
	|
	+-sqldrivers/
	|	|
	|	+-qsqlite.dll
	|
	+-DatabaseAnime.exe
	|
	+-Qt5Core.dll
	|
	+-Qt5Gui.dll
	|
	+-Qt5Sql.dll
	|
	+-Qt5Widgets.dll
	|
	+-icudt52.dll
	|
	+-icuin52.dll
	|
	+-icuuc52.dll
	|
	+-libgcc_s_dw2-1.dll
	|
	+-libstdc++-6.dll
	|
	+-libwinpthread-1.dll

И ещё несколько советов.
1. Если ваш проект не использует QtWebkit, вы можете пересобрать библиотеку Qt 5.3.1, без библиотеки icu, тогда ваше приложение "похудеет" на 27 MB.
2. Опять же, если вы не используете QtWebkit, вы можете собрать Qt 5.3.1 статически, получив единый испольнительный файл без всяких внешних DLL-библиотек и плагинов, который можно сжать upx'ом и получить exe-файл приемлемых размеров (~3-5 MB).

Подробнее про развертывание можно прочитать в официальной документации.

Если Qt был установлен с официального сайта, то всё безопасно; просто антивирус (вы кстати не указали какой) у вас параноик и ложно сработал. На всякий случай загрузите файл qsvgicond.dll на https://www.virustotal.com/ и посмотрите, сколько антивирусов отреагируют на него подозрительно.

В том случае, если ветка master (или branch_name) не является отслеживаемой веткой origin/master (или origin/branch_name), а вы хотите сделать её таковой.

Выполнив команду git push -u origin master вы устанавливаете связь между той веткой, в которой вы находитесь и веткой master на удалённом сервере. Команду требуется выполнить единожды, чтобы потом можно было отправлять/принимать изменения лишь выполняя git push из ветки без указания всяких алиасов для сервера и удалённых веток. Это сделано для удобства.

Возможно вам следует воспользоваться Qwt - Qt Widgets for Technical Applications.

Или же посмотреть в сторону QPainterPath.



Там можно рисовать такие вот штуки, посмотрите примеры из документации.

Если у вас имеется Git-репозиторий, то можно выполнить:

git config --global core.autocrlf input
Благодаря этому параметру код, полученный из репозиториев, на всех системах будет точно с таким же переносом строк, как и в репозитории. Однако, перед записью в репозиторий окончания строк будут конвертированы в LF. Эта настройка удобна для кросс-платформенной разработки в Unix-like системах, но так же может использоваться и в Windows. А если в Windows вам срочно потребуется CRLF, просто измените параметр input на true, таким образом при выгрузке кода из репозитория на машине пользователя будут CRLF-переносы, тогда как в самом репозитории так и останутся LF-переносы строк.

Зачем разные части одного проекта помещать в отдельные ветки? Кажется, у вас неправильное представление смысла веток, которые используется в Git'е. Ветка в этой DCVS -- это всего лишь указатель на состояние рабочего каталога. И реализовать Work Flow, описанный вами на ветках Git'а не то чтобы сложновато, но зачем и для чего мучить бедный Git, который при каждом

git checkout
будет вам разворачивать поддерево то одного проекта в ваш рабочий каталог, то другого. Это во-первых, жутко неоптимально с точки зрения той же производительности, а во-вторых вы так совсем запутаетесь, тем более раз вы ещё включили в рабочий процесс слияния между этими ветками. Конфликтов слияния и трудностей таким образом можно достигнуть множество. Пожалуйста, обратите внимание на работающие подходы, используемые для разработки с использованием Git:

Если в ваших частях проекта выражена очень разная функциональность, то можно создать два отдельных репозитория (к примеру, fronted и backend), а затем, при необходимости, соединить их в один Git-суперрепозиторий в качестве его подмодулей.

Если одна часть -- зависимость от другой, то следует подключить эту зависимость submodule'ем или вообще поддеревом (см. главу 6.7. из книги Скотта Чакона - Pro Git).

Если это всё же монолитный проект, имеющий две части, например, первая часть содержит реализацию логики приложения в "./src/core", а вторая -- пользовательский интерфейс в "./src/ui", то их и вовсе не нужно разделять.

Всегда используйте справку в подобных ситуациях.

Скорее всего статистика у вас не отображается из-за того, что не выполнено условие:
The email address used for the commits is associated with your GitHub account.
То есть ваш E-mail адрес, не совпадает с тем, что находится в GitHub account'е.

P. S. И да, русские символы в вашем приложении не отображаются через Wine. Возможно в Windows с английской локалью тоже будут проблемы (приду домой, проверю и отпишусь вам).

P. P. S. В репозитории на Github'е принято хранить только исходные коды, лицензии, документацию и ресурсы приложения. В общем необходимый минимум для построения рабочей программы. Хранить бинарные сборки (exe-файлы) и библиотеки (dll-файлы) - плохой тон. Для этого существует вкладка "Releases", куда вы можете выложить рабочую копию приложения.

P. P. P. S. Как я и предполагал, ваша программа некорректно работает в Windows с английской локалью. Так что оберните строки как-нибудь в Unicode'ную кодировку. И ещё, у вас в репозитории есть пара скриншотов, можете добавить их на страничку проекта, если измените свой README.txt на README.md (MarkDown разметка). Вставить изображение в README.md можно так:

![English](https://raw.githubusercontent.com/Areso/hydrostatic_test/master/screenshot_eng.png)
![Russian](https://raw.githubusercontent.com/Areso/hydrostatic_test/master/screenshot_rus.png)

Пример подобной странички с изображениями можно посмотреть тут.

Если в этом проекте есть файл "Makefile.am", то активируйте в "Help -> About Plugins..." плагин AutotoolsProjectManager, а затем перезапустите Qt Creator и откройте этот файл в программе;

Если ничего подобного нету, то сделайте проектный файл ручками с помощью "File -> New File or Project... -> Import Project". Ттаким образом на основе созданных файлов можно будет сделать полноценный и привычный "*.pro"-файл.