Freeman

.gitignore действует сразу, но в нем надо косую черту переставить:

.vs/
Debug/
Release/
*.vcxproj.filters
*.vcxproj.user

Обычный cherry-pick, не? Слияние (merge) сливает ветку изменений целиком, а тут речь именно про ручной отбор, то есть собирание истории вручную?

git switch master

git cherry-pick second~1
# разрешаем конфликты, если надо
git cherry-pick --continue # если были конфликты

git cherry-pick second
# аналогично с конфликтами и продолжением

Аналогичного результата можно было бы добиться и при помощи перебазирования second на master, но оно приведет к нужному результату только если нет этих самых unrelated histories, ибо при их наличии начнет перетаскивать историю от сотворения мира. Для двух коммитов ручной перенос — самый простой и употребительный вариант, поменяется только дата коммита.

На самом деле решение зависит от принятого порядка работы (workflow). Если допустимы rebase (у программистов) и force push, можно перейти в ветку, сделать сброс, а потом принудительно обновить ветку в удаленном хранилище (программистам потом придется выполнить сброс и/или перебазирование у себя):

git stash push
git reset --hard HEAD~10 # задать свое число — на сколько откатиться, либо по хешу
git push --force-with-lease
git stash pop

Если же, как написано:

Локально я себе все это не пуллил.

Будет достаточно одной команды:
git push --force-with-lease

Эти действия именно удалят коммиты без возможности восстановления.

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

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

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

Чтобы делать 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, это проблема архитектуры вашего приложения. При нормальной реализации должно быть общее ядро и клиентозависимые расширения, а для поставки клиента собираться в единое целое тем или иным образом.

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