Freeman

Если файлы меняются пользователями, они являются настройками и должны игнорироваться через добавление в .gitignore. В нормальном проекте.

Вроде бы хранение графа коммитов сильно ускоряет git log. Стоя в репе, выполняем команду:
git commit-graph write --reachable --split=replace

Если SSH нужен именно для push, в Git поддерживается отдельный pushurl (качать по одному пути, толкать по другому):

git remote set-url --add --push origin git@github.com:Username/repository

С самой задачей не сталкивался, но заинтересовался. Из нагугленных рецептов сработал следующий:

git rev-list master..develop~1 --ancestry-path --merges -- script/git-touch

К сожалению, он выдает только хеши, а можно ли сделать поиск по конкретной строке кода, не изучал.

Чтобы переключаться по очереди на каждую из них и видеть, что где я делал и далее копировать сделанный кусок кода и вставлять его в новую ветку.

Чтобы делать cherrypick.

Есть очень удобный GitKraken, но для приватных хранилищ от платный.

SVN лучше Git тем, что не пытается превратить твою Винду в Юникс и не тащит за собой кучу мусо... э-э-э, зависимостей, которые проистекают от нежелания разработчиков Git договориться и написать всё на одном языке... или не на одном, но компилируемых, чтобы потом собрать объектный код в исполнимые модули.

Поэтому SVN -- это 5 метров EXE/DLL самого SVN, а Git -- 200 (400?) метров, включающих в себя MSYS, Cygwin и Perl помимо самого Git. Для кого размер не аргумент -- есть понятие сложности владения: в большой и сложной системе больше точек, где что-то может сломаться.

Насчет поколений и распределенности никто не спорит. Просто так сложилось, что к моменту появления распределенных VCS несистемные программисты перестали писать на компилируемых языках... В смысле однородности Mercurial лучше, но Python медленный, зараза!

И чтобы хранилась история, чтобы мы могли взять версию своей библиотеки за прошлый год и быстро ее собрать со всеми зависимостями. Сейчас используем сетевую папку просто.

В SVN есть такая штука, как svn:externals. В Git и Мercurial тоже наверняка есть, а вот в CVS вряд ли.

Суть в том, что в вашем хранилище хранится ссылка на другое (внешнее) хранилище, и при развертывании рабочей копии клиент ходит по этим "символическим ссылкам" и рекурсивно по ним всё скачивает. В SVN подчиненные рабочие копии будут выглядеть как обычные, у них будет своя папка .svn.

Нужно только, чтобы внешнее хранилище было такого же типа, как и ваше. Скажем, SVN не сможет скачать из внешнего Git. Если вы качаете библиотеки не из хранилищ, а просто архив с сайта, заведите у себя отдельное хранилище для библиотек и складывайте туда все нужные версии.

Это не проблема Git, это проблема архитектуры вашего приложения. При нормальной реализации должно быть общее ядро и клиентозависимые расширения, а для поставки клиента собираться в единое целое тем или иным образом.

То, как вы сейчас делаете, похоже на реализацию двух разных приложений. Если хотите продолжать -- разделите хранилища, как вам уже предложили.