EXL

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

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

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

Зачем разные части одного проекта помещать в отдельные ветки? Кажется, у вас неправильное представление смысла веток, которые используется в 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)

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

Нет, клонируются все удалённые ветки. Просто они имеют префикс origin/удалённая_ветка А вот отслеживаемой становится только ветка master -> origin/master.
Для того, чтобы сделать ещё одну отслеживаемую ветку - переключитесь на удалённую и выполните создание локальной ветки. Всё это можно сделать одной командой:

git checkout --track -b local_branch_name origin/remote_branch_name

Где local_branch_name - имя создаваемой ветки, origin/remote_branch_name - полное имя удалённой ветки; local_branch_name для удобства можно назвать одинаково с remote_branch_name. После выполнения команды у вас появится ветка local_branch_name, которая будет отслеживать ветку remote_branch_name на сервере.

Github != git.
Рекомендую книгу Scott'а Chacon'а - Pro Git.