Алексей Киселев

Лучше воспользоваться системой управления зависимостями. Например Apache Ivy или аналогичной. Считается, что subtree и тем более submodule являются упрощенными и ограниченными по функциональности заменами нормальных систем управления зависимостями. Вот неплохое описание проблем связанных с использовани....
Использование Ivy подразумевает наличие системы сборки проекта. Но возможности по управлению зависимостями открываются неограниченные. Особенно приятно когда у вас команда из больше чем 2-3 человек, 2-3 десятка библиотек и нужно поддерживать и развивать несколько версий приложения одновременно.
Хотя Ivy написана на Java и очень тесно интегрирована в мир Java, она является универсальным менеджером зависимостей и мы использовали ее для управления зависимостями в проекте на C#.
Возможно, для C++ есто что-то свое, но я далек от этого мира.

Ого! Jazz еще жив!
В нем конечно хорошая интеграция всего со всем, но если вы этим не пользуетесь, да еще и его тяжеловесность является препятствием к использованию SCM, то лучше от него отказаться.

Работа должна быть в радость. Git поощряет разработчиков делать частые коммиты. Это просто и быстро. Так же с Git проще экспериментировать с кодом.
А еще Git - это mainstream. Разработчик с ним не пропадет.

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

Придется пользоваться консольным клиентом. Я проверил работу git-subtree на версии Git 1.8.1.msysgit.1 под Windows.

Я нашел в группе tortoisegit-dev запрос на добавление поддержки git-subtree датированный 27 февраля 2014 года. Думаю реализован он будет не очень скоро.

На Windows очень удобно пользоваться Git из PowerShell с помощью posh-git.

Почитайте про набирающую популярность модель ветвления Trunk Based Development.
При использовании этой модели вам потребуется ветка master (trunk) и ветки для релизных версий. В master вы ведете разработку (в вашей терминологии это development) для каждой версии выходящей к пользователям вы создаете отдельную ветку, например 1.0.x.
Самое главное: все изменения вносятся разработчиками только в ветку master. Только ответственные люди могут создавать релизные ветки и переносить изменения из master в них, в том числе и при внесении изменений в выпущенные версии. Релизы
собираются только с релизных веток.

В этой модели разработчики не ограниченны в создании локальных веток, но их никто не хочет видеть на общем сервере. У разработчиков нет прав на создание веток на общем сервере.

Процесс выглядит так:
1. Разработчик делает pull master.
2. Если нужно создает локальную ветку и работает в ней.
3. Прогонят тесты на ветке и мержит ее с master.
4. Делает push.
5. CI видит новый коммит, получает его и выполняет на нем модульные, интеграционные и приемочные тесты.

Я не очень понимаю, для чего могут потребоваться автоматические коммиты, мое мнение - этот процесс должны контролировать люди. А задачи в issue-tracker должны закрывать тестеры или разработчики, если они написали соответствующие тесты.

В том, что на CI не пройдут тесты нет ничего страшного. Он вообщем-то для этого и нужен. Откатывать коммит не нужно, нужно быстрее делать новый, в котором ошибка исправлена.

Это называется merge bubbles. Git создает merge-коммит во время каждой операции pull. Во время слияния 2-х веток Git может сделать или merge с созданием merge-коммита или rebase без создания новых коммитов. Кто-то настроил его так, что он всегда создает merge-коммиты.

За данное поведение Git отвечает настройка branch.autosetuprebase.
Данная настройка может иметь 4 значения:
* never - Git никогда не выполняет rebase
* local - Git выполняет rebase только для локальных веток
* remote - Git выполняет rebase только для удаленных веток
* always - Git всегда выполняет rebase.

Для удобства выставите ее в always глобально.

git config --global branch.autosetuprebase always

Для Git нет понятия "более поздний коммит", для него все коммиты, сделанные от одного предка являются параллельными.
В вашей универсальной команде вы создаете коммит, а потом во время pull просите разрешать конфликты автоматически используя изменения из удаленной ветки, то есть разрешаете конфликты в пользу ранее сделанных вами изменений. Что, как мне кажется, немного противоречит желанию использовать самые последние сделанные изменения.

