Несмотря на распределенность Git и Mercurial, Вам всё же понадобится сервер для синхронизации изменений между разработчиками.
Если нет своего сервера, можно использовать Bitbucket с приватными хранилищами (ограничение в 5 пользователей на бесплатном аккаунте).
А что Вас смущает?
Я не работал с Qt Creator, но полагаю, что он просто в логе показывает, что выполняется git.exe, команда commit, с ключом -F, который задаёт, из какого файла брать коммит-сообщение (временный файл он создаёт после ввода Вами сообщения, наверно. Аналогично делает SourceTree). Ни в какие настройки Qt Git не лезет.
Во-первых, файл themes/classic/views/layouts/main.css не попадает под шаблон themes/classic/css/*. Git и предупреждает, что незакомиченные изменения в нём будут утеряны.
Во-вторых, у Вас, наверно, игнорируемые файлы уже под управлением Git, поэтому он их и отслеживает.
Нужно git rm --cached path/to/file.css
Помимо предложенных вариантов, можно просто не включать изменения в конфиге в индекс перед коммитом.
На диске будет лежать измененный конфиг, а в хранилище нетронутый.
Это опять же при условии, что Вам не нужно работать с этой веткой с другого компьютера.
Вы что-то путаете.
Git прекрасно работает с пустыми файлами.
Чтобы добавить папку, в ней должен быть хотя бы один файл, даже пустой. Обычно добавляют пустой файл .gitkeep (по аналогии с .gitignore), но имя неважно.
И если в клонируемом хранилище это сделано, склонируется всё, как есть, полностью.
На Битбакете нельзя сделать SSH-ключ с Write-доступом.
Нужно добавить пользователя в управлении доступом.
После этого он сможет пушить, указывая СВОЙ логин / пароль.
Но есть ограничение в 5 пользователей (не помню - на один репозиторий или на все в сумме).
Ну и? Всё же написано.
test.java будет перезаписан после merge, поэтому нужно его либо закоммитить, либо сделать stash, чтобы локальные изменения не пропали.
Ну или просто вернуть файл в состояние, в котором он был в момент последнего коммита, чтобы в нём не было изменений.
git pull = git fetch + git merge
То есть pull - это получение новых данных с origin (fetch) и слив их с текущей веткой. fetch просто получает новые данные (коммиты), но не сливает их в текущую локальную ветку.
Откат к предыдущему коммиту (если ненужные изменения вы не коммитили, то есть сброс изменений): git checkout HEAD . (точка - часть команды)
Что значит "ставлю галочку чтобы коммиты относились к предыдущему"? Это git commit --amend? Если так, то никак - после push делать amend (изменять отправленные коммиты) неправильно, сервер отклоняет push, так как ему нужен fast forward, а хеш коммита изначального и коммита дополненного не совпадают, поэтому нужно либо делать pull (тогда будет два почти одинаковых коммита), либо push --force, а вообще лучше не править отправленные коммиты.