Возможно вам больше подойдет стратегия ours.

git pull -s ours

В этом случае ни какого слияния не производится, указатель просто перебрасывается на последний локальный коммит. Вся удаленная история изменений игнорируется.

mysvn.ru
только там Git нет.
А локализация есть в TortoiseSVN или TortoiseGit.

Git распределенная система контороля версий, не нужно пользоваться ею как SVN. Клонируйте репозитории по необходимости, это же просто и можно делать локально.

Создайте в разделяемой папке bare репозиторий Git:

mkdir repo
cd repo
git init --bare

В Ubuntu добавьте в репозиторий ссылку на только что созданный разделяемый репозиторий и выполните в него push имеющихся коммитов.

git remote add origin [путь к папке разделяемого репозитория]
git push origin master #отправляем ветку master в удаленный репозиторий по ссылке origin

Теперь клонируем разделяемый репозиторий в Windows.

git clone [путь к разделяемому репозиторию]

и работаем в копии. Изменения отправляем и получаем командами push и pull.

Это проблема библиотеки libgit2. Судя по исходникам поддержка ssh была добавлена 12.12.2013, совсем недавно.
У вас возможно используется одна из предыдущих релизных версий. Какая-то поддержка ssh появилась начиная с версии 0.20.0.

Ветки пока не нужны, достаточно master.
Если ваша активная разработка связана с внесением новых функций, необходимых заказчику, делайте все в ветке master. Я предлагаю вам сделать тег на той версии, которая работает у заказчика на боевом сервере. После этого продолжайте разработку в master и таким образом получите development версию продукта. Которую вы будете ставить на development сервер.

Если у вас возникнет необходимость что-то поправить в боевой версии, делайте ветку с тега и вносите изменения в ней. При необходимости сливайте изменения на master.

И помните Git - это не deployment tool. То как вы описываете свою проблему, наводит на мысль, что вы просто делаете pull одной из веток на серверах. Хорошо если я ошибаюсь, так как делать этого не нужно, плохо с точки зрения безопасности.

Универсальным решением будет использование сервера непрерывной интегации (Continuous Integration), например Jenkins.
Сделайте на нем 2 задания, одно для ветки master, второе для вертки test. В этих заданиях в ответ на появление коммитов в ветке сделайте публикацию на сайт по SSH, FTP или простым копированием.
Преимуществом подхода является то, что вся информация о deployment сосредоточена в одном месте - заданиях Jenkins, для разных проектов можно по разному организовать выкладку файлов на сервер, но принципиально задания будут одинаковыми.
Если пойти дальше, то в этих же заданиям можно запускать автоматическое тестирование.

Git, по сравнению с SVN, поощряет делать частые коммиты. Поэтому проверьте как у вас быстрее получается сделать коммит: через командную строку или графическую утилиту.

Если вы работаете на Windows, то возможно TortoiseGit будет для вас привычней после TortoiseSVN. Тем более что по умолчанию в Windows не работает автодополнение команд Git в командной строке.

Если вы хотите приблизиться в Windows к удобству использования Git в *nix системах, попробуйте posh-git. Это расширение для PowerShell.

Мне удобнее и быстрее делать коммиты, ветки и слияния, push&pull и теги из командной строки, а работать с историей и различиями в файлах проще из графических утилит.

Нужно завести для каждого года отдельный репозиторий. То есть начинается новый год, вы создаете репозиторий 2014 и работаете в нем.

mkdir 2014
cd 2014
git init
…
git add .
git commit

При этом ничто не мешает вам работать в репозиториях для прошлых годов и делать там коммиты.

Если нужно сделать копию на другую машину. То клонируем на ней ваши репозитории. Или просто переносим их простым копированием.

Но, если честно, вы придумали очень странное применение Git. Проблема даже не в том, что вы работаете с бинарными файлами, а в том что вы хотите делать коммит раз в год. Это очень очень очень редко.